ROI – Paying for the CMDB Metadata Knowledgebase

This is the third article in a series covering the Information Technology Infrastructure Library (ITIL) best practices and specifically the ITIL metadata management framework called the “Configuration Management Database” (CMDB).  The first article “American “ITIL” – Winning The Metadata Contest” described how the ITIL process improvement effort will re-energize metadata management.  The second article dug into the nuts and bolts of the CMDB meta-model and described how the CMDB concept actually encompasses a grand vision for a complete IT Knowledge Management system (what ITIL V3 calls the Service Knowledge Management System (SKMS). 

Process

This article will explore the business justification for building the CMDB.  ITIL process improvement projects are generating real return on investment (ROI) for adopting organizations.  This article looks at the components of ROI and how the CMDB enables them.

Process improvement and CMDB are the ying and yang of ITIL.    As we will see later, process improvement ROI cannot be achieved without the data found in the CMDB. 

Yet building the CMDB is not justified without the ITIL process improvement effort. You simply can’t have one without the other.  You might say that the CMDB is the secret sauce of the ITIL project.  This is not unlike other repository style projects.  Whether you are building a data warehouse, an enterprise architecture, a content management taxonomy, or a traditional data architecture oriented metadata repository; gathering the metadata is all cost and no value.  It isn’t until you use the data in some meaningful way that benefit begins to accrue to the organization and the financial bottom line.  

As discussed in the second article, the CMDB in its entirety represents a model of the organization.  This model is built up in increasing layers of semantic value from establishing the basic vocabulary needed to describe things to complex relationships among abstract objects such as “business service” and “application system”.  The following list contains some of the more significant data objects in the CMDB. Remember that CI stands for Configuration Item which is an entity in the CMDB.

Types Of CMDB Data

• CI class and relationship hierarchy.  These define the classes of objects maintained in the CMDB and how they can be related. 
• Common Taxonomies.  Classification schemes used to categorize objects in the CMDB.  IT assets are classified using common product taxonomies such as the UNSPSC.  Incident and Problem tickets are classified using a taxonomy that indicates the type of incident.  These classifications are used to drive automated assignment and routing of incident/problem tickets.    
• Asset Inventory.  This is the list the things you have in the operational environment including network and server devices, application/web servers and database servers.  This becomes the basic set of terms used as the “what” in the ITIL processes (i.e. what changed, what experienced an incident).
• Configuration Detail.  Further descriptive attributes of the “things” that make up the environment. 
• Configuration Relationships.  Asset inventories by themselves are useful, but additional benefit begins to accrue when you know how configuration items are related across different classes of CI’s.  For example, what databases are connected to which web servers provides an improved understanding of the impact of future changes.
• Configuration to Process Relationships.  One of the benefits of the ITIL framework is that it unifies the asset management process, configuration management process, and the support processes (i.e. Incident/Problem/Change).  It is not unusual for many organizations to have these processes silo’ed with little exchange of knowledge between them.  An ITIL enabled toolset and processes will provide a “single pane of glass” that allows the user to look at an infrastructure component and its history of incident and change activity.  There are numerous things to relate to the configuration items including: process records, known error workarounds, maintenance windows, documents, contracts.
• Service & Application Mapping.  The business service and application system layers of the CMDB represent abstract objects in your enterprise IT model.  It is one thing to generate a list of all your database servers, but what about the list of all your “application systems”?  Building this layer of the model gets out of the specifics of what is installed and into the minds of the business owners.  An “application system” may have a collection of identifiable technical components, but the act of giving an application system a name is a purely social construct.  Linking these business defined concepts to the IT infrastructure creates a powerful tool for managing IT in a way that makes sense to the business.

CMDB ROI

Now let’s turn our attention to the ROI benefits that are derived from the ITIL project.  Many of the ROI models are expressed in terms of process improvement; ITIL is after all, a process improvement effort.  In general, ITIL process ROI can be categorized as follows:

• Process and data standardization. Just moving your organization to a common way of performing Incident/Problem/Change and Configuration management tasks can achieve savings in terms of tool consolidation, lower training cost, and lower tool support costs. Configuration data is typically spread out among the technology domains with little sharing of information resulting in lost time researching problems. Many organizations have multiple silos of technology and procedures for these ITIL processes.  This is the low hanging fruit and the starting point for achieving additional results.
• Increase Process efficiency.  Getting things done more quickly per process event can result in reduced headcount.  Examples include: Reduce time spent diagnosing incidents, increase first call resolution, and reduce time spent reviewing and approving changes. It is tempting to dismiss this as “soft dollar savings”, but in a large IT organization there are hundreds of people from the help desk to “level 3” support groups that spend much of their day on these basic tasks.  Increasing efficiency means fewer people needed.
• Eliminate process events altogether.  Studies have shown that a high percentage of incidents in production are caused by changes.  Improving the change management process with better impact analysis can actually eliminate unintended incidents.  Another example is using pro-active problem management to eliminate future incidents.  You would be surprised at the number of incidents in your environment that occur on a regular basis simply because nobody has time to “fix” the problem or worse yet, nobody is even aware that multiple incidents are occurring that actually represent a common problem.

CMDB ROI Data Enablers By Process

But how does CMDB data better enable these process improvements?  The following chart illustrates the high level ROI categories and how the CMDB enables the ROI.  Note that without the CMDB data enabler you cannot achieve the ROI. 

The chart above illustrates how ITIL ROI is achieved and it is always linked to the availability of CMDB data – data that in most shops is fragmented, silo’ed, or simply not available.

CMDB As A Knowledge Management Effort

There is another way to look at the value of the CMDB repository.  Underlying much of the ROI process drivers described above is an unstated knowledge management effort.  The CMDB is more than just technical data slurped up with an automated discovery tool.  The staff who are performing the ITIL processes (Incident, Problem, Change, Release, and Configuration management) are building the CMDB’s “knowledge base”.  When ITIL processes are functioning according to the standard in an integrated system, the organizations knowledge about its systems is being captured in a way that benefits all.  Look again at the chart above and notice how many of the CMBD data enablers are actually relationships between data (i.e. incidents classified by type, incidents linked to CI’s, work-arounds for known errors).  These relationships don’t materialize out of thin air; they result from people who are correctly using the ITIL process systems.  Building the CMDB is in fact a knowledge management exercise. 

IT organizations frequently divide staff roles along the following lines:

(Tier 4)      Architect – design overall architectures for infrastructure, data, and applications.

(Tier 3)      Engineer – convert business requirements and architectures into workable designs.  This group may also construct the solution.

(Tier 2)      Operational Support – provide day to day technical and operational support for running systems created by engineering.

(Tier 1)      Service Desk – provide front line support to the end users of systems.

You frequently hear these roles describes in terms of “tiers” or “levels”, as in “tier one support” or “level 2 support”.  These tiers or levels represent the path that information follows in the CMDB knowledgebase.  The understanding of the overall composition and nature of the systems being managed starts at the higher tiers and works its way down to the lower tiers.  Information about the running state of the systems and technical problems being encountered starts at the Service Desk and works its way up the levels.  Also, note that in terms of numbers and dollars, you tend to see the number of people in each role increase at the lower levels (i.e. there are more help desk staff than architects); while the average cost per person decreases at the lower levels (i.e. help desk staff cost less than architects).  This suggests that a management goal should be to optimize the number of people in this structure and that is exactly the goal of ITIL.  How is this accomplished?

1. Knowledge empowerment – the CMDB’s overall knowledge of the systems puts this information a few clicks away for the Level 1 support staff.  Just having access to information about the environment can shorten the amount of time spent on incident research and resolution.  Better “intel” at Level 1 can mean less time researching problems and a more targeted involvement of higher levels. When level 1 has only a cursory understanding of the systems environment the best they can do with an incident they don’t understand is to shotgun it to the entire organization.

2. Standard practices – the end result of the incident and problem management process should be the creation of known error work arounds and problem resolutions.  It should be the goal of the higher levels to empower the level below with standard procedures for researching and fixing problems.  This keeps architects and engineers working on new solutions and not fixing recurring problems.

The idea is to have the right people doing the right things.  Level 1 and Level 2 staff supporting users and resolving most incidents while Level 3 and Level 4 staff work on new system functionality.  This becomes a virtuous cycle as newer systems are created with higher quality resulting in less cost to operate. 

Next Steps

This article looked at how ITIL and the CMDB generate ROI.  You should use the process ROI in your project justification but don’t forget the knowledge management nature of building the CMDB. 

On a technical level, architecting the CMDB requires the integration of data from many different systems.  ITIL calls this the “Federated CMDB”.  The CMDB itself is as more of a logical construct than a singular data repository. Recognizing the boundaries of the various systems that participate in the overall solution is an important part of achieving the overall solution. 

This article originally appeared in TDAN on September 1, 2008