A modern CMDB is at the heart of automation

The CMDB (configuration management database) is an important part of the ITIL framework. It’s the database where an organization stores all its information about software and hardware assets. The organization maintains an overview via this database. It can see which assets are critical, for example, and which mutual links exist. The CMDB is a fundamental component within ITIL, as all other processes within the framework build on it. It is therefore essential that the database is always up to date. Only then will it remain relevant and useful.

From weeks and months to minutes and seconds

And that’s the crux of the matter. The concept of the CMDB dates back to the 1980s. Back then, the evolutionary path of an IT environment was clear. Installing a new server, for example, was a process that could take weeks or months. In any case, there was more than enough time to complete the CMDB. Today everything moves much faster. The installation of a virtual server takes a matter of minutes. When containers appear and disappear again within seconds, keeping the CMDB relevant can quickly become a real challenge.

Various evolutions only underline the importance of the CMDB — shift-left testing, for example, where software testing occurs earlier and earlier in the lifecycle; or high-speed change management, which relies on very fast, automated changes in the environment. Everything is done automatically, except for adjustments to the CMDB. Monitoring the relevance of the CMDB continues to be done manually. But that manual process puts a brake on the acceleration that is desperately needed to realize added value.

Selective storage

The solution lies in the combination of different elements. The first is selective storage. Today more than ever, you need to think carefully about what to store and what not to store in the CMDB. Only the assets on which a concrete service depends deserve a place in the CMDB — so the Kubernetes Pod that provides the actual service should be there, but not the dozens of containers that are located in that Pod.

Automation

Automation is the second element needed to keep the CMDB relevant in today’s rapidly changing world. By automatically registering the correct selection of changes to the environment in the CMDB, you maintain a good overview of the current situation, without requiring a lot of extra manual work.

Self-service

The third element is self-service. You can make this possible by letting the developers trigger the necessary workflows themselves. Are they making a standard change? Then offer it via the CMDB. This way you avoid misunderstandings.

Security

Finally, it’s very important to also involve security colleagues in the management of the CMDB. This is just a logical consequence of the evolution toward DevSecOps. For example, information about accounts, such as passwords, is given a place in the CMDB. These are also assets that you must manage and around which you must be able to provide a service. It’s information that today is mostly spread across different systems, and it’s a smart move to bring these together in the CMDB. If an account has been hacked, the view of the mutual relationships in the CMDB allows you to immediately see what impact this has had on other assets and where you need to take measures.

At the heart

Yes, the CMDB is and will remain the heart of IT service management. And the faster your IT environment evolves, the more important the CMDB becomes. So if you really want to keep up with the times, don’t forget the part the CMDB plays in the big picture, and place it at the heart of the automation.

If you’re choosing a solution, look for a tool that offers a high degree of adaptability. And seek out the ability to use APIs. In the context of automation, it’s very useful to access the data from the CMDB via scripts or to keep that data up to date in that way.