Configuration management (CM) or application lifecycle management (ALM)? Shouldn’t the focus really be on how you can improve your development lifecycle from an end-to-end perspective and break down the silos between analysts, developers, and testers? Does your team follow ALM principles? You could argue that every development team practices ALM when creating software products, whether or not they plan to do so. A given team will typically define its requirements and update them, split them up into developer tasks, then complete, build, test, and release them.

I believe the issue is not so much whether you’re doing ALM but rather how you’re doing it. For example, a pragmatic ALM approach in a small team of five or six developers might include a Word document or Wiki to capture requirements, a white board to track tasks, and an Excel sheet to keep track of test cases. However, things get more complicated as the team grows or the pace of development increases. For example, Dave hasn’t correctly copied his changes and has overwritten Paul’s changes. This is where version control comes into play. Then customers start asking for maintenance of the current release while work continues on the planned, new features. This sort of scale introduces the need for CM.

CM Matters
At this stage, a discussion about costs and benefits often starts to kick in. On one hand, CM might add some overhead to development, because it requires check out and check in steps. On the other hand, there are very tangible benefits from CM, such as the ability to retrieve a previous version, visual tools to identify a change (and its originator) that have caused a bug, or the ability to access the change history remotely—a useful CM feature if a particular developer or team isn’t immediately available.

When looking beyond pure development, CM usage is also found in other tasks, such as versioned requirements or test case documents— even if the CM is done by taking a new picture of the whiteboard or by changing the document name. Typically, there’s at least one place where requirements and test cases are held: in someone’s head, in a (shared) spreadsheet, or in a software tool.

The point is, in smaller teams with clear responsibilities and a shared location, it’s relatively easy to make all this information centralized and accessible for everyone. In this situation, information sharing is based on short face-to-face meetings and informal communication involving implicit or manual changes to each team member’s information stack. To get a holistic view, a team manager wouldn’t query a tool but would instead talk to his team members.

Bigger Teams, Wider Challenges
But as dev teams grow, the problems start to emerge. Specialization tends to creep in and information is less easily shared across functional boundaries. Questions such as What if the team genius falls sick? or What if two testers want to update the test case spreadsheet at the same time? can start to arise.

The immediate solution might be to address the pain points by implementing point solutions. Later, integration needs to take place to get an end-to-end view on project progress. However, teams don’t necessarily need to have twenty or more members to feel that need for more tool support. Such a need can start to rear its head when team members start to work remotely or near- and offshore teams are introduced. In these cases, just one person not being available onsite might make it worthwhile to think about effective ways to complement direct, face-to-face communication with a more robust CM approach.

The Value of Traceability
ALM as used in this article describes an integrated and coordinated effort to manage the software development lifecycle, as opposed to working with isolated solutions. Putting this transparency into the development lifecycle has already been stipulated in CM Crossroads a while ago. Adam Kolawa, to name but one, highlighted the following [1]:

1. Requirements must be properly considered and defined
2. Requirements must be correlated to code and tests
3. The impact of changes during maintenance must be better tracked

I won’t go into detail on points 1 and 3, but will focus on point 2. Eventually, a project manager will want to see what requirements there are for a given project, how the requirements relate to each other, what impact change requests might have with regards to code and tests, and what the project status is in real time.With agile and lean practices getting more and more popular, shorter development cycles and more frequent delivery become the norm. This in turn leads to more change, as planning is revised with every iteration, and priorities might get adapted to reflect changing customer needs. So in addition to the challenge of supporting remote communication, there’s also a risk of added overhead.

Automation as a Key CM Driver
Naturally, development managers have looked into how repetitive manual tasks could be replaced with automation. There’s a double benefit in automating such tasks, as they don’t just reduce overhead once set up, they also eliminate human error and the risk that a important task scribbled on a Post-It note just got lost.

Automation has been implemented in many areas of the development lifecycle: such as when using build scripts and tools, when automating testing or project management, or where status updates are automatically performed based on links between project items. Yet, interestingly enough, CM is one of the areas where the potential of automation hasn’t been realized yet.

Achieving more automation along the development lifecycle allows team members to focus on tasks that require human input and judgment, instead of spending a considerable amount of time just updating fields in different tools. As a consequence, perhaps ALM might get a new interpretation as "automated lifecycle management"!

CM on Full Auto
CM is an important driver for development productivity, yet remains often overlooked when discussing how the development lifecycle could be optimized.  Often, this happens because of the perceived complexity of parallel strategies and, again, expected additional overhead. However, today’s CM tools offer powerful capabilities that allow users to tap into that potential.

Using private or feature branching offers huge benefits simply because developers don’t need to manually create and synchronize branches anymore. Code inheritance can take over this job automatically. This practice results in better quality, as developers can check in as much as they want without needing to reflect a completed task. This relationship is assured on a higher level when completing the feature, as modern CM tools also track change with project- or even program-wide work items.

This fills in an important gap when trying to achieve end-to-end traceability. Requirements are not only tracked on the task or feature level when they are first checked in but also when they get merged across project versions or get reused as part of shared components or libraries.

So in summary, I believe there are two main benefits in moving to an integrated ALM solution: end-to-end traceability and automation. These benefits make management of distributed development more efficient by providing team members with the necessary information and the collaboration platform. At the same time, automation minimizes overhead for each dev team member, as repetitive tasks can be automated.

These elements have long been overlooked in CM, but they become more important as a core part of achieving ALM success. Getting the requirements-code-test link right then opens the door to end-to-end visibility with only minimal overhead.