Top 10 reasons NOT to implement CMDB
This article has been podcast
OK I'll bite. One of the nice folk at Evergreen, Jill Landers, posted "Top 10 reasons to implement a CMDB". I'll do the right thing and not quote it in full here so you need to go read that first. Then you can enjoy my "Top 10 reasons NOT to implement CMDB"
- You would improve overall release, change and configuration management if only you could bring all configuration items and transactions under centralized change and configuration management control... but you can't. I've discussed the CMDB boundary problem before: No matter how much you store in a central CMDB repository, there will always be some data somewhere else.
- You might automatically discover and map all key applications, computing and network IT infrastructure with sufficient technology and enough investment in its implementation and constant adjustment, but you won't autodiscover the most important information: the relationships of CIs to services and to people (ownership, key users, escalation paths...). That's manual.
- Having all the data in one place is nice to have, but the actual improvements in efficiency seldom outweigh the enormous investment to get there. Geeks love tidy data, but geeks don't have to pay for it. We've been chasing this "one ring" myth of unification since relational database, through directory, repository, corporate data model, middleware, Web Services... Give it up.
- Because the essential CMDB relationships (and much of the data) must still be maintained manually, CMDB is as error prone as any other source. After it gives the wrong analysis a few times people stop trusting the machine and go back to asking or at least checking with the guy(s) whose head was the CMDB before the expensive technology came along. CMDBs don't reduce risks, they just change them.
- CMDBs have nothing to do with enforcing compliance. Auto-discovery will detect a few instances of non-compliance such as unauthorised devices connected to the network but you don't need a CMDB for that, just the autodiscovery tool that comes with most systems management tools these days.
- Application Management is all about code. While Change Management may store its Releases and Changes in a CMDB, the code entities are managed in specialist Software Development LifeCycle tools. CMDB plays little part in coordination across The Wall, the divide between development/solutions and delivery/production/operations.
- Even Change does not need a CMDB. It needs its records of Changes so it can manage change, and report on MACs and other statistical information. It can do that in happy independence from any other system or process if you want to. Most sites do.
- The only part of CMDB it is hard to do without is the view of a Service. Somewhere you need to document this. So do it. Use a handy tool such as a Systems management visualiser, or a Service Catalogue tool, or Visio or anything really, and document the relationships between Service and its important CIs. The best place is in the Catalogue (see below). It's manual to find this out, so put process in place so that all Change workflow includes updating it. Get someone to own it. Do everything else the way you always did. There. You have CMDB now. Happy?
- It really is cool to be able to drill down on CIs via CMDB relationships to perform analysis. It is also cool to hold all your CAB meetings in a Lear jet.
- You can do without a CMDB. You can't do without a Service Catalogue. This documents what the Services are, the impact on them of changes and outages, who the key people are. Once Catalogue matures beyond a "brochure" catalogue to a technical view for use within IT, it often also documents what the key CIs are for each Service. Just because you don't have a CMDB doesn't mean you can't write the important stuff down somewhere. You must, in the Catalogue.
Evergreen usually write really good stuff but I think this post on Top 10 Reasons to Implement CMDB smacks of the "irrational exuberance" (read: vendor and analyst hype) that I spoke of before. It is not as disappointing as another Evergreen post "CMDB Myths Revealed" though, which is not so much gushing as plain wrong. But that's another blog for another day...