Demystifying the CMDB

By: George Spafford

April 1, 2006

The 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. Thus, let’s take a few moments to discuss the seemingly arcane CMDB and remove the needless cloak of mysticism around it.

The Configuration Management Database 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.

First off, everything is a CI. Hardware, software, people, accommodations (ITIL’s term for facilities), data files, documentation (including data records), and service are all examples of top level CIs. What an organization uses is based on their needs. For example, under hardware, maybe they need tables (CI types) to track network devices, servers, storage devices, etc. Records such as those for changes, problems and incidents are also CIs and need to be defined based on business need. In general, you want to use a CI when one-to-many and many-to-many relationships exist. However, risk or other needs may also prompt you to define a class of CIs vs. simply using attributes.

Attributes are the fields of 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?

At the heart, we know we need to understand some basic elemental attributes regardless of CI type such as:

• CI ID – a unique identifier for the CI that is then referenced in documentation, etc.
• Status – Has the CI been purchased, in testing, in production, or has it been retired? You want enough meaningful status records to represent the lifecycle of the CI.
• Supplier – Who did you buy it from? This could be the external vendor ID or the internal department.
• Purchase Date – When was it purchased? You may need to know this for calculating the book value.
• Purchase Cost – You need the total purchase cost information associated with the CI. In other words, work with accounting to make sure that the correct total purchase cost is entered – this may include purchase price, shipping, professional services, etc.
• Security Information – What security information is needed about this CI? ITIL is big on Confidentiality, Integrity and Availability (CIA), but you should use what makes the most sense.
• IT owner – In IT, who is responsible for this CI?
• Physical location – Where is it located? Depending on the CI, some groups may need to know the physical location as well as logical locations.
• Production Date – When did this CI enter production?
• Comments – Miscellaneous comments (be careful - don’t let this attribute evolve into something unmanageable)
• Parent relationships – What assembled/compound CIs uses this CI as a component?
• Child relationships – If this is an assembled/compound CI, what component CIs make it up?
• RFC Records – Need to relate this CI to all request for change made against it. This may be the same as the change record IDs but it’s listed separately here. The reason is to show all RFCs – accepted and rejected.
• Change Records – Need to relate this CI to all changes made to it. This allows for the Change Manager and other stakeholders to gauge historical activity.
• Problem Records – What problems has this CI been associated with?
• Incident Records – What incidents has this CI been associated with?

For each CI type, you may add 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.

Assembled, or compound, CIs are made up of n-levels of hierarchically assembled 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 costing, impact analysis, overall planning and so on.

The relationships are very important because this allows for change management to see the CI relationships to do impact analysis and by seeing the organizational units involved with a service, the Change Manager can determine who is involved.

The bottom line is that the CMDB is the hub of all activity in IT and is a logical model that enables the organization to operate. Thus the CIs become tables and the attributes are fields. 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. When people ask what a CMDB should look like, there is no one-size-fits-all answer. They must work to understand what the business needs and 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.