Understanding the ITIL CMDB Meta-Model
Published: February 15, 2008
This article is the second in a series on the ITIL CMDB. This article provides a high level overview of the ITIL vision for IT knowledge management.
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:
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:
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:
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.
Beyond the three conceptual layers described above, lie additional sets of data that are important in the overall CMDB design:
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:
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.
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.
Recent articles by John Singer
John Singer -
John Singer is a 26-year veteran information systems professional who has focused on data management activities including metadata management, data administration, database administration and enteprise architecture in both staff and management roles. Currently working as a data architect focusing on an ITIL CMDB implementation. John is a former MetaGroup industry analyst, and also has held positions in financial services, pharmaceutical, healthcare, manufacturing, retail, and criminal justice organizations. John teaches graduate level courses as an adjunct faculty member of Webster University. He may be reached at firstname.lastname@example.org.