Configuration management (CM) and application lifecycle management (ALM) are not easy to implement. Having developed strategies to support both CM and ALM in many organizations, I must say that I was not always satisfied with the results, and neither was the management above me. But I’ve also been successful, largely because I came up with a strategy that made sense for the organization. Creating the right approach is not always easy. I’ve learned a few lessons along the way that I share with you here.

What is CM?
The definition of CM has triggered many enthusiastic debates on the CM Crossroads forums and groups. (Jump in and participate!) Traditional CM experts will typically say that CM is:

• Configuration identification
• Status accounting
• Change control
• Configuration audit

This is certainly true, but it can be difficult to come up with a strategy to implement these practices in a large, multi-platform organization. My framework for understanding CM breaks it out in terms of six core functions that I believe more closely represent the way in which CM is actually practiced on a day-to-day basis [1], and, to which, I have many years of experience implementing.

The six functions are:

• Source code management
• Build engineering
• Environment management
• Change management
• Release management
• Deployment

I always focus first on making CM compelling. Start by demonstrating how CM can help your organization--especially your development team--create software (or what CM gurus call configuration items). Don't expect everyone to automatically accept (and believe in) the benefits of good CM. In order to understand ALM you need to first understand the classic CM function called status accounting.

Status Accounting
Status accounting involves following the evolution of a configuration item throughout its development lifecycle--not counting rows of numbers as the name may suggest. This may sound great, but how do you go about completing status accounting? On a practical basis, this is exactly what ALM is all about.

ALM
ALM is essentially the software or systems lifecycle used to create each of your configuration items meaning that CM is and always was a full lifecycle endeavor. Make sure your strategy exemplifies that CM and ALM are focused on the entire lifecycle.

What exactly makes ALM different than CM? In practice, ALM has a wide scope, from tracking requirements, design, test planning, development, all the way to deployment (and even tracking and retiring configuration items that should no longer be in use). Obviously, CM touches many of the same points as requirements, test cases, and design documents all need to be under version control as well. ALM also concentrates on tools and tool integration.

ALM Tools
Recently a colleague of mine chanted the common view that the process is much more important than the tools. I used to believe this, but ALM has taught me that tools do matter a great deal and your strategy needs to include a robust tools selection process (e.g., bake off). ALM's wide focus means that you need to have the right tools and process in place to support every aspect of your software and systems development effort. In practice, this has meant implementing requirements tracking tools with integration to test case management systems. There are two essential reasons for this. The first is that requirements should map to test cases. You want to verify and validate your requirements, don't you? The second reason is that incomplete requirements can be supported by well-documented test cases. ALM tools need to focus on integrations to provide a complete and robust full lifecycle solution. One benefit of this approach is enhanced IT governance and compliance.

IT Governance and Compliance
IT Governance is all about providing the essential information that management needs to make the right decisions. These practices are an essential ingredient in seeing that management can make the best decisions with the input of accurate and relative information. There are a number of organizations that provide information on implementing IT governance including ISACA. Your strategy should include using industry standards and frameworks for guidance. This leads directly to compliance, which usually refers to complying with regulatory requirements. CM and ALM are essential for supporting both IT governance and compliance.

Agile and Lean for CM/ALM Strategy
Using agile and Lean practices to iteratively develop CM and ALM processes was one of my best implemented strategies. For example, one ALM solution that I implemented recently has a complex workflow automation template that can be tailored to the individual needs of the team and project. There was no viable choice but to approach this effort in an iterative way. So I actually setup a separate project in the tool to track changes to the workflow automation template itself. In other words, I used the ALM tool to develop and implement the ALM tool! Implementing CM and ALM is an effort that requires industry best practices in alignment with your organization and culture.

Conclusion
CM and ALM are essential for the success of any software or systems development effort. There are many lessons and effective strategies to learn from for a successful implementation. Obviously, there are also risks that need to be addressed. The best strategy I’ve found is to use the same principles that work for your development effort to guide and manage the implementation of your CM and ALM functions. This is an excellent strategy that will help facilitate your success and the success of all of your efforts. Drop me a line and share your strategies for implementing CM and ALM!

[1] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010.
 

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment