Last week, the CMDBf gathered in Redmond and successfully ran its first interoperability tests. The atmosphere was collegial with everyone in the room on a first name basis. The sign Microsoft facilities had placed on the door read “CMDB Federation of the Planets.” Interesting place, Redmond. Next door, preparations were in full swing for an Xbox tournament, complete with balloons and a truckload of pizza.
To give you some background on the testing, back in February, the group published a white paper entitled “The Federated CMDB Vision” describing its vision of CMDB federation—one in which a federated CMDB pulls CI data from other data sources, called Management Data Repositories (MDRs), via a standardized interface. The federated CMDB then can reconcile the CI data, that is, determine whether a CI is new to the federation, or the same as an existing CI already in the federation. Alternatively, an MDR may push CI data to the federated CMDB. In the push model, the federating CMDB retains a list of reconciled CIs. When a push federated CMDB is queried, it can go to the MDRs for data that has not been cached in the federating CMDB, but the reconciliation is already done. This white paper became the basis of the interop test scenarios.
The interop testing was done on the interface between federated CMDBs and the MDRs that supply the data. The API consists of a WSDL (Web Services Description Language) interface spec and a specialized query language. Both push and pull models were tested. The results were posted on a grid displayed on the overhead projector. The prototypes were all implemented on laptops. For connectivity, Greg Goodman from CA brought along a home wireless router.
One by one the combinations were called off and tested. “CA to IBM?” “HP to Fujitsu?” Each was checked off on the grid. As the grid filled in, it was quickly apparent that the tests were uniformly successful, with only a little last minute tinkering required.
Success was not surprising. Most of us had implementations outside our firewalls and we had all run tests on each other’s systems for a couple of weeks. The interop test was an anti-climax. The real challenge was the run-up that transformed a theoretical spec into something that worked in practice.
I have been involved with several standards efforts. The CMDBf is different because it comes so close to affecting shipping products. XPath 2.0, for example, is an important standard. It affects the way many products will be written in the future. Nevertheless, as important as it is, I doubt that any vendor will have to abandon a product feature because something appears or does not appear in the XPath standard.
But we run that risk every time the CMDBf convenes. Federation is a market requirement for a commercial CMDB. We have all implemented federation in our own ways and we often compete on the strength of our federations. When the standard is published, some of those implementations will have to change.
You would expect this to generate heat, but, perhaps surprisingly, it has not been a problem. I think everyone recognizes that the nature of IT management is changing. Before ITIL®, you could build an IT management application any old way you pleased. If it had any ROI for the customer, you had a product. Customers look at IT more holistically now. An application must not only have ROI in its own right, it must also add value to the whole system, not just an isolated part. And the system is almost always made of parts from a variety of vendors. The vendor who works with the most other players has the advantage.
And what is the easiest way to accomplish this? With a standard, of course. So the CMDBf team meets twice a week, every week. We all bury the competitive hatchet and work together. We discuss the fine points of a query language one meeting, the subtleties of marrying incompatible inheritance systems the next. Arguing passionately. Agreeing inevitably, because that’s our job. The interop testing last week was just another step on the way to achieving a federation standard.
Comments