You might know the Germans lost the North African Campaign in World War II, but did you know they lost because of a failure in configuration management? When a tank broke down for want of a part, the unit would request a replacement. The replacement part would arrive, right on time ... and wouldn't fit. Over time, the Germans' supply of tanks ran out and the British and Americans' did not.
Seventy years later, the discipline that sprang up to find the wrong-part-for-tank problem is called configuration management.
Now that we know the problem configuration management was designed to solve, we can talk about what it is. The answer lies in the eye of the beholder.
Towards a definition
Ask five people to define configuration management and you’ll likely get six answers. In my experience, developers will likely talk about the software itself, and the ability to replicate a software environment in one step. Project managers tend to care about work products and
That means that "configuration management" is a context-specific term. Consider an organization that sells insurance policies and needs to configure benefits for each group. For that company, configuration management might mean managing the configuration of the employer-groups. This has nothing to do with software! In the same vein, an automotive manufacturer might manage the configuration of automotive parts, or the blueprint diagrams of the parts checked into a document-control system.
Until you know the company culture (and sometimes not even then), there's no shame in asking "When you use that term, what exactly do you mean?"
This will likely generate discussion rather than a straight answer. That's fine; discourse and discussion will generate learning and understanding and advance your knowledge. The team might reach a consensus that you disagree with, but that can be okay. If so, drop the terms entirely and discuss what you mean -- what particular aspects of configuration management interest you currently.
Elements of configuration management
Version control. First and foremost, you'll want version control: the ability to check work in to some repository, retrieve it later, see who checked it in and when, and see the differences for its entire history. I'm not just talking about code here. Ideally, you'd have a project tree which allows you to store any documents that might lead to that tank-versioning problem: Requirements that might change over time, design documents (blue prints), perhaps the release notes for the software or its end-user documentation at that point in time. If accountability is an issue, store the project plans, to see how they changed over time.
Baseline and release information. Versions are great, but what was the last version actually released? What was the version before that? Most version control (and document control) systems provide branching or tagging. This allows you to point out the status of a version at a point in time. Beyond tagging, branching allows you to make changes to an old version of the document without inserting them into the current version. Most version control systems also include difference and merge tools, though they generally only support 'plain text' documents. Merging word processing documents can be particularly challenging.
Audits and reviews. One way to decide if a process is working is to audit that process; you might, for example, audit the configuration of those employer groups to make sure they are correct, or audit the designs to make sure changes in the design come from changes in requirements. This is extra work, but there are plenty of good reasons why you might want to audit, such as the case in which human life is at stake, money is involved, or the customer or a government agency insists on it in order to do business with them. Some configuration management software offers features that embed the audit workflow into the application, which lessens the pain.
Documented process. Version control, branches, audits and software may be great, but they won't work unless the team has an agreed-upon way to perform them. That's when process comes in, which is your team's promise as to how they will perform the work -- and the standard against which the audit will be performed. Several companies may offer to sell you a "cookie-cutter process" that conforms automatically to some external standard, while others like to document how the process "should be" instead of what the team actually does. Start by documenting what you actually do, keeping in mind that, if audited, you will have to do it that way every time. That may mean writing guidelines instead of defined process; "how tos" for specific situations instead of a detailed, prescriptive approach; and carefully weighing the cost of additional documentation.
Build, integrate and deploy scripts. Programmers like to produce a build in one step, testers like get the latest release to test, and operations folks like to deploy those builds easily. Build and deploy scripts are a double-edged sword; not only may your team need to “grow their own,” but without those scripts, most of configuration management is just fancy paperwork.
Provisioning and service management. Yes, the networking and system administration people do care about what box the Web-server is running on, what version of Apache it is running, what database driver it is using and whether the driver is compatible with the version that the production database is running. (And what machine is the database running on, and what version of the database software is it running, and what operating system, and ... you get the picture.) System Administrators will want a place to store all this information, IT executives will want the ability to see summaries of this data, and so on. If your company is looking to work on configuration management, you'll want to be very careful to know if this is included.
Putting it all together
Configuration management is an umbrella term for all the activities that reduce the risk of integration failure due to component change. That can mean any component, from the version of Linux on a server to a programmer building with an out-of-date specification to using the wrong blueprints to make a part on the factory floor.
Decades ago, there were full-time employees whose job was to create a physical library in which these documents could be checked in our out, or to create and manage the software to do this. In many cases, those people have given way to tools. Still, our challenge remains: to pick the right tools, use them in the right way, and balance organizational risk against complexity, process, and documents that may be overkill.
It's a tough configuration, but, well ... you know. Somebody's got to manage it.
This was first published in June 2011