The Perils of the CMDB

Configuration management is the hub of data storage and exchanges between the various ITSM processes. Groups looking to begin their ITIL journey often attempt to start with configuration management because of the siren song of the configuration management database (CMDB) coming from tool vendors. The truth is that configuration management would not be my first choice to begin with.

The goal of configuration management is to provide accurate and timely information to the other processes so that proper decisions can be made. ITIL v3 points out that an overall configuration management system (CMS) comprised of multiple databases can be assembled to provide this much-needed information in an automated manner. The software vendors have been pitching their wares for a number of years now in regards to how they can automatically collect and distribute data to aid customers in their ITSM efforts.

There’s a secret though that the vendors aren’t telling prospects – The CMS and component CMDBs can be rendered useless without the proper processes. In fact, the business needs have to be understood first, proper processes designed and then automation purchased or developed. The tools must support the processes and not the other way around. The lead-in should not be with tools.

Moreover, configuration management can be undercut if a critical process isn’t either implemented first or at the same time. The critical process is change management and configuration management can not maintain the integrity of the CMS without it.

Imagine a vast library filled with thousands of three ring binders that can be readily changed. Next, imagine that the librarians are tasked with managing the library and the contents of those readily modifiable notebooks. Last, imagine that anyone can walk in the library and remove notebooks and/or change them at any time without anyone knowing. Now, bear in mind that as the librarian you are responsible for keeping the inventory accurate in terms of what books are in the library, where they are located and how each book is configured. That would be disastrous right? A nearly identical situation will play out in regards to configuration data in the CMDB or CMS if change management isn’t present.

One of the responsibilities of change management is to govern the updating of configuration data. Whether the data is tracked manually or with automation, an effective change management process will help ensure that the data is updated appropriately whether it is tracked manually or in a CMDB.

Spiral of Death

This methodical updating is critical as all processes need accurate data. What will happen if the data isn’t timely and accurate is that people will stop relying on configuration management and the tools it provides. They will go back to their own spreadsheets and notepads in regards to how various configuration items are built, where they are located, etc. As they stop using the CMDB, the data will become even more inaccurate and a death spiral begins that ultimately results in nobody using the tool and the investment is wasted and careers potentially damaged.

The truth is that a great many software-led configuration efforts that emphasized the technical merits of the CMDB have failed abysmally because the process requirements weren’t understood and addressed appropriately.

In response to this, tools vendors reacted in an unsurprising manner: they created a technology-led solution called “autodiscovery”. The premise is that by using autodiscovery tools to identify new, changed or deleted configuration items in production the CMDB will be current and accurate thus overcoming all the process problems. Guess what? The results have been far from ideal because it still does not negate the need for processes.