CA CMDBf paper oversells the CMDB Federation standard, as predicted

Apparently CA are working to an entirely different standard for CMDB Federation than the rest of us are. This is the only rational conclusion to be drawn from a recent white paper from them. Either that or they are shovelling the bull excrement at a remarkable rate. The paper is called "The Value of Standards-based CMDB Federation". CA are certainly extracting more value out of the standard than most of us.

Back in 2007 I predicted “WARNING: vendors may wave this [CMDB Federation white paper and now draft standard] around to overcome buyer resistance to a mixed-vendor solution. For example if you already have availability monitoring from one of them, sales people from the others may try to sell you their service desk and use this paper as a promise that the two will play nicely.” That prediction has come true with an over-reaching white paper from CA that promises way more than the standard delivers.

As I explained in an earlier post, the standard defines only how management tools can pass data between them - nothing about what they pass. I bet the much-trumpeted demos seen so far involved data massaging and informal backroom agreements beyond that dictated by the standard in order to get it all to work. I am highly skeptical (surpise!) about the likelihood that this standard would enable or even faciltiate anything useful in a real-world implementation.

It explicitly does NOT define

  • The mechanisms used by each management data repository to acquire data. For example, the mechanisms could be external instrumentation or proprietary federation and replication function. [Mechanisms will be redundant and will have no re-usability between tools]
  • The mechanisms and formats used to store data [Emphasis added. The internal format, including the internal data model and the unique identifiers is NOT specified. I believe this means you CANNOT easily write a report drawing and consolidating data directly from two CMDB repositories in native fashion]. The specification is concerned only with the exchange of data. A possible implementation is a relational database that stores data in tables. Another possible implementation is a front-end that accesses the data on demand from an external provider, similar to a commonly used CIMOM/provider pattern.
  • The processes used to maintain the data in the federated CMDB. The goal of the specification is to enable IT processes to manage this data, but not to require or dictate specific processes. [There is zero commonality or consistency required in the concepts, skillsets, teminology, tools, interfaces and workflows used by operations staff]
  • The mechanisms used to change the actual configuration of the IT resources and their relationships. The goal of the specification is to
    provide means to represent changes but not to be the agent that makes the change. [i.e. the standard is read-only]

No definition of acquire, store, maintain or change.

No data model or schema or semantics for data exchanged.

Nor does it define what security mechanisms or protocols should be used. There is no commonality of identity, roles, or policy. Issues such as confidentiality, integrity, audit and privacy will all be dealt with independently and redundantly within each vendor island. Any interoperability will be outside this standard. I note that the latest DMTF version seems to have quietly dropped pointing this out.

Now contrast that with some of the statements made in the CA paper:

The CMDBf standard provides to customers a vendor neutral standard for federation within a multi-vendor customer environment ...

The CMDBf services will make it possible to automate CMDB federation to the point that so-called “operational CMDBs” will become practical. An operational CMDB has access to the real-time state of the infrastructure and links it with defined business services ...

Defines web services for federating the data into the CMDB ...

The specific requirements for a CMDB and CMS to handle both synchronization and reconciliation are greatly improved. The ability to uniquely identify a CI across applications is improved through MDR synchronization and the unified service model ...

The CMDBf provides the flexibility to not only integrate MDR s at a data level, but facilitates the coordination of ITIL processes through a common definition and understanding of CI and CI relationships. It also provides a much better manner in which to present data, and provides a more consistent interface by ensuring the definition of CMDB objects, and specific attributes and relationships are consistent by all MDRs and their supporting applications ...

It provides the ability to create web-based services that simultaneous help manage the coordination of the various MDR s. Essentially, federation becomes the backbone of moving data around as a router in the backbone of applications talking to one another. [It is hard to reconcile this model of a router/backbone with CA's model of a master CMDB fed asynchronously via ETL from slave MDRs]

The paper uses the old vendor tactic of stating a genuine problem and then implying that the product fixes it (usually by talking about similar technical issues) when in fact it doesn't at all.

Another major issue is that almost all external data sources have a data model that is unique and not close to the data model of the CMDB. To incorporate data from the world external to the CMDB, a mapping and transformation of the CIs and the relationships must be performed. Clearly, superior approaches are needed to simplify data integration.

The CMDBf standard has no schema or semantics so it does not eliminate this need. The paper appears to have been written by several authors with inconsistent understandings of this. One author knows "The CMDBf consciously chose not to endorse a specific data model" while another says "As information is in disparate places, often residing in multiple databases, and has both semantic differences in the definition of data as well as syntactic data, the CMDBf provides a method to normalize that data" which is wrong.

It goes on to say "That helps increase the accuracy of data across all of the MDRs, and reduce the costs related to ongoing integration and maintenance" which is even more wronger: a one-way feed into a CMDB has zero impact on the feeding MDRs. The next bit could be right or wrong if anyone could work out what it says:

It provides the mechanism to describe a set of global requirements of applications as it pertains not only to its locally defined functionality, but its contribution to the bigger picture. Requirements therefore become as much about maintaining the optimization of interdependence of MDR s as it is in maximizing the performance of just one specific MDR .

Buried at page 15 out of 18 (yes 18!) pages is the statement that not only does the standard not address a unified data model, but it is your problem to solve yourself

This definition is outside of any specific vendor. It encourages an architecture design that is not partial to any one vendor and focused on the needs of the business. Each vendor provides its own data model, in combination with the standards of the CMDBf. The enterprise [thats' you!] can confidently build a unified definition service model and use it to ensure the proper coordination of effort between IT and the services IT delivers to the business.

Cop-out. As usual the technical geek-friendly tool solution does not address the real business problem - you are on your own there pal.

Here is the real reason why every client has to solve it alone:

the practical benefit to specifying a model was deemed secondary to the overwhelming need to publish a standard for federation services, which could be agreed upon in relatively short order.

The paper also contains this lovely little Three Thimble Trick

The CMDBf standard:
• Defines web services for federating the data into the CMDB across a common interface.
• etc

Choosing a standards approach [note: quickly generalise from THE standard to ANY standard] enables the following:
• Most organizations have made a commitment to SOA (Service Oriented Architecture) which views functionality as a collection of web-services. The main advantages of using web services are that they are transparent to the operating system and programming language of the base application. The CMDBf standard [talk about THE standard again to help folk forget this list is about ANY standard] is built on SOA standards like: SOAP , WSDL, XML Schema, WS-I Basic Profile etc.
• Standards free your technical staff to focus on issues that are unique to your organization rather than wasting scarce resources on reinventing the wheel.
• The standards approach mitigates both technical and business risk. Since many vexing issues have been resolved by the consortium, the probability of success in implementing the CMDB greatly improves.
• Using standards will shorten the time and cost of deployment.
• The standards approach means consistency across all federations which saves time implementing and maintaining a solution.
• Simplify the deployment in that a single rather than multiple technologies need be learned and deployed to implement federations.
• Streamline the effective spread of best practices.
• Maximize compatibility across vendors.

Now how many readers will come away with the subconscious idea that this CMDBf standard will "Maximize compatibility across vendors" and "Simplify the deployment in that a single rather than multiple technologies need be learned and deployed to implement federations"? Yet it has no schema or semantics or ... Nothing up my sleeves.

The paper also explicitly confuses integration and federation.

the systems being integrated (federated) evolve through time and often change their integration mechanisms ...

... maintaining the links or federations to those external MDRs ...

... In April 2006, a number of software vendors formed a group to address this integration issue. They called themselves the CMDBf working group ...

... a unified service model that accomplishes this alignment is nearly impossible to implement without the standardized federation provided by the CMDBf specification. The effort required to design, implement, and maintain each unique interface for necessary integration is prohibitive without standardized interfaces for federation ...

Without an industry standard for integrating IT data sources, this integration is expensive, difficult to maintain, and unlikely to be effectively implemented. The CMDBf standard provides a foundation for consistent, vendor-neutral implementation of IT integration.

Integration says the various MDRs and CMDBs can talk. Federation says they can understand each other. Just because a 5V power supply and an 18V power supply have the same shaped plug does not mean you can use both on your laptop. The API (socket) is defined by the standard; what flows through it is not.

An important strategy used by vendors is to shift the goalposts to their own advantage, to redefine the problem in terms of their own solution. In this case, the paper works hard to redefine federation as an asynchronous, Extract-Transfrom-and-Load scenario because that is what CA's technology does, whereas a realtime interface is just as valid and probably more useful

Federation often includes ["often": one option amongst others] some form of an Extract, Transform and Load (ETL) process that
extracts data from the MDR s, transforms the data and import it into the central repository.... This first part of federation is extracting the information from the MDRs; the next part is loading it into the CMDB. [now ETL is THE way of doing federation]

I asked a few people about this white paper and one made some telling observations that suggest it is not only hype but self-defeating (read: dumb) hype at that:

They are overselling the standard and as a result underselling the value of their product. It would seem more logical to me if they went with the line: "the standard gives you a base level of compatibility that will (hopefully) protect your investment and allow you to demand support from other vendors and our product adds on top it of it all the important stuff (like model reconciliation) that the standard doesn't do".

If I just read their white paper and don't know better, I get the impression that any CMDBf implementation will solve all my problems, so why would I get CA's? I guess maybe it's because they plan on being the first out with an implementation and they want people to buy them because that's the only way to "buy" CMDBf? But the idea of buying a product because it is the only one that implements a standard turns things on their head, because the whole point of standards is to have multiple implementation.

Never expect marketing people to be logical.

I can draw only two possible conclusions from this paper. Either CA have their own version of the standard that we don't know about or this paper is aimed at creating the illusion that the standard solves the federation problem. Which it doesn't. Marketing people are masters of walking the fine line between hype and misinformation. Sometimes they overstep it.

Seen any other examples of this CMDBf standard being oversold?

Comments

Not a silver bullet, but...

You're right, this initiative does not solve the problem. It does, though, illustrate that Vendors are aware that Customers have been having a problem with poor interoperability for several years.

The solution has been well known since before this initiative was started and involves working towards a standard Service Management ontology. Let's hope that customers insist on it.

poor interoperability

Hi Peter

Any standard ontology, even assuming the vendors got together enough to make it happen which is unlikely given the CMDBf history, will only exist at external interfaces to the existing tools for many years to come. That is, they would only implement a translation layer to present a standardised external API. I know what it cost to re-engineer the database model within the CA Unicenter tools and they are never going to find a business case to do that again any time soon. So all the internal interfaces, reports etc would still use a non-standard ontology.

Put simply, nobody is going to solve the problem of poor interoperability. Any heterogeneous environment is going to appear as just that, heterogeneous. You either get in bed with one vendor or you live with it. All suggestions to the contrary from vendors are just sales crap. The opportunity to standardise IT operational tools was about twenty years ago.

New open source tools might be built to a standard and they might make inroads if the lower cost model is attractive enough, but the incumbent investment is huge - there'd be a lot of inertia. We'll be stuck with the existing tools for a long time...

FUD you!

I think I may have had the same feeling when I read this White Paper. Of course I admittedly did not understand some of the techno-speak, including some within your post --- but I do know this; all the big gorillas have a vision. (Some have a scheme, but when it comes to the big gorillas it's the same thing). This is FUD, pure & simple.

What disturbs me most about this is that the light many IT organizations are seeing is not nirvana --- it's a virtual freight train heading right at them at very high speed speed. At the same time we nit-pick about CMDB/CMS/SKMS, (even PMDBs) the reality is we have static data and lots of workflow automation. (I could rant on about the BUSiness' inward focus on workflow, but this is about IT.)

The result is 5-year technical 'roadmaps' that promise a vision of nirvana; IT must understand that tomorrow's always a day away...be honest, does more workflow (as a result of automation) really result in simpler processes? Vendors are vendors. I'm not suggesting they are liars, but they DO have an agenda which may (or may not) map well with your objectives (or timeframe!).

I also am not at all sure it's easier for one of the big gorillas to 'integrate' multiple real-time monitors (from their latest feeding frenzy) into a seamless, intelligent, and end-to-end real-time performance monitoring solution for virtual, n-tier infrastructures ---- than it is to do some integration of a point product to ticketing systems. However if you buy into that vision, well then that's your business.

I may not be the geek here, but I know when I see FUD it usually means WAIT (until I can get something that comes to the MINIMUM you need for us to win).

I say, FUD you!

John M. Worthington
MyServiceMonitor, LLC

Syndicate content