from www.erp4it.com

Federated CMDB: dimensionality is key

"Let's put all of IT's data into one database and call it a CMDB!"

"Okay! Wait, this is too hard!"

"Then let's keep it in several databases and call it a 'Federated CMDB'!"

"Okay! That's easier! Wait - why are we calling it a CMDB at all?"

...

That's my summary of the current discussion around the latest wrinkle in IT Service Management, the so-called "federated CMDB." (This Google Search brings up BMC and others; also, Gartner has picked up on this theme.) Having realized that it's difficult to consolidate and rationalize internal IT data (just as it's difficult in any line of business) various folks are now putting the brakes on the monolithic, totalizing CMDB concept.

This is an unsurprising development. As I've noted elsewhere, the problem generally is one of the overall rationalization and convergence of all the systems enabling the IT supply chain. CMDB is just one particular theme in many ongoing discussions of how to better manage IT; it's a provocative concept, and now the scope challenges are biting back.

As in any other major segment of business, a systems engineering perspective is needed to make sense of what IT systems and data should remain tightly coupled, and what systems/data can be loosely coupled. Calling the union of all persistent internal IT data a "CMDB" is not terribly useful; we need to understand the general functional and systems architecture of internal IT capabilities like asset management, configuration management, project management, service level management, and so on. A totalizing "CMDB" concept is a premature solution in search of the wrong problem. What's the overall map of the IT supply chain: function, process and data? That's the truly useful exercise in my book - more on this to come separately.

However, while we're on the topic of "federation" with respect to a database of any sort: even in the case of loose system coupling (i.e. "federation") it is necessary to determine the means by which any coupling can occur at all.

Take two databases. They are "federated" if you can cross-reference the data in them and run an integrated report somehow; if not, they are just two ships passing in the night. I would argue that a crucial insight into how to "federate" a CMDB is to be found in the work of Ralph Kimball and his concept of "conformed dimensions" in data warehousing. If you are trying to rationalize your internal IT databases but not necessarily physically centralize them, then Ralph's work is a key starting point. Additionally, as this Google search shows, the concept of "federated data warehouse" has received much attention over the years, and this material should also prove useful in the federated CMDB discussion.

Kimball's primary insight is that, while you can have physically separate data "marts," they must share common reference data, or "dimensions." In the IT Service Management/IT Governance space, these common dimensions include:

- Organizational hierarchy
- Application portfolio (rolling up into both the org hierarchy and SLAs)
- Program/Project portfolio
- Data subject areas (hierarchical, not relational)
- Service level agreements
- Enterprise calendar
- Enterprise operational locations & hiearchy

Conformance means no difference. Even if they are in five different databases, they always agree, and process is in place to keep them in agreement, backed by strong senior executive support.

Some of these will be well understood by your data warehousing group (e.g. calendar & location); others will be new ground. You may unearth intractable process and political difficulties in your search for conformance. You'll probably also be confronted with the challenging topic of slowly changing dimensions if any part of your federated CMDB is historic and being used for analysis.

For example: Suppose you have incidents rolling up by application portfolio and org hierarchy, and you've developed some nice trending reports over the years. Then a re-org happens. How do you handle it? Hint: there are three major approaches, all with pros and cons that need to be understood in depth.

The application portfolio for me has proven to be the most important and difficult. I have seen up to ten different lists of applications in one organization, causing no end of confusion around what IT was really doing and who owned it. Your enterprise architects should own this particular dimension; they are best suited for managing this slippery consensus concept of "application." Note that reconciling so-called "discovery" tools (and their welter of physical IT data) to a master "application" dimension (of logical concepts with an often tenuous relationship to discoverable assets) is a problem still not well understood by any vendor or research firm as far as I can tell.

The project portfolio can also be a source of pain. Just as with systems, people tend to refer to projects by myriad imprecise names. What is the system of record for your projects? Does every "federated CMDB" database that references project do so via an unambiguous project ID or picklist derived from the system of record? Or is just the project name casually typed in with no check for accuracy?

Even though a "federated CMDB" would look somewhat foreign to practitioners of Kimball's "federated data warehouse" (because data warehousing is mostly about analytics, and a CMDB has a significant operational component) the principles for alignment are identical. Learn from the experiences of your professional colleagues in data warehousing!

For further reference see this Google search on "Inmon vs. Kimball," and Kimball's books.