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.


how fundamental the problems are with actually using CMDBf

For a taste of just how fundamental the problems are with actually using CMDBf, read this . I had concerns about how on earth relationships rather than entities are shared via CMDBf but didn't understand enough to speak up [That'd be a first!]. Van Wiles does.

Most over-hyped promise?

Totally agreeing with you. However, when you say "the most over-hyped vendor marketing smokescreen ever", I can think of much more over-hyped things over the past 30 years, just remember the promises of SQL and Distributed DB Access, supposed to be the panacea for universal database declaration, manipulation, query, interoperability and portability. After 30+ years of claimed commitment from vendors and efforts from consortia, it's still NOT working...


OK so "the most...ever" was over-hyped :)

As you say this is the latest in long line of vendor crap that trails behind them like dung behind a herd of migrating cattle.

From my upcomng book:

For those who were there, remember how all data was in flat files but relational databases were coming and they were going to fix everything? We followed “the one true Codd ”. Once we had all our data in one place, referential problems and inconsistencies would vanish. With SQL all programming would be easy, and we wouldn’t need many programmers anyway because users would write their own queries.

I got my start programming and teaching 4GLs , the end of COBOL and other crude 3GLs for ever. Once again, the end of programming was nigh as end users could learn to write such simple languages. They said the same thing about COBOL, the “business-oriented language”, when my Dad learnt about it in the 1970s - but this time it was really true. Really.

Then we all built vast corporate data models. Once we got all our definitions in one place, and achieved third normal form across the organisation, then all the answers would just fall out. I worked on one project that had four and a half thousand beautifully normalised tables. Boy that really helped those end users write their SQL. Slowed those 4GLs down too, and hardware hadn’t gotten cheap yet – we were still running IBM 370s.

Next, CASE tools were going to transform programming. Once we generated code in one place, end-users would draw pictures and finished applications would burst forth automatically. Twenty years on that one still hasn’t laid down and died.

Structured programming, modular programming, object-oriented programming (once we get all the methods defined in one place…), information engineering, repository (once all the meta-data is defined in one place…), RAD , JAD , directory (once all the data is indexed so it looks like it is in one place….), data warehousing (once we have a copy of all the data in one place…), EAI (once we glued it all together automagically so it looks like it is in one place…), MIS and then EIS (once the executives have all the key data in one place….), CRM (once all the customer interactions are kept in one place…), extreme programming, content management (once all the documents are in one place…), HTML, ERP (once we have the whole damn business in one place…), Web Services (once all the APIs are dynamically linked, and the UDDI lets us look up everything in one place…), and of course e-commerce [embarrassed silence while we all blush].

A decade ago it was PCs, client/server and three-level architectures to decentralise everything. Now it is browsers, thin clients, blades and virtual machines to centralise everything.
Every one of them has added a little value and a lot of complexity to IT. Not one has been the silver bullet the vendors and consultants had us believe. Every one cost more and delivered less than promised. Is it any wonder the business is cynical?

Not that they have a right to toss too many stones about. While all this was going on in the data-centre, over in the boardroom we had Quality Circles, BPR , zero based budgets, TQM , 6sigma, MBOs , KM , coaching, the one minute manager, centres of excellence, intellectual capital, ISO9000, outsourcing and off-shoring, triple bottom line, and of course e-commerce …

under fire from a big gun

Returning from the tranquility of the Southern Alps I find myself under fire from a big gun: William. I can ignore most vendor stuff if I want but Mr Vambenepe has the street cred in this industry to be taken seriously. Which leads me to the point I forgot to make in ths article but I have made it in earlier posts: The backroom boys at these organisations tend to be the decent ones. I worked for one of the companies in question for a long time so I know, though I worked at the sordid pointy end. I am not reflecting on the individuals involved - please be clear about that. When I refer to cynical or machiavellian motivations I am talking about the companies as a whole, the executives who run them, and the games that go on between them.

So WV and the others doing the work on CMDBf are doing real work and aiming for a real result. But I don't believe their bosses at a sufficiently high level give a f***. "Yeah yeah we are working on that" will be a sufficient response for the forseeable future.

Sales and presales people do use initiatives like CMDBf to patch over obvious cracks - I stand guilty as charged. If William's sales poeple don't do it, then this indicates that they are selling at a higher non-technical level (entirely commendable) and/or not selling CMDB at all (entirely believeable in both cases: too many sales people at HP still sell tin and at Oracle sell business apps. Sales people have very small brains that seldom hold more than one product at a time.)

Perception is reality. This standard is generally perceived to be the one that defines how systems management vendors will plug-and-play. I don't want it to make coffee - I just want it to federate tools from disparate vendors. The name kinda implies that. It doesn't.

As discussed, federation is a process and people problem. Lots of standards deal with process and people problems. The technical layer (or rather the chunk of that layer that this standard covers) is a necessary but far from sufficient piece of the federation solution.

the Identity Blogger weighs in

Another significant blog doesn't agree. the Identity Blogger says "this borders on pure fantasy".

I'm not saying every salesman in town will be pushing CMDBf as a product feature. But for any sale into a heterogenous environment, the question of integration/federation often comes up from the geeks and this will be used to hose it down. If you get this question use this answer.

Syndicate content