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.

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.

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.

A fairy doesn’t appear at 2 A.M. in the data center and magically change configurations and move equipment. The fact is that someone made those changes and it is to everyone’s benefit to understand why. Simply pumping the changes blindly into the CMDB with autodiscovery is a recipe for disaster.

You may wonder why this is the case. Let’s think about it for a moment. If an IT service were perfectly designed and implemented then, when a service went into production, no changes would be needed. The reality is that there are many reasons that changes will be needed ranging from responding to business needs, security patches, technical issues, etc.

We also know that 70% to 80% of network availability issues stem from human error. We need change management to ensure that risks are properly managed and that the CMDB can aid everyone to understand what has changed and why. We can drive down MTTR by enabling resolution teams to more efficiently and effectively answer the question “What changed?” and the answer and background data will ideally come from the CMDB.

If we just use an autodiscovery tool to load all detected changes into the CMDB we risk not knowing why a change transpired and if it was properly authorized, an error or something malicious in nature. Thus, even with autodiscovery, there must be a process that governs its use to make sure that risks are appropriately managed and that the CMDB correctly reflects the current state of the environment.

In summary, beginning an ITSM effort with the implementation of a CMDB because software was purchased is a very perilous path as there is no guarantee the software will meet the needs of the organization. Furthermore, without proper processes the investment is liable to be a tremendous waste of time. To make a broad generalization, organizations seeking to begin their journey are strongly urged to begin with change management or the combination of change management and configuration management. This will ensure that risks are managed, updating of the CMDB is governed and the organization truly benefits.

George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.