THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Published in TDAN.com July 2003

The system that manages our systems: metadata repository or configuration management database? A brief look at the metadata implications of IT Service Management.

In this article, I make the case that the "system that manages our systems" has not traditionally been a metadata repository. Systems management frameworks and various point solutions are used in the data center and on the help desk for day to day operations. However, these concerns and metadata are converging quickly, spurred by the discipline of IT Service Management and in particular its key foundation element of a Configuration Management Database.

David Marco, in "Meta Data Repository: A System that Manages Our Systems" (TDAN.com #23), argues that the metadata repository is key to the ongoing operation of the IT capability in the large enterprise, asserting that it is the

This assertion however is problematic, when paired with his previous assertion (Marco 2000) that:

This view is shared by the Common Warehouse Meta-model authors (Poole, Chang et al. 2002) who also call for “eliminat[ing] manual processes” (p. 178).

But someone has to be the first one to type in the name of the new server, the definition for a new release of a package, or the name of the new table. What is that process? And if the metadata administrators are not typing in the information, who is?

Clearly, to "manage a company's systems," one also needs *processes*.

How are ...

• systems monitored?
• problems resolved?
• servers deployed?
• databases approved?
• software systems installed?
• capacity planned for?

These operational IT tasks have historically *not* been part of metadata scope. They have been filled by management frameworks and a variety of (usually badly silo'd) point solutions used in the data center, in the specialty administration groups (e.g. asset management, database, messaging, and ETL), and on the help desk. Today, the metadata concept is missing these key components to be of much relevance to CIOs seeking to run their internal IT shops. At best, metadata is an after-the-fact data warehouse or ODS-like capability that integrates from sources like CASE tools, operational systems, and others.

IT Service Management

The missing links appear to be emerging in a set of operational disciplines known collectively as IT Service Management (ITSM). Most IT professionals have probably heard of the following:

• Help desk
• Software control & distribution
• Contingency planning/disaster recovery
• Service level management
• Configuration management
• Change management
• Incident management
• Problem management
• Capacity management
• Application management
• Data management
• Availability management
• Cost management

These terms can seem very unclear (what is the difference between problem management and incident management?), at least until one encounters the Information Technology Infrastructure Library, or ITIL. This is a UK-based set of government standards which precisely define the scope for these terms, and is perhaps the closest thing ITSM has to an authoritative representation. It has been around since 1992, and is increasingly influential in large IT shops. (See www.ogc.gov.uk/index.asp?id=2261 or www.itsmf.com.)

Configuration Management and the CMDB

A core ITSM discipline is the concept of Configuration Management. To quote Jan Van Bon in IT Service Management – An Introduction,

A foundational element to the entire ITSM conception is the Configuration Management Database, or CMDB. A CMDB, according to ITIL, manages:

• hardware (including network components where relevant)
• system software, including operating systems
• business systems - custom-built applications
• software packages
• database products
• physical databases
• environments
• feeds between databases, applications and EDI links
• configuration baselines
• software releases
• configuration documentation, e.g. system and interface specifications, licences, maintenance agreements, SLAs, decommissioning statement
• Change documentation, deviations and waivers
• other resources e.g. Users, suppliers, contracts
• other documentation e.g. IT business processes, workflow, procedures
• network components
• Service Management components and records such as capacity plans, IT service continuity plans, Incidents, Problems, Known Errors, RFCs, etc.

The convergence with the evolving definition of metadata is clear. The CMDB concept moves further into classic metadata repository territory in the sources suggested for its population (Berkhout, Harrow et al. 2000, 7.9.5):

• requirements analysis and design tools, systems architecture and CASE tools
• database management audit tools
• document-management systems
• distribution and installation tools
• comparison tools
• build and release tools
• installation and de-installation tools
• compression tools
• listing and configuration baseline tools
• audit tools (also called 'discovery' or 'inventory' tools)
• detection and recovery tools
• reporting tools

One major difference between metadata tools and the configuration management space is that configuration management explicitly calls for integration with management frameworks (e.g., HP Openview, CA Unicenter, or IBM Tivoli) (Berkhout, Harrow et al. 2000, section 7.9.1); metadata repositories have not historically sought integration into operational systems of this type.

The concept of Configuration Item (CI)

The concept of a Configuration Item (CI) is key - everything within the CMDB is a CI, which are hierarchically decomposable. The Configuration Management business processes are all based around the concept of CIs.

Consider the following extended passage from (Berkhout, Harrow et al. 2000):

A data analyst reading the above passage as a requirements specification would probably start to build an information model looking something like this:

This is a highly flexible and abstract data structure; the core of it (Configuration Item and Relationship) will be recognized by seasoned data modelers as a standard design pattern for containing graphs (the notorious generalized many-to-many). Generally, use of such flexible data structures can be problematic. The question of the relationship concept alone is so fundamental to computer science and information system design that the ISO has devoted a whole publication to it, the “General Relationship Model” (International Standards Organization X.725 (1995)) – not to mention the extensive literature on constraints in the relational world.

The ITIL authors do not appear to have incorporated this level of information theory into their conceptions, and this lack of precision in defining relationships between CIs may have unfortunate ramifications for the reliability and interoperability of CMDB-stored information. Thus, ITIL seems to encourage the configuration management team to define and relate CIs with few constraints: the CM team is to "set up CI types, attributes, types of relationships, high-level CIs."

Using a tool based on ITIL principles, an administrator conceivably could

• define CI types for RAM chips and database tables,
• populate their instances, and
• relate them arbitrarily without regard to what semantically makes sense. (For example, a RAM chip should not be linked directly to a database table, but only via the server to which it is providing the service of main memory management.)

A key point in all this is that the definition of configuration items in a Service Management Framework configuration management tool is in a sense meta-modeling. Anyone attentive to the deep debates around the Object Management Group's standard models and meta-models knows that meta-modeling is a non-trivial, systems-level analysis and design task. Putting it into the domain of end-user configuration (even when those end users are IT administrators) may be problematic.

ITSM and standard meta-models

The issue of semantic constraints is well recognized by Object Management Group theorists:

The general theory of configuration item definition, at least as presented in ITIL, apparently lacks the ability to describe such constraints. Vendors may implement some functionality along these lines, but since there is no normative meta-model specified, such functionality would be proprietary.

Not that ITSM should go and re-invent such capabilities! They are already present in the robust standard meta-models authored by organizations such as the OMG and the Distributed Management Task Force (DMTF), which appear at risk of being ignored by IT Service Management.

Conclusions

The concepts of the metadata repository and the configuration management database (CMDB) are converging in scope. The differences in emphasis and history between these two conceptions will soon be irrelevant.

The current conception of the CMDB from the Information Technology Infrastructure Library (ITIL) and other IT Service Management sources pays insufficient attention to the data structures required to meet CMDB requirements. These data structures– including the user-defined Configuration Item concept– are meta-models, and the data they contain is metadata (data about data and the systems that manage it).

Meta-modeling is a complex and risky endeavor, with substantial standards activity. CMDB vendors, ITSM theorists, and the ITIL standard should start to explicitly look to the OMG and DMTF standards for reference definitions of configuration items and semantically sound constraints among them.

Without standards, tools currently sold as CMDB solutions may lock enterprises into proprietary vendor meta-models, resulting in minimal interoperability.

No single vendor can meet all of the requirements for comprehensive, end-to-end enterprise IT metadata, given the wide variety of tools and complex, specialized problem domains in the IT service function. Industry standards for IT metadata interchange are essential to the success of the configuration management (and broader IT Service Management) vision. This lesson was learned some time ago by CASE and metadata vendors, who have been supporting the OMG’s standards efforts. The new generation of ITSM vendors, however, appears unaware of these standards.

A tremendous opportunity presents itself in the potential alignment of ITIL process rigor with OMG meta-model rigor. Each has something the other needs. The emergence of Model-Driven Architecture in the software development lifecycle only furthers this need for standards-based alignment.

Think of ITIL as the "process" axis of a CRUD matrix, and the OMG meta-models as the "data" axis, and exciting possibilities start to emerge. A major industry convergence and realignment is in the works here, and as metadata professionals we have much to offer, if we take the time to study and interact with these new developments. This may mean reaching out to unfamiliar operational areas of our enterprises and making new alliances.

References

Berkhout, M., R. Harrow, et al. (2000). Service Support: Service Desk and the Process of Incident Management, Problem Management, Configuration Management, Change Management and Release Management. London, The Stationery Office.

International Standards Organization (1995). "Information Technology - Open Systems Interconnection - Management Information Services - Structure of Management Information - Part 7: General Relationship Model".

Marco, D. (2000). "Building and managing the meta data repository : a full lifecycle guide". New York, John Wiley.

Poole, J., D. Chang, et al. (2002). Common Warehouse Metadmodel: An Introduction to the Standard for Data Warehouse Integration. New York, Wiley Publishing.

Van Bon, J., G. Kemmerling, et al. (2002). IT service management : an introduction. [Canada], itSMF-Canada.