3 ways to approach configuration management

Configuration management is different to most things that we do in IT service management, because the benefits are all indirect. Practices like incident management and business relationship management are visible to our customers and deliver measurable benefits. Configuration management is mostly just visible to people within the IT organization, and the benefits come from improving how efficiently and effectively we do other things.

For example, if you are analysing an incident or a problem, you might need to know which components the service is using, and how they are inter-connected, to help you understand what’s happening. If you are reviewing a change you might need to know which services use the components you are planning to change, so you can understand the impact of the change.

Some organizations that I have worked with invest enormous amounts of money and effort in configuration management. They collect huge amounts of configuration data and carry out regular audits to ensure the data is valid. But often this data is not used by anyone, so all that effort is wasted. Other organizations collect far too little data, and don’t have essential information available when it is needed.

So how do you achieve a balance between wasted effort and insufficient data?

There are three very different approaches you can take to configuration management.  As always, each of them has benefits and disadvantages, and you need to blend aspects of all three of them to get the best value from your efforts in your own specific context.

1.     Traditional ITSM configuration management

The traditional approach to configuration management is to use tools to collect configuration data and store it in one or more configuration databases (CMDBs).  The CMDBs are usually stored in a tool that enables configuration data to be linked to incidents, problems and changes. Regular audits are carried out to ensure that the CMDBs are accurate, and discrepancies are investigated and resolved.

This approach can work well in a relatively static environment, but it is very easy for the data to become inaccurate over time, and inaccurate data may be less useful than no data at all! If people don’t trust the configuration data, then they stop using it altogether and the investment in configuration management is completely wasted.

Over-reliance on tools can also lead to the creation of a very technical CMDB, which only stores the information that tools can collect. This omits vital data such as who is responsible for a component, which services use it, and so on. This may become very problematic in large organisations with frequent staff changes where it can result in no one knowing what a component does or how to implement a change to it. In one organization where I worked there was a network link to a supplier that needed an upgrade, many groups used this link, but nobody appeared to be responsible for it!

2.     Collect data when you need to use it

An alternative approach is to collect configuration data when you need to use it. For example, if you need to know whether or not your servers have a particular version of software installed you could simply look at all your servers to find out.

This approach has a very low overhead, because you never collect information unless you need it, and you only store the information while you are using it. It works well for data that is easy to discover, but it relies on being able to collect exactly the information you need exactly when you need it. For example, if you want to know how many software licenses are being used on laptops you can only discover this for laptops that are currently connected to your network. As a result, you may undercount, which may mean that you can’t demonstrate that you are meeting your license terms. This could prove very costly.

3.     Use the configuration data to create the component

The third approach is to manage configuration data like software. You plan and review changes and then check them into a code repository which automatically creates the component. You may have come across the term “infrastructure as code”, which uses this approach to create virtual servers, storage, and networking components.

This may sound similar to the first approach I described (Traditional ITSM configuration management) but, in fact, it works very differently. For example, if you have a rapidly changing environment, then this approach ensures that your configuration data always matches the actual components, as the only way to change components is to change the configuration data first.

Which approach should you use?

All three of these approaches to configuration management are appropriate for EVERY single client where I have worked recently. The trick is to design your own blended approach which uses the right technique for each type of data that you need. The best way to do this is to start by asking questions like:

• Who needs configuration data?
• What do they use it for?
• What data do they need?
• When do they need it?
• How accurate does it need to be?
• How easy is it to collect the data when it is needed?

Don’t just ask your own team, reach out to anyone who might have a need for configuration data and talk to them. When you know the answers to these questions you will be able to design a solution that works for you.

If you get this right then you will have access to the data you need, when you need it, with a level of accuracy that works for you. If you get it wrong, then you may create a very expensive repository of unhelpful and inaccurate data that nobody wants to use.

If you currently only use one of these approaches then have a think about how you could use the others to add value to your own operation, if you are already using a mix then why not review what data you are collecting, and how. You may find that you can optimise how you use the various approaches.

Image credit: Bennett

This work is licensed under CC BY-SA 4.0