The IT Skeptic - Comments for "The CMDB Federation proceeeds at its usual glacial pace"

i'm putting this on a T-shirt

JoePearson — Sun, 25 May 2008 07:05:38 +0000

Neil:

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.

Re: "Believing in ERP"

Neil Hepburn — Fri, 23 May 2008 21:36:36 +0000

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.

Cheers,
Neil.

"Believing in" ERP...

Charles T. Betz — Fri, 23 May 2008 11:26:33 +0000

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
http://www.erp4it.com

utopian worldview

skeptic — Thu, 22 May 2008 20:07:55 +0000

"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).

ERP for IT

Neil Hepburn — Thu, 22 May 2008 18:32:40 +0000

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.

Just to set the record straight...

Charles T. Betz — Thu, 22 May 2008 02:56:44 +0000

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
http://www.erp4it.com

every organisation needs a unique data model

skeptic — Thu, 22 May 2008 00:12:00 +0000

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...

CMDB Standard – Truth or Dare

Frank Strong — Wed, 21 May 2008 13:52:24 +0000

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."

More: http://www.wearebsm.com/managed_objects/2008/02/cmdb-standard-truth-or-dare.html

Merely a graph query language

Charles T. Betz — Mon, 19 May 2008 03:04:19 +0000

Skep,

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
http://www.erp4it.com

Skeptic - if you don't mind....

Cary King — Sat, 17 May 2008 21:20:00 +0000

[this comment moved to here]

misbegotten endeavour

skeptic — Sat, 17 May 2008 20:25:00 +0000

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

Are the customers ready?

Cary King — Sat, 17 May 2008 16:15:00 +0000

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

http://community.ca.com/blogs/itservice/archive/2008/02/14/cmdbf-specifi...

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
www.MinervaE.com