The CMDB Federation is a brilliant piece of vendor marketing smokescreen

[Updated May 2009] The CMDB Federation standards initiative must be the most over-hyped vendor marketing smokescreen ever. Whenever anyone raises the bogeyman of proprietary CMDBs, the vendors wheel this one out as the future promise of interoperability. It is pure vendor double-talk. It solves little and is taking forever to appear anyway. It solves little because the standard defines only how management tools can pass data between them- nothiong about what they pass. I bet the much-trumpeted demos seen so far involved data massaging and informal backroom agreements beyond that dictated by the standard in order to get it all to work. I am highly skeptical (surpise!) about the likelihood that this standard would enable or even faciltiate anything useful in a real-world implementation.

It explicitly does NOT define

• The mechanisms used by each management data repository to acquire data. For example, the mechanisms could be external instrumentation or proprietary federation and replication function. [Mechanisms will be redundant and will have no re-usability between tools]
• The mechanisms and formats used to store data [Emphasis added. The internal format, including the internal data model and the unique identifiers is NOT specified. I believe this means you CANNOT easily write a report drawing and consolidating data directly from two CMDB repositories in native fashion]. The specification is concerned only with the exchange of data. A possible implementation is a relational database that stores data in tables. Another possible implementation is a front-end that accesses the data on demand from an external provider, similar to a commonly used CIMOM/provider pattern.
• The processes used to maintain the data in the federated CMDB. The goal of the specification is to enable IT processes to manage this data, but not to require or dictate specific processes. [There is zero commonality or consistency required in the concepts, skillsets, teminology, tools, interfaces and workflows used by operations staff]
• The mechanisms used to change the actual configuration of the IT resources and their relationships. The goal of the specification is to
  provide means to represent changes but not to be the agent that makes the change. [i.e. the standard is read-only]

No definition of acquire, store, maintain or change.

No data model or schema or semantics for data exchanged.

Nor does it define what security mechanisms or protocols should be used. There is no commonality of identity, roles, or policy. Issues such as confidentiality, integrity, audit and privacy will all be dealt with independently and redundantly within each vendor island. Any interoperability will be outside this standard. [Updated: I note that the latest DMTF version seems to have quietly dropped pointing this out, between versions 1.0.0 and 1.0.0c.]

Doesn't leave much, does it? In short this is once again a geeky technical solution to a cultural, organisational and procedural problem.

As I said before:

Vendors like to talk up auto-discovery because it is sexy, it is technology (i.e. they can sell it), and it looks like a silver-bullet solution to one of the most intractible problems of CMDB: discovery. Of course ...vendors are busy painting federation/integration technologies the same way.

Probably because the world is slowly waking up to the hyping of autodiscovery so we need a new hot gimmick to pimp.

My favourite bit of the current draft (lines 489-496):

A federating CMDB attempts to reconcile the item and relationship identification information from each MDR, recognizing when they refer to the same item or relationship. The federating CMDB performs this identity mapping using any combination of automated analysis and manual input... The determination of identity is seldom absolute and often must rely on heuristics because different MDRs typically know about different characteristics of an entity and thus establish different sets of identifying properties that characterize the entities they handle. Further, the determination may change as additional information is discovered and MDRs add, subtract, or change identifying properties as systems evolve.

There is no standard for the unique identification and reconciliation of objects. The reconciliation between repositories will depend in part on manual intervention.

Another good bit [now dropped from the latest draft]:

The Federated CMDB operates in a closed environment, in which some security issues are less critical than in open access or public systems.

Tell that to Managed Objects and their MyCMDB.

Then there is the question of the pace at which this beast is moving. There are zero commitments from DMTF or from the vendors for any sort of timeline for delivery of anything. As I have pointed out in the past,

"WARNING: vendors will waive this white paper around to overcome buyer resistance to a mixed-vendor solution. For example if you already have availablity monitoring from one of them, one of the other vendors will try to sell you their service desk and use this paper as a promise that the two will play nicely. "

The vendors have no interest in ever delivering this thing. Quite the opposite: it will generate a wave of support issues and negative sentiment if it ever sees the light of day. In as much as it does actually make some interoperability possible, it will also present a crack in the proprietary shell for open source management tools. Far better that it should exist as some vague promise of a rosy future.

The next time a vendor presentation implies that CMDBf or DMTF is going to provide seamless interoperability and/or a common data layer, throw something.

The IT Skeptic is in the mountains. This blog post was pre-loaded on January 2nd. Apologies if events have rendered it out of date - I won't know.