Greetings!

In this weeks article I will be talking about the concept of a Configuration Management Database (CMDB) and whether it is still relevant in today’s fast paced I.T. world.

What is a CMDB?

A CMDB is, in essence, the main tool that the Service Asset & Configuration Management function uses to track the state of “stuff”. In the context of an I.T. service “stuff” is anything that the services needs to manage and control the state of in order to be able meet its obligations e.g. levels of service, compliance requirements etc.

Commonly each instance of “stuff” is referred to as a Configuration Item (CI), at least in the world of ITIL®, and has a number of attributes against which pertinent information is stored. For example, the CI record, in a CMDB, for a laptop may hold the following information;

• Make
• Model
• Warranty Status
• Operating System
• Assigned Owner
• Related Cost Centre
• Previous Incidents
• etc

This information can all be useful to various roles and functions within an I.T. service, for example;

• Operating System - can be used by Technical Management to know which devices to patch with what updates
• Related Cost Centre - can be used by Financial Management for cross charging
• Previous Incidents - may be useful to the Service Desk when trying to diagnose a reported issue

Now all of this information is undoubtedly useful, but does it all need to be kept in (and typically manually replicated into) a monolithic CMDB?

Is there a better way?

Better, in a sense of being more efficient, and less prone to human error? Absolutely! In the following sections I will expand upon this and describe the options in a toolset agnostic way.

Federation

The federation model is where the base minimum of data is held in the CMDB to enable ITSM processes but, when further information is required, it points to the single source of truth for that data type.

The guiding principle is here “Right data, right place and only accessible by those who need it, when they need it”.

This model is my preference when there is a complex service environment spanning multiple delivery models and architectures.

Integration

The integration model is where the various primary data sources, that underpin delivery of your service(s), feed into your central CMDB (typically within your ITSM toolset).

Automation is the underpinning point here. This approach can work well where integrations have been proven to work, and most leading ITSM tools will come with standard integration with other leading tools, but I am always conscious that anything new requires time and will undoubtedly need iteration to get it right.

Conclusion

The CMDB still has an important part to play in delivering and controlling services to ensure consistency and quality.

However, the days of the CMDB being deployed as a single entity, and source of truth for everything, should be reconciled to the past. Instead consideration should be given to who really needs the information and how that information visibility requirement should be met.

Hopefully this has been useful to you and I wish you well on your ITSM journey…