Cmdb

TIL v3 has radically redefined Configuration Management and scrapped the CMDB as we know it. Oh, and this is a really, really good thing!
ITIL v3 is out, and the authors have done the entire industry a very good turn. They have re-defined the term CMDB and dropped Configuration Management as a process.
The CMDB is one of the most desired, misunderstood, over-marketed and most failure prone ofall the ITIL. This is partly part because the previous ITIL authors used the term “configuration management” and “database” in its definition.
The confusion from CMDB is directly related to people not understanding configuration management and thinking that CMDB refers to “normal” configuration management, such as managing device configuration files. Then they think the term CMDB actually refersto a single database – “hey, it has database in the acronym!”
This time around, ITIL authors have re-worked the very ideas of asset and Configuration Management, re-defined the concept of the CMDB, demoted Configuration Management as a stand-alone process, and folded the entire collection under the heading of Knowledge Management.
Following, I will explain how these changes could be one of thebest things to happen to ITIL and those of us who work with ITIL on a daily basis.
CMDB 2.0
ITIL v2 defines the CMDB as “A database that contains all relevant details of each CI and details of the important relationships between CIs.” In my opinion, this single statement has been the cause of most of the grief around CMDB’s. Everyone from practitioners to vendors to consultants thought thatsentence meant just what it says “a database” – singular. You know, like an Access database or something.
Many an erstwhile ITIL practitioner took the definition to heart and tried to create a monolithic database of information. However, most never actually read the ITIL, so they didn’t know that a real CMDB as described by the ITIL (not as defined in the ITIL v2 glossary) is much more of a datafederation application than a database.
A CMDB has to federate (connect to and represent) data from other systems – HR systems, Incident and Problem systems, Change Management systems, discovery tools, inventory and audit systems, etc. The actual data stored by the CMDB should be only data not found elsewhere (in definitive and trusted sources) that describes the attributes and relationships of CIs. Ifa CMDB is a database at all, it is a meta-database – a database that holds data that describes other data. (Whew.)
Aside from not understanding a CMDB, the real issue is that many companies have more than one CMDB – even though the ITIL v2 made it sound as if there was one and only one CMDB. It is quite common to have a functional CMDB as described by ITIL v2 in many locations within an ITorganizations scope of control. Networking usually has one in the form of an NMS. Application development usually has one or two. Often the Service Desk has its own version, and so on.
Many took this reality (myself included) to mean a CMDB then had to be more of a system than a database per se. A “CMDB system” had many databases underneath it. The example I always used (and continue to use) is thatof Internet search provider Google.
Google does not replicate all of the websites it indexes – rather it stores bits of information about the websites it discovers and makes this information searchable. My belief, shared with many others, is that the ITIL v2 CMDB is more of an application than a database. And, of course, that is where the controversy began.
CMDB 3.0 TO THE RESCUE!
ITIL v3defines a CMDB as “A database used to store Configuration Records throughout their Lifecycle. The Configuration Management System maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and Relationships with other CIs.”
Notice how the v3 definition allows for multiple CMDBs! Also note how the CMDB is the product of a Configuration Management System (CMS) – not the Configuration...