CMDBf: IT's Next Moonwalk
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.
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 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.Albeit, this is a moon walk of significance primarily to IT, its organization, its politics, and the broader market supporting management and optimization of IT services. It is probably not going to become vernacular among most American households, and the day when teens access CMDB systems for fun is happily either never going to happen, or so far out in the future that none of us beyond the age of 30 need worry about it.
But if the CMDBf specification actually leads to true modularity in the choice and deployment of best-in-class management applications and suites, effective CMS federation will utterly transform the management marketplace. And if it enables levels of information sharing and automation that can support truly revolutionary ways of managing and provisioning new services, IT organizations may be willing to deal with the though, thorny politics of change.
This is certainly not the end of the road or the only road for CMDB federation. The new specification does not include recommendations for a single standard around data schema, which given the existing diversity of solutions already in the market place is actually a good idea. And it doesnt yet support full bi-directional requirements so that a single MDR from a management tool or suite can fully leverage all the power of its surrounding CMDB System. But the standard does go a long way to enabling broad access to information across multiple sources and, if it were fully supported by most tool set providers, would begin to ease the issues of federation significantly. Given the preliminary state of most CMDB System deployments, the new specification might even be viewed as ahead of market.
As the CMDBf specification becomes adopted by a widening variety of management vendors, as I believe should happen over the course of the next several years, TCO for CMS deployments will be dramatically improved. But perhaps even more significantly, the vision of the CMDB as a single, monolithic repository will gradually become a thing of the past. And then the rebirth of the CMS as a mix of technologiescentered more in metadata management, reconciliation, and orchestration than in data storagemay allow those of us who have cared for decades about the effective assimilation of management resources to celebrate by planting a brand new flag on the lunar landscape of IT Service Management.
Dennis Drogseth is VP of Boulder, Colo.-based Enterprise Management Associates (www.enterprisemanagement.com), an industry research firm focused on IT management. Dennis can be reached at firstname.lastname@example.org.