Download the authoritative guide: Cloud Computing 2019: Using the Cloud for Competitive AdvantageThe Configuration Management Database (CMDB) concept of ITIL seems to generate the most questions from readers and may stem from the relatively small amount of information on the Web regarding it. So let's take a few moments to look at the seemingly arcane CMDB, and remove the needless cloak of mysticism around it.
The CMDB is a relational database that serves as the nerve center of IT service management. While the word 'configuration' makes people think it is tracking build information, it is far greater than that. The CMDB represents a logical model of IT. As such, it is tasked with tracking configuration items (CI), attributes (metadata) about each and, very importantly, their relationships to one another.
The CMDB can be all in one database or interfaced together (federated) to preserve normalization of data, ease of collection, etc.
First off, everything is a configuration item. Hardware, software, people, accommodations (ITIL's term for facilities), data files, documentation (including data records), and services are all top-level CIs. What an organization uses, and how they use it, are based on their needs.
A good way to think of attributes is that they are the data fields that make up the CI tables. As an example of CI vs. attribute, would you want to have a field in the server CI record called 'Operating System' or would you want a CI called 'Operating System' that then had attributes defining each type of operating system in use? The correct answer depends on your needs.
At the heart, we know we need to understand some basic elemental
attributes regardless of CI type such as:
For each CI type, you may add, change or delete attributes as needed, but you want to keep the CI structure both meaningful and manageable. If the CMDB becomes too complex to maintain, then its value plummets and people will stop using the system out of frustration.
Database table relationships could be as follows:
Moving along, assembled or compound CIs are made up of n-levels of hierarchically grouped components. A SQL Server is made up of hardware, software and documentation. A service is made up of hardware, software, documentation, and people. The idea is to understand how CIs are assembled for cost, impact analysis, overall planning and so on. For those people with a manufacturing systems background, think of an assembled CI as being analogous to a bill of material (BOM).
One of the most important outputs of Configuration Management is the documentation of relationship. It is critical that the CMDB be able to relate all of the various CI types together. These relationships allow for Change Management to do impact analysis.
If I allow this change to happen, what are the risks? Who and what are involved? By having the relationships in the CMDB, the Change Manager can begin to answer those questions.
The bottom line is that the CMDB is the hub system of all activity in the world of IT Service Management. The exact tables and composition should be driven by the needs of the business, then the services that support those needs and finally the resources that comprise each service that IT delivers. When people ask what a CMDB should look like, they must realize that there is no one-size-fits-all answer. They must work to understand what the business needs, what IT needs and then design a data model that meets those requirements.
Note: For further reference, the ITIL Service Support volume lists potential CI attributes in Annex 7C of Configuration Management.