In my most recent post, I wrote about good IT asset management. This post looks at what some could say is the reverse image of asset management, configuration management. Configuration management is about defining and maintaining information on all your IT assets and their overall relationship. With good configuration management you greatly reduce your business risk because you can more easily see the effect of any proposed change. Configuration Management and Configuration Management Databases (CMBD) obviously have been hot topics for several years because of the need for IT organizations to establish fundamental control over their IT infrastructure. Naturally, interpretations of configuration management can vary from company to company. Typically, people mean one of the following:
1) Loading configuration information for the service desk
2) Maintaining configuration information
4) A CMBD that includes configuration discovery of actual state and dependencies as well as the ability to detect configuration drift.
So users naturally have a lot of interpretations of what configuration management is. COBIT 5 suggests that IT organizations need to achieve both items 3 and 4. The configuration management function, according to COBIT 5, includes establishing configuration baselines, verifying and auditing the state of configuration information, and updating the recorded state in a configuration repository. The purpose of configuration management is to provide sufficient information about service assets to enable the services to be effectively managed, the impact of changes to be assessed, and service incidents dealt with appropriately. Simply put, these functions require configuration not only to be up-to-date, but also to be controlled and managed.
Goal for configuration management
To improve this process and reduce IT and business risk, COBIT 5 suggests IT organizations measure themselves against just one process improvement goal. This goal is that the configuration repository is accurate, complete, and up-to-date. Two metrics have been provided to determine whether this is the case: 1) number of deviations between the configuration repository and live configuration and 2) number of discrepancies relating to incomplete or missing configuration information. The first number tells you about how managed state and actual state relate to each other. The latter reflects either things discovered that are not recorded or the quality of the recording process as a whole.
So where should you start?
As always, my suggestion is that you start where the most immediate value can be driven. But if it were up to just me, I would start with the number of deviations between the configuration repository and live configuration. We need to drive deviations to a very small number if we are to increase the change success rate, to reduce security vulnerabilities, and to drive up availability and reliability. What do you think? What would be first on your list? I would love to hear back from you.
Blog post: Making COBIT 5 part of your IT strategy
Solution page: IT Performance Management
Solution page: Configuration Management Database
Solution page: Configuration Management
Solution page: Configuration Management Automation