Every company needs a configuration management database (CMDB). Having an accurate record of the current configuration of the infrastructure is fundamental to every IT activity and process. Troubleshooting is faster, compliance auditing becomes a breeze, analyzing resource allocation is easier, and infrastructure changes produce fewer service outages that end up as front page news.
However, not every company needs the data-warehouse version that stores every conceivable piece of infrastructure information in a single place. Any organization with plans for implementing such a thing in one shot is not interested in solving IT's challenges. Rather, it is really auditioning for a disaster-oriented reality show.
The question "do we need a CMDB?" is not the best starting point. It is important for IT managers to recognize that CMDB is just a tool, not a magic seed that sprouts overnight into a tree bearing an abundance of ROI-fruit. CMDB is a technology that stores the right level of infrastructure configuration data people require to get something done. To be successful, a CMDB must be implemented in the context of achieving specific goals. The right starting point is a project determination process that should involve the following:
- Prioritizing IT issues according to business impact.
- Determining which IT processes are involved to address the issue.
- Creating a list of all the people that will be involved in those processes.
- Determining the type and currency of data each person needs to complete their part of the process
The first step is important because any project that potentially spans different organizational groups requires executive buy-in and leadership to keep it on track. The more visible the business impact is to key executives, the more support the project will receive. This step also determines the metrics that must be used to gauge the success of the CMDB project. Make no mistake. Success must be documented in terms of improvements to the business.
The process determination step is important for limiting the inevitable scope-creep of any IT project. CMDB projects are particularly prone to creep because a CMDB is the foundation on which every IT process rests. Thus it is very easy for folks to start adding on additional considerations for related issues and processes. Once those add-ons start, it is hard to stop and disaster ensues.
The discussion of who is involved in these processes is also critical because this project is really about improving and streamlining collaboration. Each of these individuals must experience the benefits of the CMDB implementation, otherwise expect adoption to stall.
Once the processes and people involved are determined, the focus shifts to understanding the information needs and recentness of the data. This will shape the CMDB technology requirements. For example, consider a small IT shop with application troubleshooting problems because new software is continually being deployed. Their CMDB solution must constantly and automatically track, in excruciating detail, application configurations so that quick configuration comparisons before and after a problem can be observed to identify root-causes.
The situation would be different for a very large IT shop with the same application troubleshooting problem. The resolution process would span helpdesk staff, multiple infrastructure experts, a customer relationship manager and a line-of-business manager. For this organization, capturing all configuration details in the CMDB doesn't help the coordination effort. Instead, they decide that it's more important to share infrastructure relationships across the team. Their CMDB should house only the most basic device configuration data, relationship information and pointers to sources of more detailed information.
While these two CMDB implementations are radically different, they both provide the benefit the business is looking for – shorter application troubleshooting times. IT organizations that take the time to prioritize their process improvements, consider the people involved and determine their actual data sharing needs will get a good understanding of the type of CMDB implementation that will be successful.
ABOUT THE AUTHER: Jasmine Noel is Founder and Partner of Ptak, Noel & Associates. She has served as director of systems and applications management at Hurwitz Group and was a senior analyst at D.H. Brown Associates.
