Over the past 5 years as an ITSM Consultant,  I’ve been involved in hundreds of customer engagements designing and implementing ITIL processes including  Incident, Change, Problem and Service Request Management.  While thinking about my subject matter for this post it dawned on me that although most ITSM tools today offer a Configuration Management Database (CMDB) component, it’s a rare engagement that includes it. When you look closely at what a CMDB is and the value that a properly designed and implemented CMDB brings to the overall ITSM process, you have to wonder why it’s not the first process to be implemented. OK, I’m being a little facetious here because most of us in the ITSM business understand that the creation of a CMDB today is a very large, expensive a time consuming manual effort, even with the advent automated discovery tools which I’ll touch on in more detail a little later in this post. So it becomes a classic chicken or egg scenario and the CMDB almost always looses out. 

To get my point across I’m going to focus on the relationship between  Change Management and the CMDB in this post. So first lets level the playing field with brief ITIL definitions of Change management and the CMDB. 

Change Management:  “ITIL Change Management aims to control the lifecycle of all Changes. The primary objective of  this process is to enable beneficial Changes to be made, with minimum disruption to IT services”. 

Configuration Management Database:  (CMDB) “is a repository that acts as a data warehouse for information technology (IT) installations. It holds data relating to a collection of IT assets (commonly referred to as configuration items (CI), as well as descriptive relationships between such assets”.

So now that we have both definitions in front of us, it’s clear that Change Management is all about mitigating risk to the IT services that support the business. So doesn’t it also make sense that the performance of a true and accurate assessment of the risk must involve an understanding of the other IT components (CIs) related to the one effected by the change? Absolutely, and herein lies the problem. Without a CMDB to perform an impact analysis of a change against the infrastructure, we are pretty much relying on somebody’s spread sheet, Visio diagram or maybe what’s in the network administrators head to determine the true risk.  

So here we go again with the Chicken or egg analogy. Without a CMDB can we truly  claim to have  implemented a change management process that fully supports the goals of the organization? On the other hand can the organization afford to take on the magnitude of a CMDB project? My opinion is NO to the first question  (but then again something is better than nothing when it comes to Change Management). Regarding the second question, well that depends on how important the CIO regards the issues I’m pointing out and of course budget always plays into this as well. 

I always feel obligated to have the CMDB discussion with Customers that are implementing a change process. I find that it’s not necessarily that they don’t understand the value of a CMDB and risk involved in not having one, but it always boils down to cost and effort involved in a CMDB initiative. Don’t get me wrong, there are companies that have implemented a CMDB but they are rare. The issue those organizations face is now the manual effort of keeping it up to date.   

The future of the CMDB 

So what is the answer to this dilemma? I believe it will be the advent and acceptance of automated infrastructure discovery tools to automatically populate and maintain the CMDB. Discovery tools have actually been around for quite some time but they are mostly niche type tools, for example SolarWinds for discovering the network infrastructure. Another example is a Data base discovery tool from IBM. These are great but they don’t solve the entire problem. What is really needed here are automated Infrastructure and dependency mapping tools that are much more holistic in nature. By this I mean they are able to discover and map the dependencies between all components of the infrastructure including the network components, the servers connected to the network components, the applications running on the servers, the databases being accessed by the applications and on and on. With this type of tool feeding the CMDB we will then be able to conduct true Impact analysis as part of the change process. 

Over the last few years these types of tools have been evolving but I believe acceptance is not there yet. Such a tool is ADDM from BMC software. 

With these types of tools in place the true potential risk of a change will be exposed causing  change managers and Change Advisory boards to look at some changes in a different light, rejecting or delaying changes until for example more stringent testing has been done or insisting on more detailed back out plans. The end result – fewer outages and fewer Incidents opened with the service desk. 

 

About the Author

Gary Guglielmo is an IT Service Management Consultant with Flycast Parters, INC. With over 6 years experience working in the IT Service Management industry, Gary has extensive knowledge of IT Service Management principles (ITILv3) and process improvement techniques. As a consultant for Flycast Parters he has conducted hundreds of Implementations of BMC Footprints service Desk and BMC Client Management solutions including Incident, Change, Request and Asset Management processes.