Understanding The ITIL CMDB Meta-model

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.  CI’s are the objects or things we care about.  Of course, CI’s 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 CI’s beyond aggregation and generalization. For example: Installed on, Supports, Backup for, all provide a richer meaning when connecting two CI’s in the CMDB.  So that’s it in a nutshell, a basic metamodel – CI’s (entities) have attributes and CI’s (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. 

CI’s 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:

1. Service Asset and Configuration Management (SACM) – insures that the organization has a policy for identifying CI’s 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.
2. Change Management – controls changes as they occur and insures that changes to CI’s 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?  CI’s break down along several important boundaries that help the designer:

1. Conceptual layers.  ITIL describes CI’s as logical or physical.  Physical CI’s represent things that exist (i.e. a server computer) while logical CI’s are more abstract concepts such as a business service.
2. 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 CI’s and how are they managed in the CMDB?

Conceptual Layers

At the infrastructure layer, CI’s 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 CI’s.  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:

1. Service.  This layer describes the services that are provided by IT to the business (e.g. email) 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.
2. System.  This layer describes the actual application systems that support IT and business services.  While “Email” may be an example of an IT service, “Exchange”, and “Lotus Notes” may be the two systems that provide the “Email” service.  The systems themselves may be layered as in system contains sub-system. Systems are mapped to services and also mapped to components.
3. Components. This layer represents the “physical” components in the run time environment.  Continuing the Email example, components might be a server computer running Windows and Exchange software.  Component CI’s are mapped to system CI’s. 

The three layers of the ITIL model (Service, System, 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 organizations Services, Systems, and their inter-relationships.  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 CI’s come from?  At the physical layer fortunately, we can use technology to assist us.  Automated discovery tools not only find instances of CI’s, 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 CI’s

Beyond the three conceptual layers described above, lie additional sets of data that are important in the overall CMDB design:

1. 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 CI’s in the CMDB.  In most cases, these represent interfaces to external systems of record but add important knowledge to the CI’s maintained in the CMDB. 
2. 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.
3. ITIL process records.  The ITIL processes themselves produce records such as Incident tickets, Problem tickets, and RFC’s (request 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 relationship 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.

1. 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.
2. 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.
3. Configuration Management Database (CMDB).  A database used to store Configuration Records throughout their lifecycle.  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 towards 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 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.