Iterating on IT Service

Followers of my blog know that I am sucker for a good standard. I am a shameless idealist. My personal mission is to make IT organizations hum (picture the current VISA commercials) and to ensure that when the inevitable hiccups do occur, the cause is not incompatible solutions from different vendors. While you've seen me blog often about the CMDBf, I've also been working on CML (Common Model Library), another standards initiative that will go a long way towards smoothing the integration bumps that IT organizations may experience.       

The CML (Common Model Library) working group, consisting of BEA Systems, Inc.; BMC Software; CA, Inc.; Cisco Systems, Inc.; Dell Inc.; EMC Corporation; HP; IBM Corporation; Intel Corporation; Microsoft Corporation; and Sun Microsystems, has announced the publication of a white paper that describes its plans for specifying a common library of models for use in IT management.

CML is another piece in the vendor neutral IT management puzzle. (You can read the white paper on the CML web site CML Project - Home.) CML is based on SML (Service Modeling Language), developed by a consortium similar to the CML group. The SML consortium has handed off the spec to the W3C (World Wide Web Consortium), which focuses on interoperable technologies to lead the web to its full potential. The W3C is in the midst of their process that will lead to endorsement of SML as a W3C standard. Microsoft began development of the language, then lead formation of the consortium for further inter-vendor development. Microsoft originated SML as a language for describing data center configuration. SML is based on XML Schema and Schematron and is able express constraints on configurations as well and the configuration itself.

SML documents have two parts. One part is a sort of abstract template. For instance, a very simple server might be modeled as an entity with several attributes, like name, physical memory, and disk size. This first part of an SML document is the model. The second part is instances of the model. An instance of our simple server model could be "name: Shasta; phys mem: 8 GB; disk: 100GB." Another instance could be "name: Rainier; phys mem: 16 GB; disk: 300GB." ... and so on. In SML, both the model and the instance are expressed in XML.

SML provides the language to express these models and instances, but not the models themselves.

CML proposes to provide a core set of models and building blocks. The CML group could provide a basic server model, for example. The existence of a universally acknowledged basic service model has important implications. First, each time a server has to be modeled, the modeler could go to the CML server model instead of inventing a new model on the spot. Second, models from the CML will provide some level of interoperability. If a vendor uses a private model of a server, another vendor may not have access to documentation of the first vendor's model. At the very least, the second vendor has to seek access to the proprietary documentation. At worst, the second vendor may be denied access to the first vendor's model because the first vendor has designated it to be private intellectual property. This can be a real obstacle to interoperability.

Interoperability of IT management systems is the real driver for SML and CML, so that the model of an IT component modeled by one vendor is comprehensible to a system built by a different vendor. CML, like the CMDBf, is an acknowledgement by the major IT management software vendors that interoperability is a serious goal for the industry.