Principia: Power from Simplicity

The advent of the ‘cloud’ and the idea of massively distributed systems (think grid computing and SaaS) is the latest technology swing with the potential to impact configuration management practice. I say ‘potential’ because a properly designed and implemented configuration management system will be able to copy without too much difficulty. The main impact will be procedural and technical, the underlying configuration management process will remain unchanged.

A properly designed CM system will be able to handle any IT system environment. Problems only occur when you are married to the idea that centralised control of CM data and centralised change control are necessary for CM, or that a specific development process is integral to CM for it to function correctly.

It is an all too common mistake to design your CM system as a part of another process. For example, adopting a particular software development process and then designing your CM system into this development process will result in a CM system that is inextricably linked to the development process.

At this point some of you may be protesting that this is not a bad thing. Wrong. It is unnecessary, bad practice and lousy system design.

The irony is that many people who design their CM systems as integral parts of their development process are the same people who would be appalled if they saw such poor design in their software systems. They are effectively designing their CM system as a tightly coupled aggregate to their development process when it should be quite separate.

A CM system should be designed with clear interfaces that can be used by any other process. These interfaces should include:

• Change control – although change control is identified as a part of configuration management, it is preferable to maintain change control as an independent process that interfaces to the configuration management system.
• Query and reporting – getting information out or the configuration management system must be performed through a clearly designed interface.
• Configuration item references – a clear and unique method of referencing any CI in the configuration management system must be provided.
• External references – the configuration management system must be capable of unambiguously referring to any entity held outside the CM system itself.

By maintaining a clear interface like this the configuration management processes are insulated from any change to other processes in your IT development and operation.

Maintaining a consistent set of well defined interfaces also allow you to create a configuration management system that can be easily replicated across your organisation. The same configuration management process can be given to each of our organisation’s development projects for example. Providing the configuration management processes have been well designed with clean interfaces they should all freely inter-operate and, from the organisation level, will look like one coherent sytem.

When you need to extend your configuration management system beyond the boundaries of your organisation (for example, when interfacing with a service supplier or third party developer) all you need do is ensure that their configuration system presents your internal organisation with your interface. This can be achieved by either agreeing with the external agency that they will use your process or by creating a facade that will take present your interface internally but communicate with their systems externally.

Although his might appear complex it is not and it pays dividends by ensuring your configuration management system is easily to extend and will interface with all your existing processes.