CM: THE NEXT GENERATION - Beyond CM to ALM

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. 

About the author

Joe Farah's picture
Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com