These discussions almost always come back to questions about how this thing called a CMDB looks. How is it built? What tool(s) do I use? Which "database" is best? There are many more.
My first response is usually, "I hate the term CMDB, so let's try to kill it off in favor of the ITIL v3 notion of a CMS." If you pursue a CMS (configuration management system) as opposed to a CMDB, a few things become evident:
- The CMS implies a distributed (federated) model consisting of many management data repositories (MDRs). Each of these MDRs hold data relevant to the scope of coverage for the tool that encompasses that MDR (e.g., a network discovery tool is a network domain MDR and an application dependency mapping tool is the key MDR for the application domain).
- While a CMDB can certainly be formed in a similar federated fashion, the term "CMDB" has become tainted by the implication that it is a database. The natural assumption here is that this database is one big monolith that holds every detail being tracked. This is unwieldy at best and almost always destructive.
- The CMS has a more complex structure, but because it enables a divide-and-conquer approach to the overall system, it is a more pragmatic approach. You can bite off each piece and gradually build out your CMS. A "big bang" is not needed and certainly not recommended.
The single most important requirement of configuration information is its accuracy. If it is accurate, the decisions that depend upon it have a high probability of success. If the information is inaccurate, those same decisions will be flawed and the resulting actions will fail. They will need to be redone with more effort the second time, further exacerbating the stereotype that IT is incompetent and wasteful. Inaccurate data is not just useless, it's dangerous.
The CMDB or the CMS must represent the truth. This is the real bottom line. This truth reflects the world as it exists, not how we wish it to exist or think it exists. The truth is the truth and there is no other interpretation or fabrication that matters.
The MDRs in the CMS represent pockets of the truth that can more easily be kept accurate. For now, only the most progressive leading edge adopters of service management principles have successfully federated these MDRs into a more complete system. Enterprises like Procter & Gamble demonstrated some notable success here, but for most others, federation remains an aspiration still a bit out of reach. This will change as standards such as the DMTF's, CMDBf, and CIMspecifications gain acceptance. For now, the pockets of the truth will be isolated pockets of the truth.
We keep the pockets accurate through a combination of automated discovery, solid change management, and good process design and execution. These are mandatory, but I am a big fan of discovery specifically because it is generally easy. You need not be a paragon of process rigor to do discovery right. The automation provided by the tools allows nearly any organization to capture their pockets with a high degree of accuracy. Naturally, you still need to refine your processes, but discovery can help immensely in these initial stages, as well as for ongoing consistency.
The monolithic CMDB is what I call unified ambiguity. Everything is in one place, but any trust in its state is dubious. The likelihood that the CMDB is an accurate representation of the truth is almost guaranteed to be zero.
Isolated pockets of the truth are far better than unified ambiguity! Whether they are isolated or unified, pockets of the truth yield great insights because they are the truth. They also form the foundation for building federation step by step. Because discovery makes it easy, these pockets are within reach of anyone. The simple act of capturing pockets of the truth is a huge step forward in the ongoing journey toward operational excellence.
How are you doing? Have you tried CMDB? Can you trust it? Were you successful? Is your effort closer to the CMS than the CMDB? Please share with us!