Principia: Power from Simplicity

Too often we see the name Configuration Management or Software Configuration Management applied to a team when in fact they perform a whole range of functions supporting IT system development. This has lead to a gradual bastardisation of the term Configuration Management to the point that the term has lost its original, focused meaning and has become, very nearly, a useless term. Worse, for the teams involved, their true function is concealed behind this increasingly broad term.

In Through the Looking Glass, Humpty Dumpty, when challenged by Alice over the meaning he assigns to the word ‘glory’, responds as follows.

“When I use a word,” Humpty Dumpty said in a rather a scornful tone, “it means just what I choose it to mean – neither more nor less.”

This is the situation we find with Configuration Management (and doubly so with Software Configuration Management). These terms mean whatever the individual using them intends them to mean and this results in a loss of communication (not to mention many warm discussions on forums as to what should fall under the purview of configuration management).

Surely it is better to return to an arguably more impoverished but more specific and focused definition and in so doing ensure that we all agree to the meaning. A new term should be found to represent the collection of disciplines that are variously bundled under the present configuration management banner. Configuration management must remain the discipline responsible for the identification, control, accounting and auditing of configuration information. Nothing less, nothing more.

The correct name for the collection of disciplines, including build, release, change, configuration, project management and so on, may be Lifecycle Management, Process Management, or any of a number of neutral collective terms, but not configuration management which already has (or rather had) a very specific dominion until it was expanded and, ironically, simultaneously eroded by the inclusion of odd disciplines.

The inclusion of another responsibility, such as build management, in the responsibilities of the team who perform configuration management does not automatically mean that that discipline becomes part of configuration management. What you end up with is a team responsible for both build and configuration management.

I propose the title “Lifecycle Management”. It encapsulates the various disciplines commonly found provided by ‘configuration management’ teams. It describes what these teams actually do. It is sufficiently flexible, capturing the idea that the team supports and manages the lifecycle concerns of a project, product, or organisation, but also allows room for extension.

So, Lifecycle Management shall, henceforth, be my profession.