The intent of ITIL v2 was that CMDB be an application based on federated data. However, most CMDB implementations were simply monolithic databases. The problem was largely due to terminology: what did they expect when they put "database" in the name.
These monolithic CMDB databases were impossible to reconcile with live environments that were in constant flux. The result ― CMDB was the most problematic area of ITIL v2.
ITIL v3 to the Rescue
ITIL v3 makes it very clear that a CMDB should not be one monolithic database. Firstly, it explicitly says that it is ok to have more than one CMDB. Secondly, it defines a new concept: a Configuration Management System (CMS).
As you may have guessed from the diagram, CMS is not typically a master data store. It is best implemented as a federated database that contains meta-data about configuration items, customers, partners, incidents, problems, changes, releases etc..... This is why ITIL v3 is careful to define CMS as a "set of tools".
Under ITIL v3 the CMDB is demoted ― one of many potential trusted data sources for the CMS. This will no doubt lead to the commoditization of CMDB much the way that Network Management Systems (NMS) have become legacy data sources.
The best part is that the CMS is part of a broader collection of tools: the Service Knowledge Management System (SKMS). This is a even broader toolset defined as anything required to turn data into wisdom (in the context of Service Asset & Configuration Management processes).
Tweet |
|
