Successful CMDB Implementation – a Use Case

In an earlier blog post, we clarified what a CMDB is and for what it can be used. Here, we will explain how important a successful and well-structured CMDB implementation is to a company and illustrate this with a concrete example.

Getting Started: Planning Your CMDB

First of all, recognize that you must plan for the effort involved in both implementing the CMDB and its subsequent maintenance. This is because the data contained in a CMDB must be kept up-to-date, otherwise even the best designed CMDB will not help support one’s daily business.

Then, as you think about introducing a CMDB, ask yourself what benefits it should have for your organization:

• How can the CMDB be most useful?
• What business needs should it support?
• Who should work with the CMDB?
• What expectations are associated with its implementation?

In short, what is your goal in implementing a CMDB?

It is also helpful to appoint a person(s) to be responsible for configuration management. Together with an interdisciplinary team, this person can answer any necessary questions and get the project “rolling.” This person can also ensure that, once the configuration items have been entered, a process for maintaining the data contained in the CMDB is defined. As already mentioned, the best CMDB is useless without up-to-date data. As a rule of thumb, always keep an eye on the data maintenance effort!

Components of a CMDB

According to ITIL^® V3, a configuration item is “an asset, service component or object that is or will be under the control of Configuration Management.” ITIL^® V3 describes to what extent CIs should be recorded as follows: “Configuration items should be selected, grouped, classified and identified according to proven selection criteria so that they can be managed and traced throughout the service lifecycle.” In short, an asset can be anything that is needed to provide a service. When the asset is managed, it is called a configuration item.

So what should a CMDB contain? Orient yourself with these high-level principles first:

• Record what is necessary.
• Do not enter anything that is not required.
• Only enter what can be measured.

From there, a CMDB usually consists of the following components:

• Configuration items or CIs (ex. hardward and software components)
• CI attributes (ie. details about the CIs, such as IP address, processor speed or model number)
• Relationships between CIs

Complicated Concepts Can Be Helpful When Structure Is Added

To put it into practice, the implementation of a CMDB can look as follows:

A cloud provider introduced the OTRS CMDB and connected almost its entire data center to it. They decided to do this because they urgently needed to have an overview on the large number of IP addresses that were available to the provider. While every CMDB is unique to one’s business, in this case, IP addresses were considered to be CIs so that they could be easily tracked and monitored.

Designing the cloud provider’s CMDB resulted in very detailed CI classes. CI classes are groups of configuration items that share the same attributes. For the cloud provider, the first CI class was “locations.” A company location can, in turn, consist of several buildings, so a “building” also represented a CI class. In one of these buildings there are several rooms, such as server rooms. A server room consists of several cubes, in which individual server racks are available, each of which again represented a CI class. A server rack consists of several height units (HE). In each of these, there are servers and network devices, like switches, routers, etc. Servers and other devices consist of network components that have been assigned one or more IP addresses.

These IP addresses are considered assets (or CIs) that belong to the corresponding CI classes outlined above. The IP addresses as individual CIs each have attributes: One of these attributes is “status.” Looking at the status attribute makes it possible to see which IP addresses are still free and which are already occupied.

The relationship of CI classes to one another is established by the OTRS feature add-on “CI References,” and it is also saved directly as a CI attribute. Using this configuration, an IP address now belongs to a network component or server rack, consisting of several height units, located in a cube, which in turn belongs to a room located in a building. This guarantees that the cloud provider has a constant overview of the IP addresses which are freely available and where they are located within the data center.

This is just one way in which a CMDB can solve business challenges. It is also particularly helpful as part of an ITSM software solution. In an ITSM environment, equipment is routinely monitored. By linking equipment through classes, defining relationships and adding attributes, it is possible to immediately detect any impairment to CI classes in general, individual pieces of equipment or services offered by affected devices.

Whether you use a CMDB in a traditional way (such as in the example above or as part of an ITSM solution) or in an expanded way (such as for fleet or facility infrastructure tracking), keep in mind that a CMDB is basically a “never ending story” that will help your organization find the data it needs to add value today and into the future.