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
such as SERVER, APPLICATION, and DATABASE.
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:
-
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. -
“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:
