Cooperation Between Vendors Over CMDB?Im still waiting, writes ITSMWatch columnist Rob England.
We said Gartner points to the history of multi-vendor cooperation in the management arena as a reason to approach the news with scepticism." After nearly a year, the consortium of BMC, Fujitsu, HP, IBM, CA and Microsoft released a document in January 2007 describing their cooperation over CMDB. I wrote a suitably skeptical article about it at the time. Let us update that article with events of the past two years―not a big task.
One important point to note here is that the standard doesn't do what the lay public 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.) It is the first step towards federation―only a mile to go. Dont let vendors tell you otherwise.
Back in 2007, I predicted: 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, salespeople from the others may try to sell you their service desk and use this paper as a promise that the two will play nicely. That prediction has come true with an over-reaching white paper from CA that promises way more than the standard delivers, and probably other examples, too.
The Road to Hell ...
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 standard and CMDB just could be it. Also, proprietary lock-in is a big problem for consumers that this standard would go a long way towards solving. I am still skeptical that there is any real commitment by the parties to a result; as compared to a need to be seen to be doing something. That need has now been fulfilled, at least for a while.
One reason the big vendors may not want a standard are the open source monitoring tools that already threaten the growth of the big vendors markets. If the lower cost tools can get past the proprietary barriers they can elbow their way into existing clients that much more easily. The main reason it will not happen, though, is politics. These companies have a poor track record of staying in bed together. The press rooms are littered with announcements of cooperative partnerships. California marriages last longer. People outside the industry dont always realise just how viciously competitive it is: everyone will be playing games for maximum advantage.
I hasten to add that this is not a reflection on the individuals involved in this project. The backroom technical people at these organisations 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 dont doubt that the authors of the draft standard 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.
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 money to support the standard in parallel with its development so they will release the software along with release of the standard. In their dubious white paper, CA claims to be doing this and no doubt others are too. It is not such a big task as first thought now we see how basic the standard is.