One of the most authorative blogs on CMDBf has provided a comprehensive explanation of the emerging CMDBf standard, if you speak geek.

William Vambenepe is at the centre of the action on CMDBf and he's not afraid to talk about it. He says important stuff, such as this excellent recent summary of the state of play. Trouble is only some of the audience interested in CMDBf will understand it. It's in geek and neither Google nor BabelFish can translate it.

I know school-boy geek, or a mainframe dialect of it, so I'll have a go:

The standards body (DMTF) that the vendor committe turned the CMDBf spec over to, has inched its way forward with yet another draft specification. William reckons this is close to the final. [I've said that standards gestate like elephants: this one should be running round the Serengeti by now. ]

As we've discussed before, the standard doesn't do what everyone not-associated with it thinks it does: it doesn't define how to federate CMDBs. It just defines a standard way to query a CMDB, so if somebody builds a magic-glue product to do federation, they'll have a single interface to CMDBs from those vendors that implement this standard. [Or if you are daft enough to try to build your own. Don't. Use people.]. It is the first step towards federation - only a mile to go.

It is however a very cool query language that does cool things in a cool way.

William sees the standard going in one or more of three directions:

  1. Nowhere. Some of the vendors have crap data models inside their CMDBs which will make the queries work like crap. They'll blame the query.
  2. The vendor group will actually go on to develop the standard for federation that everyone thought they were doing
  3. CMDBf will become a fabulously successful language for all sorts of things beyond CMDB, ascending to stardom based on those cool features. [The fact that it has zero marketing, zero fan-base, and an uncool name may not help this option.]

Seven years from now when Cloud computing matters, this kind of federation will be important.

There. Those of you fluent in geek, how did I do as translator?


No ontology, no integrated Configuration Management System

This initiative has been dragging on for years. It seems to me more of a marketing exercise than a genuinely useful activity - technical as it does indeed appear.

There comes a time when things become commodities. That time is, sadly for all Service Management practitioners, not yet upon us with the CMS/CMDB. This is, as always when this occurs, because the vendors have no interest in the CMS/CMBD becoming a commodity. If you could mash your great Service Desk tool to the best CMS engine and feed that engine with the best data gathering tools (from your best asset register system, from the best suite of discovery tools, from your purchasing system etc) and then you'd really be able to start getting these tools to fly - but you'd no longer be in the market for the monolithic lock-in option that the vendors would like you to be. It's quite likely that the major components would be something quite different from the current Service Management tool sets - Content Management Systems look a very likely option.

None of this can happen, though, as long as there isn't a standard ontology that the various components can use. The interoperability forum has failed to grasp the nettle and produce a definitive ontology.

Lots of the bits are already there, and there are signs that this will emerge - assuming the current economic problems don't prevent this. It would be nice if a consortium of large end-users got together to push this - but they're too busy trying to survive!


Nice job translating! Hey, I have 273 other geek-talk-laden blog entries. Would you mind talking a pass through them too?


LOL, it's exhausting :) besides you talk miles over my head. I had the advantage of some prior knowledge on this one. Most of them I suspect would defeat me.

Syndicate content