The CMDB is an Operational Data Store

Longtime readers know that bringing some sense of architectural rigor to ITIL is one of my ongoing goals. The CMDB, viewed through an architectural lens, remains an ambiguous and challenged
concept. Consider just two recent CMDB discussions:

  • Is a Person a Configuration Item (CI)? Do People belong in the CMDB?
  • How can a CMDB be “federated” to other systems?

In my opinion, these questions show some confusion around data and distributed systems architecture principles. By way of examining them, I’d like to take a look at a concept proposed by Bill
Inmon et. al. in 1996: the operational data store.

In their book of the same name, the authors propose the following:

The operational data store (or ODS) is not a data warehouse. It is:

  • Subject-oriented
  • Integrated
  • Volatile
  • Current valued
  • Contains only detailed data

I suggest that all of these apply to the enterprise CMDB. Taking each in turn:

Subject-oriented. The ODS definition states it is “not organized around any specific application or function…[rather] organized around the major subjects of the corporation”
such as CUSTOMER and PRODUCT. The CMDB also is not organized around any one function, supporting Incident, Problem, Change, Release and many others. It is further organized around major IT subjects

Integrated. The ODS contains “an aggregation of detailed data found in the legacy systems that feed it. As the data is pulled into the ODS from the legacy systems, the data is
fundamentally transformed into a consistent, unified whole.” Substitute “element managers,” “platform managers,” or “federated sources” for “legacy systems” and the CMDB applicability is
clear. Vendors have spent much effort perfecting architectures to scrub incoming data into a “consistent, unified whole” in the CMDB.

Volatile. “Every time the data in the foundation source systems…changes, the operational data store needs to be updated,” on interval as needed from
transactional to 24-hour batch or longer. This is a particularly troublesome area for CMDBs, and the roots of this trouble are traceable to the ODS concept. Data integration
(extract/transform/load) logic is necessary; and yet unlike “pure” decision support systems, the ODS may also be directly updated. Inmon does not talk much about updating the ODS in his book, but
this article  does go into the issues
surrounding updateable ODSs.

Current Valued. “Data in the ODS is quite up to date; there is very little, if any, archival data found in it.” While current CMDBs may have configurable
audit trails, this is not the same as the extensive history maintained in data warehouses. And even today, a CMDB does not typically support complete general case rollback to the overall
configuration in effect at any given date.

Detailed. “The operational data store contains data that is detailed, while the data warehouse contains much summary data.” This is also true of CMDBs,
which, as transactional systems, are not suitable for extensive summarization. This is why the CMDB is not a data warehouse, despite some industry commentary to the contrary.

The CMDB’s primary responsibility is operational, although it may well feed downstream analytic systems. integrating operational data from a variety of “federated” systems has been a recognized
data architecture (or data design pattern, if you will) for some years now, originating first in business-facing systems. As with so many other aspects of ITSM, if we simply apply lessons learned
years ago in other domains our job will be far easier.

The ODS principles might answer the two questions posed at the start of the article as follows:

  1. It does not matter if people are “CIs.” PERSON (or PARTY) is clearly a well established data subject, and if you need it for your functional applications (e.g., for ITSM process assignment
    & accountability), incorporate it as required.
  2. “Federation” is as old as data processing, and just about every permutation has been tried at some point. The large enterprise system without both inbound and outbound integrations is a
    rarity. The CMDB, viewed as an ODS, does have a particular role to play as an integration and aggregation capability, across the various platform silos.

While some of the physical architecture in Inmon’s book is dated, the basic conceptual and logical data architecture principles still hold and are recommended to CMDB architects. Grounding the
CMDB discussion in well-established data management literature and principles can only assist those laboring to implement these particularly challenging systems. As Inmon notes

“There is a very dual role played by the ODS. On the one hand, the ODS is decidedly operational. The ODS provides high response time and high availability and is certainly qualified to act as the
basis of mission-critical systems. On the other hand, the ODS has some very clear DSS characteristics. The ODS is integrated, subject oriented and supports some important kinds of decision
support…Because of the many roles that an ODS fulfills, it is a complex structure. Its underlying technology is complex. Its design is complex. Monitoring and maintaining the ODS is complex.”

All true of the CMDB…

See also:

Share this post

Charles Betz

Charles Betz

Charlie Betz is the founder of Digital Management Academy LLC, a training, advisory, and consulting firm focused on new approaches to managing the “business of IT.” He has previously held positions as enterprise architect, research analyst, developer and product owner, technical account manager, network manager, and consultant. From 2005-2011 he was the VP and chief architect for the "business of IT" for Wells Fargo, responsible for portfolio management, IT service management, and IT governance enablement. He has also worked for AT&T, Target, Best Buy, Accenture, and the University of Minnesota. As an independent researcher and author, he is the author of the forthcoming Agile IT Management: From Startup to Enterprise, the 2011 Architecture and Patterns for IT Management, and has served as a ITIL reviewer and COBIT author. Currently, he is the AT&T representative to the IT4IT Forum, a new IT management standard forming under The Open Group. He is a member of the ACM, IEEE, Association of Enterprise Architects, ISACA, and DAMA. Currently, he serves on the board of the Minnesota Association of Enterprise Architects chapter and is the organizer of the Agile Study Group, a working group of local practitioners and faculty examing Agile methods from the perspective of theory and pedagogy. Charlie is an instructor at the University of St. Thomas, and lives in Minneapolis, Minnesota with wife Sue and son Keane.

scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept