Central to IT Service Management is the concept of a Configuration Management Database or CMDB. Throughout my career I have been involved in dozens of service management/helpdesk implementations and close to a dozen IT asset management implementations. As the service management processes defined by ITIL continue to be adopted as the de-facto standard in the US and around the world, my company is being asked to help other companies develop a CMDB. The ITIL process set, while becoming increasingly popular, is by no means a new concept. However, I have yet to come across an organization that can say they have an accurate CMDB. Why is something so critical to the ITIL philosophy, so difficult to adopt? Furthermore, is something so challenging worth the effort to implement? If so, why, and how should you go about it?

I believe there are a couple of primary attributes of a CMDB that make it very difficult to create and maintain. First, is the fact that a CMDB has a very broad scope. By definition, a CMDB should contain accurate information on every Configuration Item (CI) within the organization. The definition of a CI can be rather broad in that a CI can be any entity related to your IT Infrastructure against which change should be managed. For each entity that your organization defines as a CI there is a long list of attributes and relationships that must be captured and maintained. Therefore, simply defining the scope of a CMDB within your organization can be a massive effort.

Another huge challenge is the fact that CIs are typically owned and managed by numerous different departments. Maintaining accurate information on all these items, particularly the relationships, requires significant coordination and cooperation between these departments. Often, corporate management structures and cultures impede this necessary cooperation. The ITIL processes seek to break down these barriers, but doing so often requires significant organizational and cultural changes that tend to occur slowly.

It is typical for IT organizations to believe they can overcome these organizational and cultural challenges through the implementation of additional technology. Technologists tend to understand technology and thus are more comfortable tackling problems with technology than through process. This is probably one of the biggest mistakes any company can make, and yet it is repeated over and over throughout the US corporate environment. While technologies are emerging that claim to be able to automate the collection and maintenance of data for a CMDB, processes cannot be ignored. This is evident by the fact that the Configuration Management process, as defined by ITIL, has a direct link to every other ITIL process.

At the beginning of this article I intended to answer the questions of whether implementing a CMDB is worth it, and if so, why, and how to go about it. If you?re not already asleep, you might agree with my intent to get deeper into those questions in a follow-up blog. I will say this on those topics however to fulfill the obligation set forth in the first paragraph.

When considering whether to implement a CMDB review and consider the benefits as defined by ITIL. Determine which of these benefits will have the greatest impact and provide the greatest value to your business. With business objectives clearly understood you?ll have the direction you need to define the scope of your initial CMDB. This involves defining your CIs, the important attributes to maintain, and the critical relationships that must be maintained. Finally, focus on the process for obtaining and managing this data and not technologies. Technology should be sought to automate manual processes defined and implemented where possible; technology should not drive the definition of process.

—–