Config management: Enemy of agile approach or the reason it WORKS?
Ch-ch-ch-ch-Changes (turn and face the strain)
David Norfolk is practice leader with responsibility for development and governance at Bloor Research International. He is on the committee of the BCS Configuration Management Specialist Group.
Configuration management (CM) is the management of configuration items (CIs), which are the things that you care about, the things that are essential for delivering an automated business service.
CM is not just about software, although software CM (SCM) is important – you care about building your production systems from the right versions of its various software components – but you also care about running them on the right hardware or on the correctly configured virtualisation image.
A virtualised machine image might be a configuration item and you might want to ensure the the image used in production is configured to be the same as the one you use in test – or your testing won't be worth much.
But the business may want to put phone lines or desks, or even toilets under configuration management if they are essential to delivering a business service (adequate toilet facilities are a statutory requirement for a call centre). What you consider to be a CI is a business decision around ensuring reliable service delivery.
CM was originally an engineering discipline, formalised by the US Airforce for managing pieces of hardware material over the lifecycle of the systems they made up.
Today, cutting-edge CM is exemplified by fully automated provisioning of cloud services such as Amazon Web Services or Google Compute, where you deploy a standard configuration and then make specific changes for your environment.
Its disciplines are also related to implementing BIM (Building Information Modelling) approaches to designing buildings and Building Management Systems – computer-based control systems that monitor and manage building systems such as ventilation, lighting, power, fire prevention, and security and can make all the difference to maintaining safety, comfort and power efficiency as the building is used and maintained.
If you ask to buy CM, some vendors will try to sell you something called a Configuration Management Database (CMDB). But implementing CM is really not the same thing as building a CMDB, and if you think it is, you will probably fail.
The CMDB is simply a database (or federated set of databases) that holds information about CIs and their relationships. What really matters is the CM process, that uses the CMDB (or an equivalent data-store) and that involves people.
Configuration management is sometimes confused with change and version management and these are all related - practitioners often talk about “configuration, change and release management" - but they aren't all the same thing.
Pure change management is mainly about ensuring that a particular change is formally authorised, properly assessed for impact and adequately planned. CM ensures that related changes go through at the same time, that the business is in a position to use the changed system, that the change specification is correct and deals with the correct CIs and the correct versions of these CIs.
In practice, “simple” change management usually includes (formally or informally) a bit of CM too. What makes full-blown CM different from change and version management is that it's at a higher level and manages whole systems, and relationships between the changes to CIs.
It is worth remembering that CM shouldn't be seen as a disconnected silo or as an end in itself – it only matters if it helps to deliver a business outcome. Automated asset discovery over a network can let you document a lot of assets (although it will probably miss some too) and call them CIs – but if no one uses them, managing them is just a waste of resources.
CM is sometimes also seen as the enemy of agile development - but what is the point of deploying a new system quickly if, for instance, it backs out an important emergency fix for a compliance issue - and your business is promptly shut down by the regulators?
The secret is “just enough” CM to let the business operate reliably
Good CM is actually fundamental to an agile approach like DevOps at scale and should be built into the process – the secret is having “just enough” CM to let the business operate reliably, even if you don't bother to actually call it CM. What can CM do for you?
CM lets you sleep at night. When you have a major production release, SCM ensures that an old module isn't included in the build, letting a problem that you thought was fixed come back – and resulting in you getting a support call in the small hours of the morning.
When the auditors dictate that a certain procedure must be followed when a new system goes live, or the regulators will shut down your business, CM is what ensures that the new procedure goes live at the same time as the new software does.
CM is what ensures that an "automated building" such as The Shard operates effectively, economically and safely. CM is what ensures that the software and graphics and human voices behind a film - Avatar, say, - are all in place when the film is released. So, CM is about a lot more than just managing software.
Technically, that's what is known as a cock-up
What sorts of things happen if you don't have CM? Imagine you're a retail chain and it's the run-up to Christmas and you have a small fire in one of your London premises. It gets put out quickly, but there's a small server that doesn't come up afterwards. No big deal either - it's going to be decommissioned next week anyway.
Then you discover that you can't process Chip and PIN cards in your Oxford Street stores. And people are finding workarounds with credit card info that probably put you in breach of PCI DSS security standards - and that can be serious.
Then you hear that your credit card processing isn't working in Paris either. And no-one knew that all European credit card processing services were critically dependent on a server in London that didn't do anything much else that was important - as far as you knew.
Technically, that is known as a cock-up. It's also a probably a configuration management failure - effective CM keeps track of the things necessary to deliver a service and the relationships between them; and documents this accessibly.
Effective CM can save you money because it reduces rework (you are less likely to have to back out a deployment and repeat it) and because the chances of production problems are reduced. Effective CM actually allows you to take more risks – because CM gives you a firm foundation on which to manage risks.
CM is so useful for the reliable operation of a business that you're probably doing it already, even if you've never heard of the term; although if you haven't, you're probably doing it informally, somewhat unreliably, and inefficiently.
In most IT-driven businesses, there is probably someone (perhaps in Ops), with a brain the size of a planet, who keeps all the changes and their relationships, and any required hardware implications in his/her head.
This can be a cheap and effective approach – but it is very high risk compared to implementing CM formally. Suppose that that key person makes a mistake, gets ill, leaves for a better job, or simply gets fed up with being on-call to sort things out 24x7 …
Where do I find out more about CM?
A good starting place to find out about CM in practice and its benefits, is to attend meetings of the British Computer Society's Configuration Management Specialist Group BCS CMSG. You can usually attend as a guest - for a while)
The site supplies webinars and other materials on topics of interest online, but if you attend meetings, you get to meet practitioners and can ask them face to face about your real-life configuration management issues.
Vendors of configuration management tools supply a wealth of useful information free - as well as paid-for consultancy. This won't usually be entirely altruistic, of course; so it's best to know the basics, so you can discuss your needs with a vendor on fairly equal terms.
And don't neglect ITIL, even if you don't buy into all the books and take the training. It embodies a lot of "good practice" taken from practical implementations - and it's a very good place to get vendor-independent definitions of CM-related terminology.
ITIL introduced the Service Knowledge Management System (SKMS) and the latest CM thinking is maturing to focus on using information and knowledge to gain insight and support decision making - its best practices will evolve further in the world of virtualisation and DevOps.
A good place to get help in putting Configuration Management in the context of everything else to do with Service Delivery is the, fairly short, book "Introduction to the ITIL Service Lifecycle by Antony T Orr of BMC Software (there's a review of this as "the missing ITIL manual you always wanted").
In the end, CM is simply good practice for managing complex and business-critical systems, in situations where you actually care about reliable service delivery. ®
Sponsored: DevOps and continuous delivery