The fundamentals of Configuration Management Database (CMDB) with the objective of mapping business to technology

As the world of technology changes, many new technologies and techniques complicate the traditional IT Service Management vision. For example, the Agile/DevOps community embraces the concept of Infrastructure as Code. What is that? Wikipedia defines it as “the process of managing and provisioning computing infrastructure (processes, bare-metal servers, virtual servers, etc.) and their configuration through machine-processable definition files, rather than physical hardware configuration or the use of interactive configuration tools.”

Infrastructure as code is a two-edged sword when it comes to the traditional CMDB. Machine definition files would be an excellent source of data for a federated CMDB, but if one is sufficiently mature with infrastructure as code, who needs a CMDB at all?

Other modern trends include increasingly volatile virtual machines, and now ephemeral containers. The ultimate vision is one of infrastructure on demand – for example, the Amazon Web Services (AWS) Lambda computing platform, a “compute service that runs code in response to events and automatically manages the compute resources required by that code.”

With infrastructure so completely driven by need, and spinning up and down at lightning speed, what will be the role of the CMDB?

To answer this, we need to get back to basics. In my experience, the CMDB is most valuable as a sense-making tool that helps people understand the business value of technology. What is the minimum data required for this? I believe it is:

* The lowest level business concept
o Mapped to
* The highest level technical concept

This may be puzzling terminology, but bear with me.

Most businesses understand their highest levels very well: major value chains, product families, channels, and P&Ls. They may map value chains into enterprise processes and lower level workflows. They can break down product families into products, channels into customers, and P&Ls into budgetary accounts. But, what they struggle with is mapping the IT resource back up into this familiar language. (That’s why the IT Financial Management Association has existed for so many years, with its successful ongoing conference series.)

On the other hand, technologists live in their details – IP addresses, ports, virtual machines, databases, firewalls, load balancers, software products, the list goes on. One of the initial motivations for IT Service Management was to get technologists out of this technical swamp and challenge them to define their activities in a more business-centric manner. Thus was born the “IT Service”, a wrapper to contain various technical resources and give them a more business-friendly identity. Many organizations have explicitly embraced the “IT Service terminology”. Other organizations found they could achieve the same result by elevating the term “Application” to the same level. Whether “Service” or “Application”, these terms became the highest level technical category.

And, mapping the lowest level of the business to this highest stable level of the technology is, in my view, the fundamental CMDB goal. At the end of the day, it doesn’t matter what concepts you choose, as long as you are bridging the gap.

One of the most frequently seen mappings historically has been “Application to Server”. This was the state-of-the-art for many companies. It was an evolutionary step, because previously these companies only knew they had thousands of servers. Determining what was running on any given server might require expensive research and, of course, accounting for the server’s costs was challenging as well.

Sometimes it might be known what cost center or project funded the server, but this was often unsatisfactory; servers could be re-allocated according to demand and the original acquirer might no longer be responsible.

Other companies might reject the term “Application” (frequently because of the perception that it was equivalent to Software). Instead, a concept of IT Service would be mapped to the Servers.

Notice also that the Server itself is a “highest level” concept for much other IT technical data, including network dependencies, databases and more. The IP address resolved via the Domain Name system is an essential point of coupling that decodes much else in the environment.

But, these are only the best known mappings. What if you no longer care about servers, or applications?

You probably still have concepts of business and technology. On the business side, a very popular new concept is “product”. You have a digital product portfolio and the products have owners. These start to become management points. You’ll find yourself wanting that normalized, high-quality list of official Products just as you needed a high-quality Application portfolio ten years ago, and for all the same reasons.

On the technology side, even in a virtual or full Cloud environment, and even if you believe “servers are cattle not pets”, you need to have some ability to trace those cattle to their origins. Why was the server initialized? Why is it showing up on the bill? If it’s running and starts throwing errors, who is responsible? These questions don’t go away just because you’re operating in the Cloud.

In closing, the more things change, the more they stay the same. The important thing is to understand why you want your CMDB or repository and the value you hope to derive from it.  We’ll talk next about how to quantify this value a bit better.