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 werent included. But the notion of keeping the workgroup to a modest number of vendors was considered essential if progress was going to be madea 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.
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 industrys 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 Im writing this, its July 20ththe 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 companys 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 Ive 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 DMTFs approval of the CMDBf standard may indeed herald the equivalent of the next moonwalk for ITafter, say, the move to distributed computing and even the advent of the Internet.