Skip to main content

CMDB history and a primer for (finally) getting it right

(Image credit: Image Credit: B-lay)

Soon after the very first IT devices were deployed, they broke and required fixing. IT professionals quickly realised that they needed a way to track how they were repairing the devices, as well as a way to determine what else might break as a result of those changes. Thus, the Configuration Management Database (CMDB) was born – and immediately became outdated and despised by IT teams everywhere.

The concept of the CMDB first emerged in the 1980s as part of the IT Infrastructure Library (ITIL), a best practice framework produced by the UK government to help manage and develop controls for IT services. The ITIL principles and standards called for creating and maintaining a database to track and manage IT services. Conceptually, the CMDB is nearly as old as the ITIL standards themselves. It is still considered a foundational element for IT Service Management (ITSM).

CMDB was introduced as a process in ITIL V2 in realisation that asset inventory wasn’t cutting it, especially for change control. The concept didn’t come about overnight though. It emerged from the asset management process, which morphed into more of a hybrid configuration-ish management, later adding change control, which then really made it a true configuration management database.

But then the CMDB as a practice kind of died when people realised it was too complex, too cumbersome, too difficult, and that it was only ever a snapshot in time; by the time you went to use it, it was out of date and worthless. More recently, it’s been making a comeback because of innovations like application and infrastructure discovery and dependency mapping (DDM).

Let’s dig in deeper to this generational timeline.

1990s: The era of asset management

In the late 1990s, IT teams leveraged asset management tools to simply inventory their physical hardware and software assets. Virtualisation wasn’t a thing yet. At that time, we were talking about LPARs (logical partitions) as virtualised systems and physical servers and devices (remember those?).

For corporations, there was a drive to understand their assets because of software licensing and asset depreciation from an accounting perspective. That merged into a question of: ‘Great, but what does this mean for what we have and how we use it?’ People wanted to know the IT equivalent of how the hip bone is connected to the leg bone, connected to the ankle bones, connected to the foot bone. In other words, you have a physical server, but what’s running on that hardware, and how are you using it?

Initially, IT assets were very expensive and, as they proliferated, organisations needed to keep track of them all. Once virtualisation went mainstream, it became critical to also track virtualised assets and the software running on them to do true ups and allocations. Meanwhile, asset management attempted to keep up.

Early 2000s: Configuration(ish) management

All of these trends and developments morph into configuration – taking stock of all the assets that exist and grouping them by relationships, which started to become more virtual at this time. Software sitting on a virtual machine necessitated an understanding of the correlations between assets, providing visibility into what was happening upstream and downstream from various devices and how they related to one another. 

Teams initially leveraged a three-tier stack – comprised of a database sitting on an application server tied to a web server – to monitor critical business services. The understanding was that if one component failed, it took down the whole service. For example, a HR application might sit on top of an Oracle database tied to an application server and web server. If the web server fails, so does your HR app. This was the beginning of mapping and relationships in a configuration approach.

Mid 2000s: The CMDB arrives

Finally, we arrive at a true configuration database, which combines all of these previous phases together with the addition of change control. The CMDB effectively asks: How are these assets associated to these other assets and these business applications – both physical and virtual? How are they interconnected and related? What service are they providing the business? Looking at infrastructure through this lens was picking up steam in 2002, but it didn’t get really hot until about 2004-2006.

Early-Mid 2010s: Peak of inflated expectations – Trough of disillusionment

All of a sudden, CMDB was THE most important thing. Everything had to be in the CMDB. Except people soon realised that you can’t really put everything in the CMDB because there’s too much stuff! Plus, you can only have upstream-downstream relationships while your left-right relationships don’t show up very well.

Around 2012, there was broad realisation that the CMDB was too cumbersome. The value of the CMDB is always just there but never achievable. A number of articles talked about the death of the CMDB. People started to lose faith in it. If it’s just a snapshot in time, it’s not very valuable. Any tools that would reference a CMDB had a bad name attached to them. Unsurprisingly, people stopped using the CMDB.

2018-Present: Technology developments usher in a CMDB renaissance

With the recent maturity of machine learning and AI for IT Operations (AIOps), automated, full stack application and infrastructure dependency mapping is now a reality. By delivering full visibility into dynamic, complex enterprise IT ecosystems, automatic dependency mapping enables the correlation required to identify upstream-downstream flows. ITOps can now map the relationships between assets, applications, and their groupings for services while automatically updating the CMDB in real time – without any human interaction required.

What’s more, automatic dependency mapping can update the CMDB with asset class structure while creating changes and change requests. Creating the enforcement and policy to track what’s real and what’s actually current, that all makes for getting your CMDB right, which is the cornerstone of IT service management success.

Now, ITOps people can say: ‘If you can auto-populate my CMDB, auto-update my CMDB, tell me where the changes are, create the change request for me, and then go back and update the CMDB – the CMDB works for me!’

Looking to the future of the CMDB, the foundation is now established for far more advanced IT operations. Dependency mapping as part of an AIOps platform leverages machine learning to generate data-driven insights. Combine those insights with robust, cross-domain automation, and ITOps can trigger powerful actions to remediate problems and even predict them before they occur. ITOps now has a recipe for agile, autonomous IT operations, one step closer to the promise of truly self-healing IT.

Marcus Rebelo, director of sales engineering and product management, Resolve