Living without CMDB
This article has been podcast
CMDB is positioned as the key underpinning foundation to ITIL:
Configuration Management provides the foundation for successful IT Service Management and underpins every other process. The fundamental deliverable is the Configuration Management Database (CMDB) [Ref 1]
This is wrong. It is a peripheral nice-to-have. In a previous blog we discussed how it is currently an infeasible nice-to-have. Let's talk about doing without it.
There is a boundary problem to CMDB: no matter how good your CMDB tool and processes, there will always be CIs that matter to your environment but are outside the reach of your CMDB: closed proprietary databases, service providers’ networks, itinerant devices that attach casually, paper documents… So if you are going to have to interface from your repository to another somewhere, what does it matter where? i.e. if you have three repositories, each holding 33%, how is that worse than three holding 90%, 5% and 5% respectively? So lighten up and learn to love mentally reconciling and integrating data from multiple sources.
But what shall we do with no single universal CMDB? What we always did, though ITIL asks us to do it better. Only people can really analyse impact. Only people can reconcile conflicting information. Only people can deduce how complex systems will respond to perturbation. No tool is going to have the smarts to do what ITIL asks of Configuration Management in the foreseeable future. The functions of Configuration Management that are defined or inferred in the process are people functions. Stop trying to automate them [sorry Frank]. ITIL is about improving process, not throwing technology at the problem.
Go on, prove me wrong. Prove a tool can do those functions as well as a person or better. Set up a complex environment of integration, reconciliation, synchronisation and whatnot to give a single virtual view over data from umpteen sources. Then measure the amount of work invested to buold and maintain that versus the work to manually do it ad-hoc as required. Then propose changing something in the Citrix load-balancing and check the impact analysis from the tool against the impact analysis from Ralph the sysprog. Use your new tool to drive automated notification and SLA impact reporting, then stand back at your next Priority 1 outage and see how much it gets right; who gets called, what turns red?
People are doing fine without CMDB now. Look at the statistics for implementation of ITIL processes: Configuration Management is always one of the lowest percentages. For example, Incident-Problem-Change works fine on top of a single asset database with basic “depends on” links from key services to essential objects. Whether Availability or Release or Continuity or Financial or other disciplines use the same repository isn’t actually that important.
We desperately need some solid research on ITIL. I would love to know what proportion of CMDB projects have shown a positive ROI. How many have caused a measurable change in the effectiveness of other processes? And even when something positive is measured, how much of that stems from the presence of a shiny new repository, and how much from people focusing on Configuration processes? I argue you could re-engineer your processes using astrology instead of ITIL and you would see a positive result. Any process benefits from some attention. But that is yet another blog…
It is nice to store those basic “depends on” links to show the key CIs that services depend on. My experience is that organisations can manually maintain these service mappings for about ten to fifty services. Yet most have two to ten times that many services. They all seem to end up pragmatically picking the top services to store the mappings in the database. What happens to the rest? They wing it; they work it out on the fly; like they always did. It works.
Neither relational database, datadictionary, repository, nor directory succeeded in unifying our environments. Nor will CMDB (nor Web Services nor SOA nor .NET nor …). I have spoken previously about how so many of us in process methodologies and operations delivery tend to be anal obsessives. Lighten up and stop trying to find one repository to rule them all. Let our data be untidy. Let go of that old “everything has to be complete and correct” mindset. Live without CMDB.
1 An Introductory Overview of ITIL, itSMF, 2004