The CMDB Federation, a vendor consortium, has at last released a document describing their cooperation over CMDB. The good news is that CA and Microsoft are on board now, along with the original members BMC, Fujitsu, HP and IBM.

The original press release said a draft specification would be out by the end of 2006: The specification is still nowhere to be seen. Surprise. Getting these vendors to work together is like putting six cats in a suitcase.

The idea is a good one. This initiative is essential for the IT operations software industry in general, not just CMDB vendors. We need a fundamental common CMDB standard and this could be it. And proprietary lock-in is a big problem for consumers and this standard could go a long way towards solving that issue.

The document strikes me as sound, but not profound; documenting the obvious so they can all agree. It is not explicit in the document that the CMDB will include real-time status information. In places it is only implied: “Application (transactions) monitoring application … Resource monitoring application(s) …­ Event analysis application …”;

In other places I get the impression the data is fairly static: “… performance records, event logs … A federation service provides the interface to add, modify, and delete resource definitions.”

Without status data it is hard to understand how incident management or proactive service level alerting can be supported. Without it this won’t be the IT operations Babel-fish we seek either.

“Storing information that associates resources with services ...” is left to later. This is a cop-out. The exclusion of this issue supports my contention that deducing and tracking relationships between “real” CIs (configuration items) and abstract services is too hard for the current technology.

Caveat Emptor

WARNING: Vendors may wave this white paper around to overcome buyer resistance to a mixed-vendor solution. For example, if you already have availability monitoring from one of them, sales people from the others may try to sell you their service desk and use this paper as a promise the two will play nicely.

Well they may — one day. Look at the timeline. It has taken the best part of a year to get the gang together and produce an in-principle white paper for comment. I would say it would be optimistic to expect a draft spec in anything less than another year since the devil is in the details.

I am still sceptical there is any real commitment by the parties to a result, as compared to be seen to be doing something. That need has now been fulfilled for a while.

One reason the big vendors may not want a standard is open source monitoring tools already threaten the growth of their markets. If the lower-cost tools can get past proprietary barriers, they can elbow their way into existing clients much more easily.

The main reason it will not happen though is politics. These companies have a poor track record of sticking together. The press rooms are littered with announcements of cooperative partnerships; Hollywood marriages last longer.

People outside the industry don’t always realise just how viciously competitive it is and everyone will be playing games for maximum advantage. For example, who brought Fujitsu to the table? Any number of service providers could lay claim to having CMDB expertise (don’t tell me Fujitsu claim status as a tools vendor on the strength of the internationally famous Systemwalker). Perhaps their presence gives someone two votes? The major operations software vendors have released a white paper describing how they plan to cooperate on ITIL CMDB. Don't hold your breath waiting for anything to come of it.

The CMDB Federation, a vendor consortium, has at last released a document describing their cooperation over CMDB. The good news is that CA and Microsoft are on board now, along with the original members BMC, Fujitsu, HP and IBM.

The original press release said a draft specification would be out by the end of 2006: The specification is still nowhere to be seen. Surprise. Getting these vendors to work together is like putting six cats in a suitcase.

The idea is a good one. This initiative is essential for the IT operations software industry in general, not just CMDB vendors. We need a fundamental common CMDB standard and this could be it. And proprietary lock-in is a big problem for consumers and this standard could go a long way towards solving that issue.

The document strikes me as sound, but not profound; documenting the obvious so they can all agree. It is not explicit in the document that the CMDB will include real-time status information. In places it is only implied: “Application (transactions) monitoring application … Resource monitoring application(s) …­ Event analysis application …”;

In other places I get the impression the data is fairly static: “… performance records, event logs … A federation service provides the interface to add, modify, and delete resource definitions.”

Without status data it is hard to understand how incident management or proactive service level alerting can be supported. Without it this won’t be the IT operations Babel-fish we seek either.

“Storing information that associates resources with services ...” is left to later. This is a cop-out. The exclusion of this issue supports my contention that deducing and tracking relationships between “real” CIs (configuration items) and abstract services is too hard for the current technology.

Caveat Emptor

WARNING: Vendors may wave this white paper around to overcome buyer resistance to a mixed-vendor solution. For example, if you already have availability monitoring from one of them, sales people from the others may try to sell you their service desk and use this paper as a promise the two will play nicely.

Well they may — one day. Look at the timeline. It has taken the best part of a year to get the gang together and produce an in-principle white paper for comment. I would say it would be optimistic to expect a draft spec in anything less than another year since the devil is in the details.

I am still sceptical there is any real commitment by the parties to a result, as compared to be seen to be doing something. That need has now been fulfilled for a while.

One reason the big vendors may not want a standard is open source monitoring tools already threaten the growth of their markets. If the lower-cost tools can get past proprietary barriers, they can elbow their way into existing clients much more easily.

The main reason it will not happen though is politics. These companies have a poor track record of sticking together. The press rooms are littered with announcements of cooperative partnerships; Hollywood marriages last longer.

People outside the industry don’t always realise just how viciously competitive it is and everyone will be playing games for maximum advantage. For example, who brought Fujitsu to the table? Any number of service providers could lay claim to having CMDB expertise (don’t tell me Fujitsu claim status as a tools vendor on the strength of the internationally famous Systemwalker). Perhaps their presence gives someone two votes?
The major operations software vendors have released a white paper describing how they plan to cooperate on ITIL CMDB. Don't hold your breath waiting for anything to come of it.

The CMDB Federation, a vendor consortium, has at last released a document describing their cooperation over CMDB. The good news is that CA and Microsoft are on board now, along with the original members BMC, Fujitsu, HP and IBM.

The original press release said a draft specification would be out by the end of 2006: The specification is still nowhere to be seen. Surprise. Getting these vendors to work together is like putting six cats in a suitcase.

The idea is a good one. This initiative is essential for the IT operations software industry in general, not just CMDB vendors. We need a fundamental common CMDB standard and this could be it. And proprietary lock-in is a big problem for consumers and this standard could go a long way towards solving that issue.

The document strikes me as sound, but not profound; documenting the obvious so they can all agree. It is not explicit in the document that the CMDB will include real-time status information. In places it is only implied: “Application (transactions) monitoring application … Resource monitoring application(s) …­ Event analysis application …”;

In other places I get the impression the data is fairly static: “… performance records, event logs … A federation service provides the interface to add, modify, and delete resource definitions.”

Without status data it is hard to understand how incident management or proactive service level alerting can be supported. Without it this won’t be the IT operations Babel-fish we seek either.

“Storing information that associates resources with services ...” is left to later. This is a cop-out. The exclusion of this issue supports my contention that deducing and tracking relationships between “real” CIs (configuration items) and abstract services is too hard for the current technology.

Caveat Emptor

WARNING: Vendors may wave this white paper around to overcome buyer resistance to a mixed-vendor solution. For example, if you already have availability monitoring from one of them, sales people from the others may try to sell you their service desk and use this paper as a promise the two will play nicely.

Well they may — one day. Look at the timeline. It has taken the best part of a year to get the gang together and produce an in-principle white paper for comment. I would say it would be optimistic to expect a draft spec in anything less than another year since the devil is in the details.

I am still sceptical there is any real commitment by the parties to a result, as compared to be seen to be doing something. That need has now been fulfilled for a while.

One reason the big vendors may not want a standard is open source monitoring tools already threaten the growth of their markets. If the lower-cost tools can get past proprietary barriers, they can elbow their way into existing clients much more easily.

The main reason it will not happen though is politics. These companies have a poor track record of sticking together. The press rooms are littered with announcements of cooperative partnerships; Hollywood marriages last longer.

People outside the industry don’t always realise just how viciously competitive it is and everyone will be playing games for maximum advantage. For example, who brought Fujitsu to the table? Any number of service providers could lay claim to having CMDB expertise (don’t tell me Fujitsu claim status as a tools vendor on the strength of the internationally famous Systemwalker). Perhaps their presence gives someone two votes?
I hasten to add that this is not a reflection on the individuals involved in this project. The backroom technical people at these organizations tend to be the decent ones. I worked for one of the companies in question for a long time, though I worked at the sordid, pointy end.

I don’t doubt the authors of the white paper are having entirely congenial discussions of honourable intent. 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.

Best Case Scenario

In the event the specification gets done (and it hasn't all ended in tears first), a formal standard must be promulgated. This is what is needed, and it is the stated intent in the white paper (“adoption and standardization”).

Standards gestate like elephants, so add another year or two. If we are lucky, some of the vendors will invest the millions required to support the standard in parallel with its development so they will release the software along with release of the standard. Look forward to that two or three years from now, best case.

What of the vendors not involved? Those already in the club probably figure the task of keeping the original six together is hard enough without encouraging more. Once they get to a standard then everyone else will follow along — they hope. They are taking a gamble. The risk is a competing proposal for a standard, or worse a competing standard. DCML, anyone?

I can’t help feeling this initiative would have greater chance of success if it were itSMF- or OGC-driven. Both parties have been conspicuously absent when it comes to driving the ITIL software industry, though either party would have perceived right to do so.

Their hands-off approach is one cause of a peculiar phenomenon: the software industry and their parasitic analysts have seized on the only bit of ITIL that involves a new technology, CMDB, and run off with it. Look at the press release, or a recent ITSM Watch article and a fascinating pattern emerges: The vendors themselves never refer to ITIL in quotes, and seldom is it mentioned in article text. It is left to itSMF to make the linkage.

The consortium white paper mentions ITIL twice at the start and several times at the end, and not at all in the body of the paper. It does not once cite the ITIL books on what a CMDB should be or do (although to be fair the blue book is so light on this topic that such a citation would be there to show respect more than for anything useful).

The ITIL trademark is not acknowledged (other than with a “®”), OGC is never mentioned, and there are no references. ITIL is not defined at any point. There will be explanations for all of these omissions, but I am a great believer in the Freudian slip. You judge.

Finally, this consortium does not operate under the umbrella of any of the existing industry alliances: OASIS, OMG, DMTF, etc. or of a standards body or itSMF or OGC. Apparently, this is so they can move quickly. If so, it isn’t working, yet. Once you guys get past a jotting of notes by some friendly geeks, let us know, OK?