The word is out about configuration management databases (CMDBs). Spurred by early adopter success stories, which often report an ROI of 200 percent, 400 percent, or more1, more than 65 percent of enterprise IT shops are currently in the process of implementing a CMDB solution2.
The benefits of a CMDB are many. Besides being billed as a must-have for IT Infrastructure Library® (ITIL®) adopters, a CMDB brings an attractive assortment of operational benefits, including improved service levels, reduced downtime, and fewer outages. These cost-saving advantages, along with the high cost of not deploying one, have incited companies to start CMDB projects.
There is, however, a flip side to this. A significant number of organisations have experienced disappointing results from their CMDBs. Why do some CMDB projects lead to discouragement while others generate demonstrable ROI?
Generally speaking, it’s not a CMDB’s technology that is insufficient, but rather, how it is populated. If the appropriate information model is not built into the CMDB before it is populated, it will fail—simply because it will contain massive amounts of irrelevant information. For CMDBs to be effective, they must be useful; they must be able to access data that answers business questions and solves business problems. CMDBs that are populated with discovery data alone do not function in this way.
Before an implementation effort begins, it’s important to discard misconceptions about the CMDB itself. If IT teams harbour mistaken assumptions about what a CMDB is or what it can (or should) do, it’s likely that its deployment will take a wrong turn.
A CMDB is not a “thing.” Organisations that believe this run the risk of not investing enough in pre-implementation planning, one of the chief causes of CMDB failures. Essentially, they become overly focused on the technology3 —presumably, what the CMDB will automatically “do.” As a result, their initial expectations for the CMDB’s performance typically run high.
A CMDB will not solve data quality problems. Many organisations rush to implement a CMDB because they believe that having a single source of record will eliminate issues with poor data quality. However, information is actionable only when it is 97 percent accurate, according to data management experts. To avoid misleading data --and an unreliable CMDB-- implementation teams must achieve continuous data quality assurance before, during, and after CMDB implementation.
A CMDB doesn’t have to contain every configuration item (CI). In fact, it’s unadvisable. Some businesses, believing they must store every piece of data in the CMDB, become overwhelmed with the notion of populating it. However, not every CI is appropriate for CMDB storage; accordingly, populating the CMDB cannot possibly be an entirely automatic, tool-driven process. IT organisations must determine which CIs are important to monitor for the business; these CIs belong in the CMDB and should be built into its information model.