This is one of the most frequently asked questions I get in my many interactions with people on the topic of CMDB.
The short answer is, “A CMS is possible, but the common model of CMDB is not.” I have even been challenged on Twitter that CMDB is nothing more than an endless time sink (follow glennodonnell to see the threads). Sadly, this is a common perception that is fueled by the many failures resulting from an unrealistic view of CMDB as a monolithic database.
Herein lie the real gremlins of the CMDB and the primary reason Carlos Casanova and I set out to write The CMDB Imperative in late 2007. Yes, that is his real name and yes, the book is now available from your favorite book retailer
The main problem with CMDB is the term itself. The right way to think about the configuration management database (CMDB) is not to think of it as a database at all. It is an organized collection of databases and other data sources that are very likely to be in multiple formats in multiple places in multiple tools from multiple vendors. Some may be in a home-grown Oracle database, some in an HP network management tool, some in an EMC storage tool, some in your HR database, etc.
A monolithic CMDB has several problems, most of them around the challenges of maintaining accurate contents. It might be good to highlight this issue with a little story.
My team and I built our first CMDB in 1986, although we didn’t call it a CMDB. We were too young and naïve and none of this had yet evolved to a reasonable point.
It was more an asset database than a CMDB. It was a decent model of our newly complex environment of distributed Sun workstations and servers, but it was a grand failure. We didn’t capture the many relationships needed in a real CMDB, although that was not our fatal mistake.
Our youthful naiveté led us to believe we could maintain its accuracy. It was all manual. We had no automated means to populate our CMDB to reconcile it with reality. We quickly abandoned it, but we did learn from that debacle.
Our “CMDB” failed because it was what many beleaguered CMDB are today – what I like to call unified ambiguity. These CMDBs are consolidated repositories, but the contents are of dubious quality. If you can’t trust your CMDB, you are in trouble. Your decisions are driven by the CMDB.
Good data yields good decisions. Bad data results in flawed decisions and sloppy execution. When you make the wrong decision, you need to go back and do it all over again, usually more slowly because you now also have to gather and verify the state of your relevant environment. In our book, we point out other flaws of the monolithic model, but unified ambiguity is the greatest curse against the CMDB.
So, if the CMDB is no good, what is a CMS and how is it so much better? ITIL v3 introduced the concept of a configuration management system (CMS) that finally abandons the notion of a consolidated data repository.
Instead, the CMS incorporates many CMDBs – what we should really call management data repositories (MDRs).
An MDR is a tightly focused information repository. It is not an attempt to build a model of the entire world. It maintains a view specific to its focused domain. You will have one for your network, one for your servers, maybe another for your virtual servers, one for your mainframe(s), one for your distributed applications, and so on. An MDR has two distinct benefits: it is fine-tuned for that domain and it is far easier to keep it accurate.
A network router has different attributes than a virtual server and a J2EE application is very different than a SAN, so it is best to have MDRs dedicated to each and tailored to reflect the precise model of each. A “one size fits all” model is a compromise, the proverbial jack of all trades and master of none. An MDR must be a master of one.
By restricting an MDR to a specific domain, we can keep it more accurate. Most notably, we can implement discovery technology to “learn the truth” about the domain. This has quickly become a key focal point of the CMS, especially with regard to practical solutions you can buy and implement today. With discovery, you can ensure a high degree of accuracy in this particular domain.
Each MDR can be its own pocket of the truth. Pockets of the truth are far superior to unified ambiguity!