CMDB is crazy talk
The CMDB debate seems endless, sisyphean. The analysts promise "Well OK CMDB crashed and burned but CMS is different. Really." The vendors know they're flogging a dead horse and they'd much rather prance about the service catalogue instead, but they have to get their R&D money back so they bang the CMDB drum. Here's my case summarised again (under recent provocation), for those who haven't read it before.
I made this summation comment over on Craig Wilkey's "thoughts" blog when arguing the issue with him:
I think, as is usually the case in IT debates, we must define terminology.
A CMS (and its subset, a CMDB) is a tool for assessing impact on services by using relationships from those services to other CIs. The CMS holds all the relationships and all the CIs, the CMDB holds some of the relationships and/or some of the CIs, but both relate CIs to services. No services in the data? Not a CMDB/CMS. Relationships don't (directly or indirectly) lead to service? Not a CMDB/CMS.
if we don't agree on that definition then we're gonna argue forever. And if we let any more general sort of data be a CMS or CMDB, why have a term for it? "Database" will do.
by that definition, there are many other buckets of CIs that are not a CMS or a CMDB. My position: to grow those buckets of data into CMS or CMDB and keep it current (all the discovery and integration and federation and reconciliation and audit and manually maintaining service links because at that level of abstraction there is no other way but manual) is not the best use of scarce funds in 95% of organisations. The few who can get a business case sensibly approved are the 5% Club.
For the other 95% we do what we do now: when asked for the impact, we draw data from buckets to deduce the impact. That's a process. Our job as ITSMers is to optimise that process. After we've worked on the culture, the ownership, the skills, the training, the policy, the process, the procedures and the runbook, we'll be a lot faster at impact assessment than we were before. Then we apply technology to address the remaining bottlenecks and sources of error (efficiency and effectiveness). We start with simpler technologies to assist in finding, extracting, analysing and reporting the data. if we still aren't accurate and fast enough after that, it's time to think about a CMDB. But even then, there are good odds that there are more pressing needs for the money and we'll just have to live with being less perfect than we'd like. If it's still a good idea, we've just joined the 5% Club.
[And you know what? I bet we still need those manual processes even after we automate impact assessment. Because nobody trusts the automated result because the data is never perfect. If the answer matters, I bet you still sanity-check what the tool tells you.]
This CMDB talk is all technical autoeroticism over an obsession with perfect information. Geeks just can't cope with living in a world of imperfect information. The faster the rate of change, the less perfect the information. Deal with it.
Sure, in the future CMS will be more important. From a <5% base. It has a long way to go before most of us are involved. Building one now is an irresponsible diversion of resources for most of us. You 5%ers can go play with your super-technology - we envy you your toys. Just stop feeding the vendors and analysts when they insists everyone needs a CMS. That's crazy talk.