The specification proposal comes from the CMDB Federation (CMDBf), a working group formed in April 2006 that includes BMC, CA, Fujitsu, HP, IBM, and Microsoft. At this point, the spec has been published in the public domain and is available for download and for anyone to apply.
The group intends at some point to submit this to a standards group, such as Oasis, W3C, DMTF, or elsewhere. But it is looking for market feedback before it decides where and when to submit the spec formally to a standards body.
The preliminary spec issued this week covers retrieving data and pushing data out from CMDBs, which are the databases for maintaining IT system configurations that is called for by the ITIL specifications. And it also makes provision for registering what configuration data exists out there so there is a known body of data on which systems are updated.
It assumes that the CMDB would have relationships with what the proposed specification calls Management Data Repositories, or MDRs. Those MDRs could be the databases or repositories maintained by point tools, such as an asset management, user directory, or service desk system, or it could be another full-blown CMDB itself.
The data exchange and communications mechanism is based on a Services-Oriented Architecture (SOA) and uses HTTP, SOAP, WSDL, and XML Schema standards. The service requests are designed to comply with the WS-I Basic Profile for interoperability.
The specification was written with the assumption that there must be a golden copy of each piece of IT configuration data. Although the spec authors drafted it with the idea of some form of hub and spoke system where at least one CMDB would be the system of record, in fact there is nothing in the specification that would prevent a distributed CMDB where the golden copy of different pieces of data, such as asset management or software deployment, would reside in their native systems.
Clearly, the proposal is highly preliminary. It only covers registering data and exchanging it, either via a push or pull mechanism. The group also plans to work on a mechanism managing the relationships and ascertaining the integrity of CMDB data sources that are federated, and at some point, it may also work on a pubsub mechanism for proactively updating CMDBs and MDRs.
Our View
This is an auspicious first step in that it gathers all the key incumbents in agreement that there must be a mechanism to share IT configuration data. With growing acceptance of ITIL, providers of tools dealing with the various aspects of IT infrastructure management have been busily retrofitting CMDBs to their offerings.
It’s remarkable that all major players in this space have signed on. This makes for an encouraging start that specifications for basic exchange of IT infrastructure data might avoid the all-too-typical curse of competing standards or standards factions.
From that standpoint, it shouldn’t be surprising that the group tiptoed around a couple of existing competing web services standards, WSDM and WS-Management, which specify the headers and schema used in SOAP messages for requesting performance data from systems management tools. Although some claim that the WSDM and WS-Management camps have already converged, the group showed a streak of pragmatism in dancing around these specs (which aren’t that widely used yet anyway).
As such, while it is great to have a repository of IT configuration data, the challenge is to have too much of it, or at least, too many sources. Consequently, some form of CMDB federation was inevitable given the fact that lots of tools maintain configuration data, and there had to be some way to coble together a single version of the truth.
But this is only a start, and while it’s a promising start, things could get sticky should the CMDB Federation get too ambitious. Specifically, we’re talking about semantic relationships. At some point, when you federate multiple sources of data together, there needs to be a handshake on what the data means and how it all maps together. Lacking taxonomies, the problem will have to be handled manually on a case-by-case basis.
We’re going to have to address the problem of taxonomy, conceded Marvin Waschke, CA senior technology strategist, who is also CA’s representative on the CMDB Federation group, who noted that the DMTF’s Common Information Model (CIM) has provided a useful precedent.
Nonetheless, the industry’s track record in this space is spotty, as CIM itself has not been universally adopted. For instance, CA’s CMDB makes some use of CIM, but CA feels that CIM does not go far enough. We have used our own customer’s experience much more, noted Waschke.