both earlier and later into the product lifecycle sphere of influence. As well as having the standard CM components, an ALM solution must address:
- Version Control (2G)
- Build Management (2G)
- Change Management (2G)
- Configuration Management (2G)
- Problem Tracking (2G)
- Requirements Management (2G)
- Feature/Task/Activity/Project Management
- Test Case Management
- Test Run Management
- Document Management
- Organization Chart
- Delivery Management
- Customer Request Tracking
- Product Management
Basically, the product must be managed from inception until its retirement. It must be able to manage the entire product road map, and the product family road map. What is ALM? If your solution contains all the information you need about your product, for planning, development, validation, delivery and support, then you have an ALM solution.
So why is ALM so difficult? It comes down to architecture. It might have been ok to link a change management tool or a problem tracking tool to a version control tool to create CM, but the solution was far from ideal. 2G CM solutions, for the most part (excluding monolithic solutions such as CM+), either focused on a more narrow target (e.g. no requirements management or problem tracking), or ended up being administrative nightmares. Too big, inflexible, not scaleable.
Beside the functional requirements, the architectural requirements of an 3G ALM solution include:
Low maintenance: you only need part time support to keep even very large ALM shops working. Backups are automated and reliable. Server outage is rare. System limits are rare and/or inconsequential. Scripting for special requirements is straightforward.
Easy and extensive customization: Customization is the same across all functions, requiring less training. Capability is strong so that the process can be tailored to the roles, and the information is readily available for the job function. Customization across process, data schema and user interface are performed quickly and at low cost.
Easy navigation, including traceability: Why was this line of code changed? Which problems are fixed by this release? If you can't point-and-click to get answers without waiting for them, your ALM solution will lose half its value. You can run meetings from your ALM solution.
Ease of use across lifecycle functions: If training is necessary for each tool, you'll be losing a lot of time on training courses. If the tool doesn't follow your process closely or the terminology doesn't fit, more confusion. If its slow, you're wasting money and instilling dislike for your solution.
Role-based architecture: What you see is based on roles. There are role-specific dashboards. Record state transitions are protected by role. Permissions are by role, not by file system permissions.
Common repository: Your queries can span all functions. Your repository and/or schema is designed to support engineering and management applications. Your backups are consistent.
Multiple site operation: You can work from any site, or move from site to site, as long as you are assigned the proper roles. You can restrict sensitive data from some sites if necessary. Your data is up to date at all sites. You can almost always recover from network outages automatically.
Extensive process support: You have proper process guidance as part of the solution. You can dynamically modify the process as your requirements evolve. You can clearly and easily track progress.
Reliability and availability: Your solution is not prone to down time, whether for administration or because of problems. You have disaster recovery in place. Your backups are guaranteed to be consistent. You can deal efficiently with data errors or sabotage introduced several weeks back.
Longevity: As a backbone application, you can't be changing out your solution with every project the way you might be able to with CM alone.






