The Value of the Configuration Management Database

Posted: October 23, 2013 in General, Information Technology
Tags: , , ,

by William Mantz,  ITIL Certified Practitioner
InterconnectionAs ITSM practitioners, we are often asked why ITIL Service Management starts with the foundation of the Configuration Management Database (CMDB) or what is called Configuration Management System (CMS).

The value that this configuration data provides can be shown this way.   First, it starts with the architecture map.  Can you imagine if you had the architecture map for your IT Systems documented in a way electronically that would allow you to identify change or incident impact of a system change?  It the relationships were in a DB electronically to depict the same map for each component,  you could quickly identify the downstream systems or servers impacted when a change request comes along or an incident?   With a bit more information, such as key contacts for these components, you could extend the status and reporting to those impacted customers.

Using an analogy, similar to an electric power line where a power outage can impact downstream customers, if you did not know “who” the downstream customers are  that had been impacted, how would you be able to communicate and inform those impacted by the incident the status, size and scope of the incident?   And, what happens when there is an interruption?  A flood of calls comes in to the service desk.  Wouldn’t it be nice to have the current information so that a response could be formed?   The same story can be told for change requests.  Wouldn’t it be nice to be able to see how and where a potential change could impact what systems?  The quality of this data allows you to focus in specific to the effected systems.

The Configuration Management Database for IT is similar in nature when properly organized and set up to provide such details.   If equipped, it can be used during incidents, as well as change requests to see the size and scope of the issue.  The response can be formed by knowing the customer relationships, as well as the impact and scope of all the components related.  Experienced professionals in Change and Release Management will tell you the power of this Configuration Management Database  is the relationships that each component has with others components, with other system applications, and with connected services.  Second to this is the contact information for these items related.  The quality of this data matters for the accuracy of the status and ability to form the communication of status.

Let’s explore the use case a bit further.  As change requests come along, a quick analysis of that change could be done, and you would have a list of people to question and inform if the timing for the change is good.   This is a key, time-saving feature when looking up impact in the evaluation phase of a change request.   That is also why reporting from the CMS is so critical.  If the system (CMS) has poor reporting capability, it defeats the purpose to do the analysis, scope and assessments.  Simply putting the data in a repository is only the first step.   Choosing a repository that has good reporting capabilities is also just as important in the selection.

512px-ComputernetworkIf you are starting this journey new, as a minimum, take a moment to model out the levels of Configuration Management, and the attributes that you would want to collect.  if you are going to collect the information, you may as well capture it up front.  Key attributes would include a category, type, relationship type,  a single point of contact for the configuration item, and the support group for each item.  And, when looking at component to component relationships or system to system relationships, we have dependent relationship types (meaning the system requires the component to function, or independent, that means the system can function independently of the component in the event a change or outage occurs).   An example of a dependent relationship, would be a log on service where you are leverage a log on service to gain access to the system. The parent system “Depends” on that service to function.   An example of an independent relationship, would be a batch data feed where the parent system can still function fully if the data feed was temporarily interrupted or down for a change.  It’s independent in operation.   Noting this type of relationship is also key in your collection of the data so you will need to document the type of dependencies on the architecture map.  These relationship types will aid in data input into the Configuration Management DB.

Next, you want to configure the relationship of the configuration items (CI’s) in the same order that they would depict in the architecture map as the system was designed. You would do this for each physical environment created for the Application (such as Development, Test, or Production).    Finally, the top level of the map is the System or Application name as your business calls it.  That should be a unique name to avoid confusion, variants, and duplication.  Each level if the data model should capture the same single point of contact information and their support group or persons, and key attributes.   Relationships for integration’s and services are also added between environments or components.

You will find in shared architecture, the relationships can be 1 to many, so you may have multiple people involved.  But, essentially, that is the point of the relationships.  You want the relationships and contacts in order to communicate, inform, and perform the analysis of the impact.  Similar to the power line example, knowing whom is impacted and what customers and companies are effected, allows you to be efficient, proactive, and professional when you form a response.

During the Change Request process in ITIL Service Management, the very first steps of the change process is to evaluate the impact, scope, size, who/what is impacted, and priority.   The CMDB holds the keys to this information.  If you can depend on the data quality for each IT System and their relationships, you can quickly get through the assessment, impact, and prioritization to make informed decisions on the change. The subset of contacts depends on your scope assessment and whom will be notified or consulted.   The same approach could be used for Incidents that arise to a component of the architecture.   For that reason, the process you set up for updating and maintaining the data has to be centralized to a team that respects the data quality and the importance it has to the overall process.

You also need to decide to what level the relationships are needed to do the assessment and impact analysis.   ITIL will state the relationships should go from the top level IT System down to it’s end point, typically, the IP Address.  However, you may not need that level of detail in all the reports.  So, choosing the scope of the data with it’s key contacts is also important.  In the example of the power line, while it may be advantageous to know each switch, node, transformer, and lines to handle the incident, the scope to communicate the outage and status would typically be the end customers and the companies.   Therefore, you would want to structure the data model for the key contacts with this scope in mind for the top level of the map, but also allow you the option to get down to the smaller details if needed.

Careful planning is key to the setup of the CMDB of your CMS.    The scope decision for reporting is key because you don’t want to over communicate details that are not necessary.   In addition, when change requests come along, you need to be able to quickly ascertain the impact and assess what effect the change will have to the systems.  That can only be done quickly if the model is recorded accurately, and reported quickly from the CMS Database.  With this quality of data in the CMS, you will have a valuable tool for IT Service Management.   This foundation work then leads to the practices that use it under Change Management, Release Management, Incident Management,  and Problem Management.

This article is the first in a series of articles around IT Change, Configuration and Release Management using ITIL’s Foundation Framework.

Copyright. William Mantz 2013. All Rights Reserved.
Images used with permission from GNU, please see Image Description.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s