CMDB Solutions are dead—long live the Service Catalog!

Configuration management databases (CMDBs) are essential to bringing visibility, health, and optimization to your IT infrastructure. Whether a single database or a federation of multiple databases, a CMDB solution is a repository that acts as a data warehouse—storing information about your IT environment and the Configuration Items (CIs) used to deliver IT services. 

As organizations grow in size and complexity, CMDBs can help in consolidating, maintaining, and understanding the complex and siloed data. However, CMDBs are not without their drawbacks. The maintenance overhead can be costly both in technical resources and the human attention needed to ensure quality and value. Fortunately, there is an alternative—the service catalog. At a high level, service catalogs can help reduce the time and cost of technical services while also improving the user experience.

But before we dive into the advantages of service catalogs, let’s look at the brief history of the CMDB.

The Failure of CMDB Solutions

Before the emergence of cloud computing and hosted services, managing physical installations and manual deployments meant that CMDB solutions were essential, and the importance of it grew.. and grew.. and grew! Following any change to IT services, updating the CMDB became a manual effort and additional toil after the work was done. It didn’t seem to add value, so what was the point? 

The value only became clear when CMDB solutions were needed to make real-time decisions. But by then the information that was held was often so out of date that it no longer reflected the real world. So the IT industry came up with discovery exercises, which were nothing more than a huge audit to bring CMDBs up to date. The problem was that the audits took so long that by the time they finished the data was out of date again.

The Modern Challenge

As Agile principles developed and smaller changes occurred more quickly, the discovery exercises just seemed even more futile. Add migrations from on-premise to the cloud and it appeared as though the cloud providers would manage our catalog of services, platforms, servers, and applications for us…which, of course, they didn’t. In fact, moving from monoliths to microservices meant that the number of assets we needed to track exploded exponentially.

The result was that organizations gave up on CMDB solutions, and this has led to inevitable problems. We still need to know what our assets are (even those in the cloud) and their configuration and settings if we are to operate as a service. The move to Infrastructure as Code means that changing ‘hardware’ assets is much easier and quicker, such that they should be software rather than bare metal assets.

An Extra Layer of Complexity

With the introduction of DevOps principles where regardless of our actual job title, we’re all engineers now, the changes are coming thick and fast: from anyone, anywhere, and at any time. This means while we still have the original problem of not fully understanding the makeup of the services that support our business, it’s now even more complicated than before. 

Let’s think about just production environments for a moment and consider some simple questions:

• How do we know we’re monitoring all of our services correctly if we don’t know what all of our services are?
• How do we know if an issue is an incident—or even genuine—if we don’t know what services we operate?
• How do we fix an issue with our service if we don’t know the latest changes made?
  

Now add the non-production environments that need to be controlled and you can see where things quickly become unmanageable.

The Rise of the Service Catalog

The answer is actually quite simple and arises from those same DevOps principles. I’m referring here to “CALMS”, as first proposed by John Willis and Jez Humble, which stands for Culture, Automation, Lean, Measurement, and Sharing. At the core of this framework is providing “business value”. This requires a service catalog—a list of technology resources and offerings available from the IT service provider within an organization.

Culturally, we must accept that a method of recording our IT systems is essential and kept up to date, otherwise, everything we do to support our service is guesswork and assumption. We must also recognize that it has to provide genuine business value and be usable not just by developers or operations technicians, but by anyone in the business.

Automation is key. Previous failures were due to the mundane, manual nature of the need to update a CMDB solution following a completed change. So let’s convert the manual process of updating the CMDB into the automated process of updating a service catalog. Automation means we know the update will always happen, it will always be correct and its application consistent, with any issue or error reported immediately. Any search for a business service providing value on the service catalog will provide the latest data.

Lean means making our ways of working as simple and as instantaneous as possible. In process terms, the moment the change has occurred is when our automation must update the service catalog. The moment we require a business service, we should use what we have in our service catalog already, rather than re-engineering the wheel.

Measuring everything means asking ourselves several questions: How stable are our services? Where do we make the most changes? Where do we maintain our current trajectory? Where does change provide the greatest value? The answers give us a whole new level of information and understanding that we can use to scale the rate of change to our services and determine our success.

Sharing real-time information about our services with the confidence that we can identify real business value, when we actually need it, without the toil, waste and error-prone overhead of manual maintenance and discovery, is essential to ensure consistency of best practice across the enterprise.

This means that we cannot make the same mistakes in cataloging our services as we did with CMDB solutions. Remove the waste of manual effort. Remove the concerns about data quality. Remove the complexity that underpins our businesses. By taking the CALMS principles and applying them to Incident and Change Management, we can genuinely take control and manage our IT in a viable, simple and value-added way.

Ready to apply what you’ve learned into practice? Contact xMatters for a demo and discover how you can easily maintain your service catalog with automation. If you would like to try xMatters, sign up today and start exploring.