The Service Management Soapbox

Management tool integration has long been the bane of IT Operations organizations. Getting one tool to communicate with another has always been difficult because there are far too many incompatible data definitions that are used to integrate data from one tool to another. Each vendor has its own data model and various APIs to exchange data. Standards appeared in various forms from such bodies at the DMTF and OASIS as an attempt to address this issue. Despite their clarity and noble ambitions, adoption has proven lackluster.

In the integration battle, size matters. Large, established vendors defined the de-facto standards for integration. Incumbency gave HP and IBM heavy influence, as their early proliferation of OpenView and Tivoli respectively built an overwhelming installed base of management tools throughout the 1990s. Between the two, they captured nearly half of the management software market by 2004. a market with well over 100 vendors competing for share. Although some of the smaller vendors have taken share away from both, they still enjoy an almost co-monopolistic grip on the management market.

What this means from a tool integration perspective is that the HP OpenView API and the IBM Tivoli API remain as the most common integration mechanisms. If you are a smaller vendor, the first thing you must do is build your integration to plug into one or both APIs. This is a survival tactic, since your products must coexist with these two behemoths if you hope to survive in this cutthroat market. Both HP and IBM (and all management vendors for that matter) are changing dramatically themselves, but the OpenView and Tivoli APIs are so deeply entrenched that even HP and IBM are now bound to use their APIs for the long-foreseeable future.

The CMDB offers hope to those struggling with integration. As a common trusted logical repository of information, tools should extract what they need from the CMDB and write information to the CMDB (more on this in a later article and in our upcoming CMDB book [shameless plug!]). This way, all tools would go through the CMDB as a common integration point. Instead of a many-to-many direct integration model that grows geometrically (i.e., an O(n²) problem), you have a many-to-one model that grows linearly (i.e., an O(n) problem). This is far more scaleable and manageable.

Of course, this is the ideal view and one that will be reality within two years for many tools. Until then, we must confront at least three challenges:

1. Even CMDB integration requires good standards
2. We must ensure that vendors will embrace these standards
3. There are no true CMDB products yet available to solve the ultimate needs

I’m one who has long been skeptical of standards, but I believe there is a ray of hope here. The standards question is already being addressed by a loosely-knit body called the CMDB Federation Working Group (CMDBf). The first draft of the standard is now available at their web site. It is unlikely that CMDBf will be the long term trustee of the standard, but their initial work is very promising. Expect the DMTF, OASIS, W3C, or itSMF to take the reins for future evolution. All are in talks to make this next step. My choice is the itSMF, as this is a global body with a vested interest in its success and whose members are empowered to drive the standard’s proliferation.

As for vendor adoption, all indications are favorable for widespread acceptance – genuine acceptance – of this new standard. For one, the CMDBf itself was formed by BMC Software, CA, Fujitsu, HP, IBM, and Microsoft, so each of these vendors has an obligation and (more importantly) a desire to incorporate the standard. The CMDBf intentionally kept its “club” closed to this small set for a good reason. Fewer contributors meant they were able to make progress more quickly. The reason most standards languish is because there are “too many hands in the soup” so to speak. Political posturing and disputes inevitably hamper progress. The CMDBf evolved very quickly, as standards go.

Finally, we get to the dearth of CMDB products that can actually be purchased today. Plenty of cmdb products exist (note the lower case for emphasis) for various segments of the overall CMDB market requirements, but none are ready for the future vision that has been outlined by the CMDBf. Certainly, one should expect the CMDBf members to be shipping some of the first truly federated CMDB elements. These should first appear some time in the second half of 2008 and it will take another year or so before multiple management products can take advantage of these CMDB elements.

It is important to understand the concept of the “CMDB elements” here. There is no such thing as “a CMDB” in the monolithic sense. A “CMDB” can only work in a federated model, where the various software components must cooperate as a full configuration management system (CMS). The elements are analogous to the various musicians in an orchestra. Each performs its duties well, but the symphony cannot exist unless they all perform together. This federated CMS is the notion now espoused in the new ITIL version 3 description.

The future is bright for management technologies based upon such a CMDB, or more accurately, the CMS. The next two years will be a frustrating wait for many, but also an exciting opportunity for those who have the wherewithal to help drive configuration management and tool architectures. Those who embrace change and fuel its execution will triumph over those who foolishly attempt to resist the inevitable.

This entry was posted on Friday, January 18th, 2008 at 17:59 and is filed under Standards, Integration, ITIL, Management Tools, ITIL v3, CMDB. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.