In my post on CMDB autodiscovery and other fairy talesthe ITSkeptic raised the question of: “when does any old bag of configuration management data becomes a CMDB”.
In his opinion a CMDB should show all CIs under change control and their relationships to the service. This seems to be a fairly complex and according to the skeptic unachievable and undesirable (on account of being far to expensive).
So what if we take this completeness requirement out of the CMDB? Everybody knows that a CMDB (CMS or whatever) can never be fully accurate and complete, so we have to make sure that the usage of the data is fault tolerant. ITPedant (Robs own suggestion😉 ) argues that this can not be called a CMDB.
In my opinion, a CMDB is an Information System. It helps with decision taking, but it does not take decisions. So it aids the impact analysis, but it does not automate it. It can not do this. The vendors are selling their systems with this story. That could work, if you had to reduce your failed changes rate from 20% down (refer to the study “The Total Economic Impact(TM) of the BMC Atrium CMDB” by Forrester), then a system with approx. 90% data accuracy could improve your situation (sometimes, maybe and if you are lucky. At least on an ROI calculation paper). But in a real world, where we have smaller targets to hit, people with knowledge and a valid (fault tolerant) process help you more in getting the failure rate down.
So why do we need a CMDB? I do not need this term. I need a configuration management process, that is in control of the relevant and usefull data. I need it to publish this data to other processes and organisations, so that they have a good foundation for their decisions. Why does everybody talk about the CMDB? Not many people (anymore) are talking about the trouble ticketing system when they really mean the incident management process.
So if a CMDB may only be the idealized version containing the whole nothing but the whole of the IT services, components, systems and objects and their reletionships, then yes nobody has a CMDB and nobody ever will. So let’s continue to use CMDB for the unrealistic all-in-one-for-all-purposes (German “Eierlegende Wollmilchsau” direct translation “Egglaying Wool-Milk-Pig”) and try finding a name for the achievable environment in which we keep the configuration data.
- As per Title CMDC – Configuration Management Data Container
- As ITIL states CMS (but people believe this to be even more than a CMDB, while I am looking for a term that is a little less than a full CMDB)
- ITEIS – IT Environment Information System
Go ahead post ideas in the comments.