The CMDB Federation proceeeds at its usual glacial pace

The CMDB Federation was formed in April 2006 by CMDB vendors so they could tell people they were moving towards a common standard of interoperability, known in the CMDB world as "federation", so the group is called the Federation. Two years later what have we got to show? Glacial advance. That's the way the vendors want it.

Way back when, the IT Skeptic said "I am still highly sceptical that their is any real commitment by the parties to a result, as compared to a need to be seen to be doing something. That need has now been filled for a while. "

We have crept up to version 1.0b of the draft specification, dated January 2008, so there has been some change since the first release of the specification.

More importantly the draft has been handed over to the DMTF. But don't expect that to mean a published standard any time soon.

I also said last year "standards gestate like elephants: it will be even longer before a standard sees the light of day. My latest prediction is that by the time it does emerge blinking, nobody will give a flying fox anyway. CMDB will be, like, so 2007, and IT's chattering classes will be whipping some new concept to fever pitch, safely way out ahead of the possibility of actually building or delivering anything."

William Vambenepe points out that

I can’t help noticing in the press release is that none of the quotes from the companies submitting the specification tout federation, but simply “integration” or “sharing”. For example: “integration and interoperability” (BMC), “share data” (CA), “sharing of information” (HP), “view, track and change information” (IBM), “exchange data” (Microsoft). This more realistic assessment of what the specification does stands in contrast to the way the DMTF presents it in the press release : “this specification provides a standard way to federate management data stored in multiple different data models”. At this point, it doesn’t really provide federation and especially not across different models.

Nothing on the DMTF website but press releases. Try to find anything by navigating from the homepage.

So, more hype and still no results. Nobody is mentioning any dates for the standard to emerge. I also said in the past "When that fine day dawns [of a published standard] we'll finally have the ability to build heterogeneous IT management environments. The IT Swami predicts that this will give a tremendous boost to open source tools such as Zenoss. They will be able to displace vendor tools one bite at a time instead of a revolutionary overturning, thus making them far more attractive to companies who want to ease carefully into open source. No wonder there is no great rush to finish this."

Still waiting. Funny that. In the meantime, as I warned previously:
"WARNING: vendors will waive this white paper around to overcome buyer resistance to a mixed-vendor solution. For example if you already have availablity monitoring from one of them, one of the other vendors will try to sell you their service desk and use this paper as a promise that the two will play nicely. "


ERP for IT

I am a big fan of "Cobbler's Children", and agree with a value-chain approach. However, buy-in for an "ERP for IT" would presuppose I believe in ERPs to begin with.
Like so much in IT and technology, ERPs appeal to a utopian worldview. There is no arguing that they are in some regards a perfect solution. But you could also say that the Command System Economy should be able to outperform free markets since redundancy can be avoided.

This isn't an entirely fair argument. My real point is that ERPs tend to calcify businesses mainly due to the huge costs required to make change. It's a bit like the failed Information Engineering approach proposed by Martin and Finkelstein (I shouldn't say failed, but it hasn't been a great success).

My [current] philosophy is to stop thinking of complex systems and repositories, and rather look at business as a collection of defined: data elements; business rules, and business processes (there is also a presentation & human factors aspect which affects all these things). These things [for lack of a better word] all tend to be irreducable, so in theory could be consolidated across the entire enterprise. I would even posit that most of what you see in the Zachman Framework can be boiled down to this level. The nice thing is, these are concepts that everyone understands intuitively (if it's explained correctly).

If you look at what's being done with Wikis and Business Rules Engines in particular, you can see we're moving closer a homogenous view of these things. However, we're nowhere near the level of comfort around this type of abstraction to go in and say, rejig a CMDB by tweaking this business rule or that data element, as we should be.

The vendors simply don't want to be reduced to such a commoditized level or rules and elements, or they patronize us by saying it's all too complex for us to understand and manage. So, they present their solutions as holistically novel, when it's really just a few business rules and data definitions that sets them apart from the competition.

"Believing in" ERP...

If by "Cobblers Children" you mean my book, thanks. However, if you don't "believe in ERP" then how again are SAP and Oracle making their money? Quick glance at their 2007 annual reports shows $18 bn US for Oracle (yes I know a lot of that is non-ERP, but still), 10 bn Euro for SAP (*all* ERP-related)...

ERP is a puzzling concept; you mention it in polite IT thought leader company and everyone holds their nose... but it appears to be one of the most successful Utopian failures ever seen in management information systems...

It's really not "ERP vs. No ERP." The ERP system becomes primary, but not all-inclusive. (Even MRP systems were distinct from shop floor control systems.) Business rules and BPM get absorbed into the core ERP framework (both SAP and Oracle have done this). They have formidable layers of abstraction already implemented with their 4GLs (Netweaver, Oracle Forms, PeopleTools). The pain and suffering mostly revolves around people:

1) not wanting to accept the delivered "best practice" processes
2) using the 4GL capability to develop their own solutions
3) suffering terribly when the next version of the delivered solution comes along, solving more of their problems or offering functionality they can't resist, so that their custom solution needs to be re-analyzed and re-factored. (Simple upgrades don't typically break solutions developed in-house on ERP frameworks per se as long as you just want to move them forward to the new version, it's more complex than that.)

I agree however with your architecture approach. First process, then logical data (ontologies & business rules). No argument there.

Charles T. Betz

Re: "Believing in ERP"

Hi Charles,

Yes, I am referring to your book. Honestly, it's the best Enterprise Architecture book I've come across in a long time, and I would easily put it in the same league as Spewak's "Blueprint". If you ever want to come up to Toronto and give a presentation to IRMAC (the Canadian arm of DAMA), just say the word.

Perhaps I'm being a bit hard on ERPs, and part of this has to do with some arrogance I've experienced when dealing with SAP. Without going into details, when I heard about the Waste Management debacle, I couldn't help but be reminded of a similar situation I nearly got myself into.

But I think you make a point that you can't really avoid an ERP approach, since whatever you build (assuming you're following a value-chain approach, which you advocate, and I agree with), will end up looking like an ERP one way or another.

Although I agree that a big problem is with managing people and expectations, an argument can be made that it all comes down to cost. Taking the Waste Management example (which for the sake of brevity, I'll assume you've heard of), Waste Management could have just thrown more and more money at the problem until SAP solved it. This is basically how SAP works: When they encounter a problem they haven't addressed, they simply incorporate a new sent of business rules and data elements into an existing module, or create a new module. If we just gave SAP enough money they would solve all our problems. However, since SAP consultants usually run at $1500/day (at least), this isn't possible.

My point is that we need to commoditize and socialize the concepts of business rule management, metadata management, and business process management, so that everyone can build their own ERP, or mix and match ERP "widgets".

As a recent example, I consulted for a training company that does roleplaying. They were heavily dependent on a scheduling tool to run their business. However, the solution they had was poorly designed, and needed to be replaced. My first instinct was to look for a pre-canned solution. There are literally hundreds of scheduling tools out there, and some of them even came close to meeting many of the clients requirements. However, none of those candidates had any flexibility whatsoever. In the end, I was forced to recommend a custom solution. With that said, there is a huge commonality of so many business rules, entities, and and business processes, that it seems ludicrous to build something like this from scratch. However, our concept of reuse is locked up in the software world, in the form of COM objects, Java Beans, and MySpace widgets. If we could instead think of a business rule/business process/data element "widget", then we wouldn't be impacted every time the flavour of the month changes. Instead, each time there are underlying shifts in implementations, we are left fighting with a new breed of code monkeys that act like they know more than we do.

Sorry for the rant - it's one of my big gripes, and I know you guys get this stuff, which is why I always read your blogs.


i'm putting this on a T-shirt


My point is that we need to commoditize and socialize the concepts of business rule management, metadata management, and business process management, so that everyone can build their own ERP, or mix and match ERP "widgets".

I'm putting this on a T-shirt. Great philosophy.

The idea of reuse of business rules etc is an important one. I especially like the point about commoditising them. In certain management circles, there seems to be an idea that business rules are how we do business, our unique competitive edge - and therefore can't possibly be shared. These managers need to see business rules and so on just as building blocks.

utopian worldview

"utopian worldview": thankyou! CMDB/SKMS summed up in two words.

And I think the calcification point is a great one, appiled to many technical ideas, not to mention outsourcing (another utopian holistic solution).

CMDB Standard – Truth or Dare

ITIL and CMDB are like religion and everyone's got their world-view of the heavens. Managed Objects Michele Hudnall wrote in a recent blog post:

"CMDB standards, do they exist or not? ... Every so often I run into this question and discussion and I view it as nothing more than fodder because while managing IT infrastructure principally does not change from organization to organization, I have never run into two organizations with exactly the same configurations and the drivers for their CMDB projects especially when an organization is mature enough to apply the CMDB to the services of the organization."


every organisation needs a unique data model

And every organisation needs a unique data model for payroll, general ledger, and warehousing too I suppose?

This kind of comment from Michelle is indicative of the immaturity of CMDB, that everybody thinks they are special.

While I'm not entirely supportive of Charles Betz's concept of "ERP for IT", I do agree that the models are the same in every organisation and CMDB can be commoditised. the consulting firms don;'t like to hear this though.

Managed Objects don't have a standardised commodity CMDB. When all you have is a hammer...

Just to set the record straight...

Not sure I agree with "ERP for IT" either. Paid too many dues back in the day as an ERP architect for Accenture, where I saw the good and the bad of it. Here are some relevant quotes from my book.

Also, the concept originated (as best I can tell) with General Motors CIO Ralph Szygenda.

Charles T. Betz

Merely a graph query language


As I've pointed out elsewhere, this whole effort is in meta-meta-land. Vambenepe accurately observes,

The current specification is a useful graph-oriented query language that is a good match for CMDB data. But it’s really just a query language (plus a simple registration system).

I am not convinced that they needed to re-invent this particular base computational wheel, given all the prior art... certainly surprised it took them this long. And bear in mind now that your CMDB developers will have to get their heads around this new technology, meaning talent management and training challenges...

Vambenepe also scares me when he says,

I think this change goes too far in the direction of turning a shared agreement to exchange data in XML into an assumption that the internal data models are all based on XML.

See Dave Hay in TDAN for an excellent primer on why this is problematic.

The real trouble in data management comes at the level of semantics, not grammar & syntax. What happens when BMC's CMDB calls something a "BusinessService" and IBM's calls something semantically identical an "ApplicationService"? That is the level of modeling that would be really useful. Solving such questions burns a lot of time (already so, for me). CMDBf has nothing to offer at the semantic level yet, and it's not clear they're even going to go there.

I don't have a whole lot of time for the DMTF and CIM. I think that set of standards was poorly conceived, far too detailed in taxonomic complexity and impoverished in specified, constrained relationships between entities. The products I'm having to deal with based on this "standard" are showing all the weaknesses I predicted years ago when I first encountered CMDB and ITIL (also here). Would you like to be able to say that an IT Service is directly and critically dependent on a particular RAM chip? Or that a Printer has a peer to peer dependency with a Database? Or that a Hard Drive contains a Mainframe? I can show you DMTF-derived products that let you say all that, and more. Simplistic graph metamodels just won't cut it.

Jury's still out, but what I'm seeing so far is not what I need as a standards consumer.

Charles T. Betz

Are the customers ready?

Marv Waschke has a CA-sponsored blog and comments on CMDBf regularly.

My view is that many vendors and companies are still focused on creating a single, unified CMDB - a la their interpretation of ITIL v.2.

Customer companies feel themselves to be, largely, captive of the vendor technology. Until a majority of vendors shift their approach, customer companies will be slow to shift their approach to federation.

Additionally, while the underlying technology may enable federation, that does not mean that the various internal organizational silos of IT have yet learned to collaborate so that federation is politically viable.

Perhaps before they worry about federation of their CMDB, customer companies would be better served to identify their service portfolio and break down their fulfillment processes. It seems that the process of creating accountability for the individual fulfillment steps tends to open up the discussion about breaking down silos.

Cary King
Minerva Enterprises
Managing Partner

misbegotten endeavour

Hi Cary

You know my view of CMDB as a solution looking for a problem, or more precisely a technical solution for a process problem (as you said).

But if you asked the market whether they want federation now I think you'd get a pretty clear answer.

if someone is going to embark on this misbegotten endeavour, then they either have to throw away their current investment to buy a single-vendor, single-database everything, a la CA/BMC/HP/Tivoli or they need federation to synchronise data across multiple data stores.

Sorry but "the client isn't ready" sounds a feeble vendor rationalisation for failure to deliver

Syndicate content