I was speaking at a Unicom workshop a week or so ago. We were exploring two new freedoms - Cloud and Agile - and wondering how the business was going to assure itself (without compromising agility) that what was going on was broadly in line with with what it (or its shareholders) wanted to do. I was speaking about Configuration Management (CM) - you can find my slides at the event URL above. If you get a chance to get to one of these workshops (I think Unicom is going to repeat it), it's well worth attending, I think.

I've now met two problems with CM, underlined by a useful heckler at the meeting. The first is, "what on earth do you call it?" The second is, "what's its scope?".

The first should be easy - Jim Jones, of Perennius Ensemble (who was speaking about IT healthchecks) points out that Configuration Management (CM) was defined by the IEEE back in 1990 (IEEE Std 610 - 1290) as: "a discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements". More recently, and more succinctly, ITIL defines it as: "the process responsible for maintaining information about configuration items (CIs) required to deliver an IT Service, including their Relationships". A CI in ITIL is: "any component that needs to be managed in order to deliver an IT Service....[for example] IT Services, hardware, software, buildings, people, and formal documentation such as...SLAs". Both definitions are broadly equivalent and I'm happy using the term "configuration management" - as it has an independent provenance. I'd probably see a CI as something important to delivering any service, not just an IT service - but the distinction is moot these days, as most, if not all, business services now run on software; business services are, effectively, built on IT services, although they'll involve manual processes too.

The second, related, problem is that, as was apparent at the meeting, some people confuse configuration management proper with software configuration management (SCM) and think it only applies to source code. This is clearly not part of the definitions quoted and is often counterproductive. In a previous life I have met a banking service which was "completely" (as far as its software and databases were concerned) recreated in a hot recovery data-centre - a practical configuration management issue - only to discover that the local telephone exchange couldn't provide sufficient phone lines for the business service to operate. CM applies to everything critical to providing a business service - including critical phone lines - and cuts across the IT and business domains.

Partly to address this scoping issue, Perforce (a leading vendor of CM tools) wants to talk about "versioning" (instead of CM) - its "versioning ecosystem" is used to manage the automated business of the NYSE and pictorial elements of films and computer games. The trouble is that people who confuse CM and SCM also confuse "versioning" with "version control" - and CM is a lot more than version control. In fact, the opinion was expressed at the Unicom workshop that CM has nothing to do with versions because "the CM System just gives you the right code, automatically; you don't need to know what version it is". Well, from the programmer's point of view, that might be true, but (as we said) CM deals with more than source code.

In any case, from a business perspective, the business probably needs to be able to talk about, say, AsiaPac operating on Version 1 of the Global Banking System, while EMEA is on Version 2, even if it also relies on CM to keep both versions operating concurrently. And, of course, the version numbers need to be traceable back to (possibly slightly different) business requirements. It would be nice if everyone could always use the latest version of a system, but in a large global enterprise, this may not be possible at any given point in time.

So, I asked Mark Warren (EMEA Product Manager, Perforce) to explain Perforce's idea again. He points out that version management is important to resolving disputes and compliance issues: "a key part of the 'management' aspect is not just what will happen, but also what has happened," he says, "so the state of a system at a given point in history is critical for audit purposes as evidenced by the NYSE usage of Perforce that you referenced; this isn't just good practice but also often statutory". I agree - CM is about a lot more than just getting the right code at the current moment. As Mark goes on to point out: "in the business world, a HR department should version manage a contract of employment as the conditions of employment vary over time and it's really hard to keep track manually today but it's critical to be able to recover the historical versions in a dispute. The same is true when considering sales contracts which are continually updated during negotiations. For consumers, the need might be when "tweaking" the latest family snapshot, editing a home movie or updating the family budgeting spreadsheet. As Christopher Seiwald [Perforce's founder] has said to you, the consumer understanding of version management is about where IT was 30 or so years ago and for these users, I think the concept of "versioning" and "version management" is more approachable than "configuration management."

So, where does this get us? Well, while I applaud Perforce's intent, in renaming CM as "versioning", I still see people being confused. I'm afraid I still like the term "configuration management", which (as we've seen) has an agreed, vendor-independent definition. However, whatever you call it, it's important for everyone to realise that CM is fundamental to good governance of business systems and applies to a lot more than just software code. If that realisation becomes common as a consequence of "versioning", I'm sure I'll learn to love the term.