Defining Accurate Configuration Data - ITIL Concepts

The definition you choose to use for the accuracy of your CMDB is quite important. If the definition is too stringent, you will spend significant resources trying to achieve accuracy in unimportant details. If the definition you choose is too lax, you will be declaring your database very accurate when people depending on your data know it isn’t. This section helps you strike a balance that will work for your organization by balancing validity, correctness, and timeliness.

Accuracy of Attributes

The immediate thought when people think of CMDB accuracy is that the attributes of each configuration item (CI) are correct. This is a good start, but we’ll see that it is not nearly complete enough. Suppose that for every server, you are tracking the server name, number of CPUs, physical memory installed, and the status of the server. You find that one of the machines has the wrong number of CPUs, so there is an error in one of the specific attributes of that server. You may find out, however, that a change was executed on the server just yesterday, so what looks like an error may actually be an issue of timing? The normal cycle for updating the CMDB in your process might be several days, and during those days there will be a discrepancy between what is recorded and reality. These timing errors are different from errors where data is inaccurate, and your policy on measuring accuracy must account for them. In most cases, you’ll want to exclude timing errors from any measures of CMDB accuracy.

Your accuracy policy will also need to further distinguish between errors and invalid entries. Using the previous example, the status of the server is probably one of a specific set of values. The tools and database constraints will ensure that one of those values is always assigned, so in some sense you could say that the value in the status attribute will always be valid. However, if the status is “production” but the server is really disconnected from the network and in a storage location, the status is not correct even though it is valid. So, you need to make a distinction between attributes that are invalid and those that are inaccurate. You should also think about your position on empty attribute values. In some cases, an attribute is clearly in error if it is empty, such as in number of CPUs. In other cases, such as the date of the most recent audit, an empty attribute might be a perfectly valid value. There should be a difference between saying that no value is possible or available and saying that you simply forgot to put a value into an attribute. Perhaps you want to define “n/a” as a valid value in some places, and ensure that your procedures help everyone understand exactly when to use it. Whether or not an attribute can be empty is most likely defined in your database, but you should also think about it in terms of errors in the database. Empty values may or may not be errors, depending on your definitions.

Accuracy of Configuration Items

As stated in the preceding section, simply knowing whether attributes are accurate is not nearly enough to define the accuracy of your CMDB. It is also quite possible that a CI itself can be inaccurate.

One obvious error in CIs is incorrect classification. Although it would be relatively rare for someone to mistake a router for a server, classification errors will spring up with less tangible kinds of CIs, such as business processes, documents, or even compliance audits. Each CI can have only one classification, but it’s sometimes difficult to determine which classification applies. Your definition of database accuracy should define what is meant by an error in classification.


One client I worked with wanted to define network file shares as CIs. Unfortunately, they also wanted to define permissions to network file shares as a separate configuration item. Although I told them this much detail might be expensive to maintain, they persisted and we went into production with this schema.

We soon learned that it was extremely difficult for even the IT people to tell the difference between a file share and the permission to use a file share. We were constantly getting errors in classifying the CIs, and people were confused by any search or report that showed both groups.

If you put too many categories, or categories that are too closely related, into your scope definition, you’re just inviting classification errors in the future. Another common problem with CIs is that they aren’t in the CMDB at all. This is the most difficult of all errors to find because you never know what might be missing. Anyone who has spent any time in the IT field knows that as hard as you try, equipment will often get moved around without any record. We’ve all heard the stories of opening the door to a closet to find a whole room full of equipment that we never knew about.

The positive side of discovering new CIs is that at the very moment you make the discovery, you can collect data, and thus the error is corrected. Part of your policy around defining database accuracy should define how this is handled. At the very minimum, you should keep a count of the number of newly discovered CIs so that you can discover trends and form an educated opinion about how many more CIs you may be missing.

Accuracy of Relationships

The third part of the CMDB that must be considered for accuracy is the relationships between CIs. Just like attributes and CIs, there are several ways that relationships can be inaccurate. By far the most common inaccuracy in relationships is that they grow stale. By stale, we mean that the relationship was broken in the real world, but the CMDB was not updated to reflect that fact. This happens because many organizations believe that “simple” changes do not need to be controlled as tightly as more complex changes, and this policy allows for many kinds of modifications to the environment that are not tracked.

Finally, relationships can be in error because they are recorded as the wrong type. Just as CIs have a category, so do relationships. If you are implementing a SAN device and want to indicate the physical connection between a server and the SAN, it would be inaccurate to use a relationship type of “logical connection” rather than “physical connection.” Just as with CIs, the way to avoid this mistake is to have a smaller number of relationship categories, and clearly differentiate those categories so everyone understands when to use each one.

Figure displays the different areas where errors can occur in the CMDB. Ultimately, you need to create a policy that defines what is meant by accuracy of the CMDB. This policy is the foundation for being able to measure and report on accuracy, as described in the next section.

Accuracy of Relationships

Errors can occur in attributes, configuration items or relationships.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

ITIL Concepts Topics