This is the second 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 for two reasons – ITIL process improvements generate real ROI, and they
cannot be achieved without an integrated view of the IT ecosystem called the CMDB.
This article will provide a high level overview of the ITIL vision for IT knowledge management. Enterprise architects and metadata management groups should pay close attention as the ITIL V3
standard calls for the creation of an enterprise model that drives the full life cycle of provisioning IT services to the business.
The CMDB meta-model (as loosely defined by ITIL) describes a basic repository of IT infrastructure components and their relationships, but quickly expands into a bold vision for IT knowledge
management. ITIL V2 places a large emphasis on transitioning IT from a systems management perspective (server xyz is down) to a “service” management perspective (the order entry system
is down). This requires a mapping from business process to application system to infrastructure component very much like the layers in the Zachman Framework. In fact, calling it a
“configuration” database is a misnomer, as the CMDB is essentially a model of the entire enterprise. Vendor “CMDB” products that support this concept have only recently
appeared with features that will be familiar to the “metadata repository” crowd. Existing metadata management vendors are re-tooling their messaging so they too can play in this new
market. In this article, we will consider the “logical” view the CMDB and all that it is intended to encompass.
The CMDB Meta-Model
At the heart of the CMDB is the concept of the “configuration item” or the CI. CIs are the objects or things we care about. Of course, CIs have attributes that describe the objects.
Relationships are the next important part of the CMDB. ITIL recognizes that there are many types of relationships between CIs beyond aggregation and generalization. For example: installed on,
supports and backup for all provide a richer meaning when connecting two CIs in the CMDB. So that’s it in a nutshell, a basic meta-model – CIs (entities) have attributes and CIs
(entities) are linked together via relationships. Vendors “CMDB” products are essentially basic metadata repositories combined with a discovery facility for automatically populating the
infrastructure layer of the model. The ITIL books do not provide a meta-model standard like the OMG’s Meta Object Facility (MOF) or the DMTF Common Information Model (CIM). However, the ITIL
books do provide guidance and best practices for building the CMDB in a way that is sustainable, supports the business and delivers ROI.
CIs make up the unit of change and are under the control of change management. This is an important point as metadata project failure is frequently caused by lack of confidence in the data (i.e.,
the data in the repository isn’t kept up to date with the real world). In the ITIL world, a CI is under the control of two important processes:
-
Service Asset and Configuration Management (SACM) – insures that the organization has a policy for identifying CIs and insures that an auditing process is in place to
validate the correctness of the data. This is accomplished using automated discovery tools or old-fashioned manual audits. - Change Management – controls changes as they occur and insures that changes to CIs are recorded in the CMDB.
This combination embeds the maintenance of the configuration metadata deeply into the organizations processes, thus insuring its accuracy and timeliness.
Designing the CMDB becomes a question of CI scope and complexity. How many things do you include in the CMDB? How much detail do you capture about each thing? CIs break down along several important
boundaries that help the designer:
-
Conceptual layers. ITIL describes CIs as logical or physical. Physical CIs represent things that exist (i.e., a server computer) while logical CIs are more abstract concepts such
as a business service. -
Contextual. There are many things that have useful relationships with configuration items. Staff, locations, general ledger account structures, organizational units are all
entities that can be related to systems and services. Are these things CIs and how are they managed in the CMDB?
Conceptual Layers
At the infrastructure layer, CIs are easily recognizable (e.g., server, disk, network device). Once you move beyond things that physically exist, it gets a little harder to identify and name
concepts such as “application system,” or “business service.” Does your organization have a list of its application systems (let alone a decent definition for what is an
application system)? In the CMDB world, all these things are considered CIs. ITIL uses the terms logical and physical to distinguish between infrastructure components (physical) and abstract
concepts such as “business service” (logical). In general, there are three layers to the model:
-
Service. This layer describes the services that are provided by IT to the business (e.g., e-mail) and business services that are provided to customers (e.g., web- based order
entry). The services themselves may be layered as in service contains sub-service. Services are mapped to systems. -
System. This layer describes the actual application systems that support IT and business services. While “e-mail” may be an example of an IT service,
“Exchange” and “Lotus Notes” may be the two systems that provide the e-mail service. The systems themselves may be layered as in system contains sub-system. Systems are
mapped to services and also mapped to components. -
Components. This layer represents the “physical” components in the run time environment. Continuing the e-mail example, components might be a server computer running
Windows and Exchange software. Component CIs are mapped to system CIs.
The three layers of the ITIL model (service, system, and component) map quite closely to the Zachman Framework layers making the ITIL CMDB effort a great starting point for enterprise architects
seeking ROI for their efforts. Unfortunately, the ITIL CMDB says little about the “data” column of the Zachman framework, focusing more on mapping the business to applications and their
underlying infrastructure.
At the logical layer, it is entirely a human knowledge engineering effort to define the organization’s services, systems and their interrelationships. The concept of “Application
System” is a social construct – an instance of an application system exists because the organization has agreed to its name and what it encompasses. Where do the relationships between
logical and physical CIs come from? At the physical layer, fortunately, we can use technology to assist us. Automated discovery tools not only find instances of CIs, but can infer relationships
between physical components by examining detailed configuration data or by monitoring packets of data as they move on the network. For example, web servers have configuration files that identify
the database instances they connect to. This allows the discovery tool to create a relationship between the web server and the database server. The hardest relationships to create are the mappings
from the physical components to the logical systems. Part of the problem lies in the sheer volume of physical components and the lack of meaningful metadata in the physical configuration. The
discovery and application mapping tools provide a partially automated solution in that you can train the discovery software to map discovered physical components to logical systems based on
discovered configuration data. This requires a manual effort in configuring the discovery tool; but once established, the relationships will be maintained automatically.
It is the relationships that take the CMDB beyond the realm of an asset inventory and into more value-added knowledge management capabilities. Relationships enable impact analysis when performing
changes (i.e., If I shut this server down, which applications will stop running?). Relationships build the bridge between the IT infrastructure and the business by defining how services are
supported by components.
Contextual CIs
Beyond the three conceptual layers described above, lie additional sets of data that are important in the overall CMDB design:
-
Business Context Data. It becomes tempting to see everything as a CI – why not people, organization, projects, financial, or physical locations? All of these things
represent important data that can and should be related to the CIs in the CMDB. In most cases, these represent interfaces to external systems of record but add important knowledge to the CIs
maintained in the CMDB. -
Classification Taxonomies. ITIL recommends that organizations adopt standard classification schemes for assets and ITIL process records (e.g., incident, problem, change). These
taxonomies become the valid values for attributes in the model and provide for a more standard reporting and query capability. -
ITIL Process Records. The ITIL processes themselves produce records such as incident tickets, problem tickets, and RFCs (requests for change). All of these process records should
have a relationship to a specific CI in the CMDB.
Building relationships between the IT ecosystem model (with its conceptual layers) and the additional business context data described above creates an overall model of the enterprise. Much of the
ROI from ITIL is driven from this knowledge repository.
The ITIL V2 description of the CMDB in terms of configuration items, attributes and relationships is not adequate when compared to the scope of what the CMDB is intended to accomplish. The
simplistic CMDB meta-model has been applied to all IT knowledge management problems including unstructured data. In May of 2007, The UK government agency responsible for publishing the ITIL
standards came out with ITIL V3. The new version did not represent a change in the existing standards, but was an enhancement of the material that places an emphasis on managing business and IT
services using a life cycle approach (i.e., from planning to disposition). This brings the ITIL CMDB into the enterprise architecture arena in a more formalized way. In version 3, additional terms
have been introduced that extend the CMDB concept to encompass virtually any IT knowledge management activity:
-
Service Knowledge Management System (SKMS). A set of tools and databases that are used to manage knowledge and information. The SKMS includes the Configuration Management System
(CMS), as well as other tools and databases. -
Configuration Management System (CMS). A set of tools and databases that are used to manage an IT service provider’s configuration data. The CMS also includes information
about incidents, problems, known errors, changes and releases and may contain data about employees, suppliers, locations, business units, customers and users. -
Configuration Management Database (CMDB). A database used to store configuration records throughout their life cycle. The Configuration Management System (CMS) maintains one or
more CMDBs, and each CMDB stores attributes of configuration items (CIs), and relationships with other CIs.
The preceding definitions were paraphrased from the ITIL Service Transition Glossary (ISBN 978 0 11 331048 7).
These new definitions and the guidance contained in the ITIL V3 books recognize that multiple knowledge management technologies are required to achieve the overall vision of the CMDB as it had
evolved under V2. The SKMS definition establishes this higher order view of a knowledge management architecture being created to manage and run IT. The CMS definition acknowledges the existence of
business context data that should be related to configuration data, but not confused with it. Finally, the CMDB definition pulls the meaning back toward its original intention (documenting the IT
ecosystem) and acknowledges the need to “federate” or integrate many CMDB style repositories.
Next Steps
Powering the CMDB is the ROI associated with the various ITIL processes. In the third article in the series, we will examine the different components of the ROI and how the knowledge managed in the
SKMS/CMS/CMDB enables the ROI. Understanding the data value drivers will lead to a well designed CMDB that supports the new IT service management strategy.
Architecting the CMDB requires the integration of data from many different systems. ITIL calls this the “Federated CMDB.” The CMDB itself is 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.
\
