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, Understanding the ITIL CMDB Meta-Model, 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).
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.
- 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 siloed 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.
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 proactive 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.
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, siloed or simply not available.
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 organization’s 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 CMDB 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?
-
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. -
Standard practices – the end result of the incident and problem management process should be the creation of known error workarounds 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. The
fourth article in this series will examine the technology behind building the CMDB.
