CMDBf: IT's Next Moonwalk - Page 1

The CMDBf specification was first introduced by the CMDB Federation Workgroup in August of 2007, and the DMTF announced the creation of a working committee around the CMDBf specification on November 27, 2007. The CMDB Federation Workgroup included BMC, CA, Fujitsu, HP, IBM and Microsoft in Q3 2007, a condition that inspired some political questions among many other vendors who wondered why they weren’t included. But the notion of keeping the workgroup to a modest number of vendors was considered essential if progress was going to be made—a contention that I would have to, on balance, support.

Looking at the specifics, the CMDBf specification leverages SOA standards such as SOAP, XML schema, HTTP, and WS-I (Web Services Interoperability). It describes how APIs and calls to CMDB registration APIs can be pre-built into the management data repositories (MDRs) of management tool set providers.

similarly, registration APIs are pre-built into a federating CMDB, along with calls to query APIs. In this way, a federating CMDB can access data from a multiple MDRs using the query service defined in the specification. And MDRs can push data to a federating CMDB using a registration service. The specification also supports CMDB-to-CMDB federation, as CMDBs can extract data from each other using the query service. In essence, the specification supports data access in a federated mode, as well as bi-directional data sharing across federated CMDBs.

If such a vision is to become reality, then the industry needs a more consistent approach for federating multiple sources than the current rag-tag mix of adapters, APIs, and other technologies that still make federation, especially federation across multiple brands, such a painful experience.

Is such a vision even plausible? If one were to believe that CMDBs are essentially “repositories” optimized to bring new life into old platform technology, one might well ask, “Why bother?”. But, on the contrary, CMDB and now CMS initiatives were born out of two parents. One of them is the IT Infrastructure Library (ITIL) with its focus on process. But the second parent for the CMDB/CMS phenomenon is that age-old requirement to reconcile different management investments in a way that finally works.

To some degree, how plausible this is (along with the entire future of CMDB systems) will depend upon the industry’s willingness to support this IT equivalent of the “cure for cancer”. In other words, it depends on your willingness to say “no” to those Darth Vader salesmen/women who try to ensnare you in unibrand solutions when your investments and skill sets are, as is normal, multi-brand.

As I’m writing this, it’s July 20th—the day I expected to be hearing from the DMTF with official notice. It is, instead, the day that one of the supporting vendors, in this case CA, announced its participation in this “newly approved, industry-wide” specification. In other words, here we are on the 40th anniversary of Neil Armstrong and company’s fateful lunar landing, and the volume of noise around the ratification of the CMDBf standard is by contrast conspicuously low. No doubt this signifies some real industry ambivalence around federation and, as if for good measure, at the same time I’ve just heard that 25% of Americans now believe that the lunar landing may have been a hoax.

Putting the moon aside for a moment, I would argue that the federation discussion is a troubling one primarily because most significantly game-changing events are by definition troubling. I would even go further to suggest that in its quiet, almost clandestine way, the DMTF’s approval of the CMDBf standard may indeed herald the equivalent of the next moonwalk for IT—after, say, the move to distributed computing and even the advent of the Internet.