A guide to conceptual data models for IT managers

With a focus on business processes and data models, this chapter takes an architectural approach to IT management.

The following is an excerpt from Architecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children, written by Charles T. Betz. It is printed with permission from from Morgan Kaufmann, a division of Elsevier; Copyright 2006. Click here to download the complete chapter, "A guide to conceptual data models for IT managers."


A conceptual data model

Data modeling is arguably the most widely used technique in modern systems analysis and design, but it isn't always used well. Too often, technically oriented "modelers" jump straight into excruciating detail, dense jargon, and complex graphics, incomprehensible to process-oriented participants and other mere mortals.

The root problem is a misconception—data modeling has been equated with database design. That's like equating architecture with the drafting of construction blueprints. Of course, the architect's work will eventually lead to precise, detailed blueprints, just as the data modeler's work will eventually lead to precise, detailed database designs, but…it can't start there, or the subject-matter experts will soon mentally "check out." Without their participation, the data model won't be a useful and accurate description of their business. And that's exactly how a data model should be regarded—not as a database design, but as a description of a business.
--Alec Sharp


Dialog: Data model discussion

Chris: One thing that has us all puzzled is exactly how the ITRP concepts fit together and work with other non-ITSM concepts. There's a lot of terminology, and it seems like things overlap sometimes. For example, what is the relationship between a Configuration Item and an Asset? Also, some of what ITIL calls for is not exactly how we do business. Do all Configuration Items go through our data center change control process? What is the relationship between a Service Request and an Incident? Is a Service a Configuration Item? Is a Service Offering? Are Applications Services?

Kelly: That's why we're going to turn to one of the most important aspects of enterprise architecture: the creation of a conceptual data model.

Chris: A conceptual data model? What good is that? We're probably not going to build anything—we're going to purchase products. Sounds pretty technical.

Kelly: That's why I call it a conceptual data model, and yes, it's relevant even if you are purchasing products. There are a lot of vendors out there selling various flavors of IT enablement and IT governance tools, and they have a lot of overlap between their products, often with slightly different terminology.

A conceptual data model is not technical—it's about clarifying the language describing our problem domain so that we understand exactly what we mean by a Configuration Item (CI) and how it might relate to a Service. And this is something you need to put together independent of the products— because it's going to be your road map that helps you determine what products you need.

Chris: Will it help me translate the vendor-speak?

Kelly:Absolutely. One vendor may have a "service catalog entry" and an "order," and another vendor may call the same two things a "template" and a "service instance" In the conceptual data model (also called a "reference model"), they are Service Offering and Service. It doesn't matter what the vendors call them, but you need to understand that any service request management solution should have both concepts. Doing the data model helps us understand our requirements better and communicate them to the vendor.

How do we gain more precision around hard-to-define concepts like Change or Configuration Item? One technique used for many years is an "entity relationship model." Other (not necessarily synonymous) terms used in this general area are "conceptual model," "logical model," "domain model," "ontology," and "class model."

An entity relationship model helps clarify language by relating concepts together in certain ways:

  • A Configuration Item may have many Changes applied to it, and a Change may be applied to multiple Configuration Items (many to many).
  • A Machine may be related to one and only one Asset, and an Asset may be related to one and only one Machine (one to one).
  • A Configuration Item may be a Service, Process, or Application (subtyping).

These relationships are visually represented as shown in Figure 3.1

Figure 3.1: Data modeling key


Key point to Figure 3: Vive la difference
Your organization's concepts and terminology will be different. Count on it. This does not make either your Organization or this model right or wrong. The point is to start asking the questions: Why does the model call for two concepts when we use one? One concept where we use two? Do we have any ability to relate concept A to B as the model calls for? Do we need it? Why do we relate X to Y when the model doesn't?

Some data modeling methodologists emphasize naming the relationships (typically with a verb phrase such as "is a part of"), but others do not see this as critical, and this book does not systematically do this.

Using these tools, we can start to carefully structure the relationships between the various loosely used terms of IT governance (Figure 3.2).

Pictures such as this only tell part of the story. They require a detailed discussion of each box (or entity), what it means, and how to interpret the lines (relationships) to the other boxes.

Figure 3.2: IT enablement conceptual model

Figure 3.2 is a conceptual data model. It is primarily about refining language and concepts. The goal of this model is not technical precision but rather resonance with common industry usages, which overlap and are not well delineated. It's an attempt to push common usage toward more rigor and admittedly encounters a number of problems in this effort.

Key point to Figure 3.2: Overwhelmed?
If this model looks overwhelming to you, you might want to review the section later in this chapter titled "An Iterative and Incremental Approach to Configuration Data Maturation."

It also deliberately omits a number of details that would be necessary to realize a solution. Attributes obviously are not included (e.g., Serial Number on Machine or Date Signed on Contract). Omitted entities are generally intersection entities and dependent entities that elaborate on the core concepts. Some notes on possible approaches for elaborating this into a full logical data model are covered in the data definitions.

Building a model such as this for an industry that is not yet mature in its process best practices and terminology is challenging. The relationships among entities such as Release, RFC, Service Request, Project, and Configuration Item might have many permutations. This is a reference model, presented as a starting point for your own analysis. Reasonable professionals may come to different conclusions about which entities should be related to which.

This picture, technically speaking, is not the model. It is only one view on the model. One characteristic of a good conceptual data model is that its central concepts can be represented with a one-page view; there are always more details to add. Thus, in the subsequent sections other entities will appear, along with relationships not drawn in Figure 3.2.

Dig Deeper on MDM best practices