“Federationing”

I am glad to see that, as it inches towards standardization in the DMTF, the CMDBf specification is getting more visibility. Forrester’s Glenn O’Donnell recently wrote very positively about it on his blog, presenting it as a key enabler for a federation of MDRs (Management Data Repositories, a term introduced by the CMDBf specification so don’t look for it in ITIL). He argues this is the only way (rather than a single data store) to fulfill the ITIL-defined role of a CMS. Rob England (the IT Skeptic) has also shared his thoughts about CMDBf and they were noticeably less enthusiastic, to say the least. While Glenn calls the specification “profound”, Rob calls it “the most over-hyped vendor marketing smokescreen ever”. There is plenty of room in between them, which is where I sit. As I explained before, it does have real value (as a query language/protocol for system integration) but is nowhere near providing “federation” capabilities.

I am happy to see Glenn approve of CMDBf and I agree with him that accurate specialized MDRs are more useful than a single store that attempts to capture all the relevant data. As Glenn puts it, “pockets of the truth are far superior to unified ambiguity”. But I wasn’t very comfortable with the tone of his article, which seemed to almost encourage the proliferation of these MDRs. Maybe he was just trying to present a clean break with the “one big CMDB” approach and overreached. Or maybe I am just not reading properly.

Because while I agree that the answer is not “one and only one store” I also don’t want to loose the value of having as much unification of the IT model as possible. Both at the data level (i.e. same metamodel/model, consistent retention/roll-up policies…) and the access level (i.e. in the same physical store, with shared access control, accessible using a well-known DSL for data manipulation…). Metamodel transformation and model bridging are costly (in accuracy, maintenance, reliability). If your CMS does more than just support a  “model navigation” GUI it may then need to run large queries that go across several portions of your IT model, including multiple different domains (e.g. a compliance rule kicked-off at the app level based on the type of data it manipulates that ends up having to look at the physical location of the servers running the hypervisors for the virtual machines that power the app). Through such global queries you can apply configuration rules, do impact analysis, event correlation, provide context to your transaction tracing, etc. No consolidation means no such queries (or a very limited subset). Considering the current state of federation, there is a lot more that you can do with your CMS if you have a very small number of MDRs rather than a sea of “federated” MDRs. This is why, as Oracle acquires IT management companies, we deliberately integrate their repositories with Enterprise Manager.

[UPDATED 2009/4/8: More, along the same line, from Glenn and his co-author Carlos Casanova available here. And my CMDBf partner-in-crime Van Wiles also responded to Glenn, bringing a BMC perspective.]

1 Comment

Filed under Application Mgmt, Automation, CMDB, CMDB Federation, CMDBf, Everything, IT Systems Mgmt, ITIL, Mgmt integration, Modeling, Query, Specs, Standards

One Response to “Federationing”

  1. I enjoyed reading your post. I wholeheartedly agree with your (and Glenn’s) assertion that federation MDRs is really the only practical approach to creating a unified view of the IT data. I see a lot of parallels in the current discussion and one that I saw 10 years ago around unification of another data domain i.e. customer data (e.g. CRM, billing, order management systems). That resulted in a completely new product category called Master Data Management.

    I would urge your readers to take the marketing message from the big IT vendors with a big pinch of salt. Of course they want the customer to buy everything from them. However the idea of a customer standardizing all of their IT management systems from one big vendor is neither practical nor smart. Why would a customer want to replace all their existing IT management systems (i.e. MDRs) if they are working fine? And why would they want a single vendor lock-in? So a multi-vendor world is here to stay and the only solution to solving the problem is federation. I would add two things to your post:
    1) It doesn’t have to be about full federation or full decentralization. Hybrid approaches can also work i.e. centralize (replicate) some data that needs frequent access and analysis. But you need to determine why you need the unified data in the first place e.g. compliance, release management, forecasting, process streamlining etc.
    2) Pay close attention to your processes especially those outlined in ITIL v3 e.g. security management, change management etc.

    Thanks for an interesting post.