This Blog
Syndication
Recent Posts
Tags
Calendar
Archives
Iterating on IT Service
January 2008 - Posts
-
CML: Another milestone in the push for interoperability
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.
-
Sample Implementations Ease Adoption: A Parallel between CMDBf and SNMP
To quote Yogi Berra, "it's déjà vu all over again." I could not shake that feeling after reading an article entitled "Providing a CMDBf Query and Registration Service" that appeared in the Eclipse Wiki on the COSMOS project page. Eclipse is an open source community and COSMOS (Community-driven Systems Management in Open Source) is an Eclipse incubator group for building open source systems management tools. (A number of CA developers contribute code to COSMOS.) The Wiki article includes an open source implementation of the CMDBf Query and Registration services. I believe this implementation will go a long way toward promoting the adoption of the new CMDBf specification for federating CMDBs.
Quicker than you can say "disco ball," I was transported back to the eighties, working with one of the most successful standards I have ever worked with: SNMP (Simple Network Management Protocol). The IETF (Internet Engineering Task Force) published the RFCs (Request For Comment) for SNMPv1 in 1988. Around that time, I was consulting at a large aero-space corporation, writing network management software. Of course, RFC 1065, RFC 1066, and RFC 1067 became hot topics soon after they came out and the "yellow book"--Marshall Rose's The Simple Book: Introduction to Network Management--showed up in every cubical. The best part of SNMP was the sample implementation documented for reference that was available over something new: the Internet. I don't remember who wrote it, but I do remember FTPing the sample code down to my work station, poring over it, compiling it, and finally writing it into the tools I was working on.
Without that reference implementation, SNMP probably would not have made it into our tools. We were under no compulsion to follow any particular standard. We were more worried about SNA than TCP/IP at that time anyway. But SNMP was not only simple, it was easy to implement by following the lead of the sample implementation. If it had not been so easy, we probably could not have justified including it in our tools.
I see a lot of similarity between SNMP twenty years ago and the CMDBf spec today. The CMDBf is a great idea, but no one is holding a gun to anyone's head about implementing it. The success of the spec depends on the bang for the buck. The vendors in the consortium have already put money and IP on the table by writing the spec. It's in their interest to implement it. But the rest of the community has to make up their minds based on the return on their investment.
The return is there. I don't think anyone questions that configuration item (CI) management data must be federated, and that vendor-neutral federation makes tremendous sense. The problem is on the investment side. Until there is a critical mass of implementations working together, there won't be much return on any single implementation of the CMDBf services.
Just like the SNMP reference implementation, an open sample CMDBf implementation reduces the investment required to implement CMDBf services, smoothing the way for acceptance.
Print
Email
Rate