The IT Skeptic - Comments for "The CMDB as a dead elephant, it cannot be done ... NOT"

lost in translation

Tim — Fri, 08 Aug 2008 14:02:56 +0000

I like this example and I especially approve of the need for IT to be run like a business. I think that it misses a couple of important points, however:
- CMDB is the responsibility of IT operations, ERP etc are built by IT projects. IT ops seems to be mostly weak at understanding what it means to manage a business. IT ops also seems to have an even deeper fascination in technology (over processes and people) than your typically naive business manager.
- when the ESM vendors started building "CMDB"s, the term meant something closer to a CMS in ITILv3, ie the total repository of all information about CIs. This is about the same as the scope of "all state changes for each individual item of stock tracked by an ERP system." I've seen CMDB projects generate 1M CIs in the shared estate of only 1500 servers - this is the usual mess that you get with poor analysis. Managing this amount of data and the schema to represent it would blow any business case.

I don't think that there's a proven need for ERP in most businesses and as often as not it's just used as an excuse to break existing, broken, business processes. Nevertheless ERP vendors (or at least those who are literate in data management and business analysis) would be much better builders of ITIL/CMDB products, and SIs at implementing them and the supporting business processes and technology adoption, as there is a lot in common between these problem domains. At least they'd not allow the scope creep and runaway expectations of typical CMDB projects.

The suggestion was not that

Visitor — Wed, 06 Aug 2008 19:14:00 +0000

The suggestion was not that only business units can succeed with a CMDB. IT should have been involved. Moreover, they should have led the way.

The point was about business impact. ERP, JIT, SKMS, and the like, get traction in business units because the thread is woven between investment and business outcomes. When the argument for a CMDB leads with these effects, then many of the objections on this blog become irrelevant. When IT abandons this premise, ignoring it in favor of “few IT initiatives are truly strategic”, it steps into well known management trap generically described as a vicious cycle.

Every service provider is subject to competitive forces. It may not be for market share or revenues. It may compete simply for the goodwill of its stakeholders or for scarce budget dollars. If the provider doesn’t grasp this, if it doesn’t make explicit that internal initiatives aimed at improving operations are based on its direct effects on the day-to-day realities of its business’ life, then it won’t prosper for long.

When customer needs are predictable and well-defined, a service provider can afford to be a passive order taker. But this is seldom the case. Customers have to deal with their own competitive forces, financial problems, directives to please shareholders, or the need to improve their own internal efficiencies. IT has managers also. And it doesn’t take long for an IT organization to be put on its heels as it realizes it is capable of efficiently churning out robust systems but for the wrong services. [To mangle another Drucker quote.]

Symposium

JamesFinister — Wed, 06 Aug 2008 14:27:17 +0000

Is there some way that we could arrange an on-line symposium/masterclass to cover both Charles's and Ian Clayton's ideas?

design-build-operate

Charles T. Betz — Wed, 06 Aug 2008 13:18:02 +0000

Also, it is a misreading to say that the lifecycle portfolios reduce down to a simple design-build-operate model. The whole point is that they have independent logics which interact in non-deterministic ways.

Charles T. Betz
http://www.erp4it.com

Is vs. ought

Charles T. Betz — Wed, 06 Aug 2008 03:11:34 +0000

As the one who proposed the multi-portfolio approach that Cary and Skeptic have both favorably commented on, let me make clear that I propose it as an explanatory model, not a recommendation. It has originated from my own (also NDA) experience, as I reflect on the dynamics and interactions characterizing my day to day activities in the midst of a $3bn IT spend.

I have no idea whether it is the way things ought to be, and certainly no evidence. But I think that accurately understanding the reality of how things are, is a first step towards changing them. At this point it is merely a hypothetical model. My next priority, in my copious spare time, is devising some falsifiable tests to determine whether this model has superior utility, as compared to ITIL's overly numerous processes-cum-functions. One basic granularity principle in process analysis is "fewer=better" and any time processes start numbering more than a handful, we probably have opportunities for aggregation and synthesis.

Who has invoked the Sisyphus analogy? And what has been proposed as an alternative to the "design-build-operate" paradigm? Little to be found in ITIL v3 I fear, with its lifecycle model essentially framed around same.

And suggesting that CMDBs only succeed if owned by business units is interesting; I have worked in multiple organizations where that would simply mean no CMDB.

Charles T. Betz
http://www.erp4it.com

what I meant by "can't"

skeptic — Tue, 05 Aug 2008 21:29:37 +0000

I'm fascinated by the way so many debates hinge on subtleties of definition.

Ben said "Your CMDB should be the (master data) hub, and not the single data store (which actually only replicates data from one tool into another). I think this confuses a lot of people, for some reason the CMDB has morphed into this humongous store all repository. There is no need for this, your CMDB should federate and not replicate, a key distinction."

This is in fact what ITIL says, at least in some places, or at least what the authors meant, but it is far from clear from the books and it sure as heck ain't what some vendors and many implementors have interpreted it to mean. The concept has indeed morphed out of control, as the industry terminologically debases it to mean what suits them.

What we mean by "CMDB" matters. So does what I meant by "can't". I meant it is not sensible, not practical. I'll keep bringing us back to those four questions I posted above.

passive

Cary King — Tue, 05 Aug 2008 15:08:47 +0000

Peter Drucker wrote that, "The productivity of work is not the responsibility of the worker but of the manager."

Whether IT is more than a passive order-taker is entirely up to IT - based upon the capability of the IT business relationship managers and the IT service management product teams.

Few IT initiatives are truly strategic - in the sense that they create a meaningful shift in a company's capability relative to competition. IT is a service provider.

Like any service provider IT can choose to get to really know their customers needs and anticipate those needs with service products that support their customer, or they can choose to wait passively until their customer tells them what services they need.

In a competitive marketplace, those service companies that are passive market followers must compete on low price. In the world of IT - that's simply an other word for outsourced.

The point of the portfolios is to provide a business-like structure that delineates roles within IT with a business perspective - to run IT like a business within a business.

To bring this back to CMDB - it seems to me that a CMS is a tool to provide information to IT decision makers so they can improve the consistency and quality of their execution.

My issue is that companies approach building a CMDB without first defining clear decision roles. And the result is muddled decision bottlenecks - and poor results.

Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com

Several times now you've

Visitor — Tue, 05 Aug 2008 14:30:44 +0000

Several times now you've expressed your admiration for this multi-portfolio approach. Is there any evidence of its efficacy?

My readings of it show it to be another "design-build-operate" model of IT; what some describe as the Sisyphus-like struggle of rolling IT initiatives uphill only to have them come rolling back down as legacy systems in need of support. In other words, it provides a tactical means for IT survival but ignores the business' aspiration to use IT as more than a passive order-taker.

Reasonable arguments, but, I

Visitor — Tue, 05 Aug 2008 14:24:04 +0000

Reasonable arguments, but, I think, destined to not go far. As long as the argument for a CMDB/CMS reads like a manifesto for operational excellence, this skepticism won't be resolved.

I have seen large-scale CMDBs successfully implemented (and multiple SKMSs, for that matter. Really, Skep). But here is the catch: they were done by business units, not IT. They each required significant investments and long-duration efforts. McKinsey has a nice ROI on SKMS – though they call it something else. In fact, it was so nice, the business unit of a firm invested almost $20MM in the effort, including the provision of a 30-million-item CMDB/CMS. The system is operational and, thus far, fulfilling expectations (generating revenues). (Before they naysayers start howling, I cannot provide proof or names. All the work is under heavy NDA. Sorry. These firms prefer if competitors remain oblivious.)

IT had zero involvement in these initiatives. Worse, if I look at those firms, the same constructs do not exist on the IT side. Why? Because they ignore technology’s potential to affect business outcomes, the goal to make IT a differentiating factor; instead, they concentrate on rolling the IT machinery faster and cheaper. In other words, they don’t seek to support the business’ aspiration to leverage IT as a differentiating factor.

ROI and the CMDB

Visitor — Tue, 05 Aug 2008 13:37:51 +0000

There are holes with this argument. For any “major consumer of capital”, ROI becomes more important, not less.

While ROI can be qualitative and quantitative, ROI isn’t achieved by putting data into a system. It is achieved when business productivity is improved or additional value created. And the value should exceed other potential investments.

Even G/L and HRMS is subject to this standard. If they weren't, then the investments would be spent elsewhere. In the case of G/L, for example, ROI can be assessed through:
- Timely financial visibility to stakeholders and improved financial control
- View lines of business as profit centers
- Compare forecasts with budgets through variance analysis and reporting

Also, a positive ROI is seldom sufficient. A non-regulated investment should return, at a minimum, more than the cost of the capital required to fund the initiative, often 18% for many of the global Fortune 500. Can the CMDB meet this minimum threshold?

When the argument is IT has no choice (regulatory requirements) then the discussion moves to fulfilling the requirements in a cost-effective manner. Can the requirements be fulfilled by a sound asset management process and quality Bill-of-Materials, for instance? If so, then the regulatory argument for a CMDB is moot. I believe this is The Skeptics point.

CMDB ... yes we can!! (to plagerize a phrase)

BBRand — Tue, 05 Aug 2008 13:04:55 +0000

Hi “Skeptic” and others

Thanks for the welcome, hope to be back here more.

You have out-ed me I fear. Yes, I work for ASG, which is a CMDB vendor, and I am VP for Professional Services. I was trying not to make that too obvious as I was not writing this from a vendor perspective, but hopefully IT in general and inserting some experience we have in this area.

I posted a reply in the original thread as well yesterday, where I talk about how ROI and the chosen implementation method should be linked together, and that the CMDB is built up of discrete layers. Also, it is very important not to allow technical resource decide what is populated into the CMDB, but the “business” end to make that decisions. Hence when you state you have seen CMDB's with 500k CI's just related to networks, a couple of bells start ringing.

Let me explain further on how I see the CMDB, a baseline is needed here to even discuss ROI. I think we have a very different view on this than some others here as they maintain that transactional data is part of the CMDB, while I struggle to see that.

The CMDB contains the baseline information of CI's, and the relationship between them. It is in fact a CI repository, nothing more and nothing less. Some might feel that something is missing:
state information: this is contained in your monitoring tools, why move that across in real time to your CMDB? Leave it there as it does not add anything to the CMDB.
service desk: all information regarding support, problems and issue tickets should be kept in the service desk tools, why would you want to merge that into the CMDB. You might want to merge some basic KPI information about the BI but no the complete history of the CI.
Release and change management information: once more, leave that in the workflow tools supporting your efforts.

Your CMDB should be the (master data) hub, and not the single data store (which actually only replicates data from one tool into another). I think this confuses a lot of people, for some reason the CMDB has morphed into this humongous store all repository. There is no need for this, your CMDB should federate and not replicate, a key distinction.

As for ROI, there are lots of white papers surrounding this subject so I will avoid redoing them here. But I do like the comparison that Charles made “what is the ROI for a General Ledger”, or one I used before, the ROI for a carpenter's hammer? Has the CMDB not become the heart of our IT governance, something that is impossible to achieve without?

Does it make sense to make sure your IT is aligned to your business … If it does then how can you achieve this without understanding what IT artifacts are used in relation to any business service?

Does it make sense to lessen the risk of change … If it does then how to do want to achieve this without an overview of what IT artifacts are effected by a change?

Does it make sense to look at the number FTE's in your IT department and make sure this is aligned to your needs … How can you achieve this without understand what your IT environment looks like and measuring relevant KPI's?

In fact, you can sub divide these questions in multiple more atomic questions. Here lies your ROI, if you want to achieve a next level of maturity (whatever that may be), then ask yourself what tools you need. I bet a CMDB like offering will pop up somewhere. It is not the CMDB that drives the ROI, it is resolving real IT-business issues that creates the requirement for a CMDB.

“Cannot be done”, that statement if nothing else is what has driven IT forward. As I said before, it can be done. Should it? The answer lies in “What are your strategies and how will you achieve them?” My bet is that you will need the CMDB beast to help out. The typical end-user did not want ERP, but it got implemented because that was the only way to reach the next maturity level and reach the strategic goals.

Now, you can keep on flailing around in a twisty maze of passages, all alike, but you have been handed a torch and a map. Your CMDB vendor is not the enemy, most are more than happy to work with you and help you create the best solution for your business. They won't? Kick them out and give me a ring :-)

Portfolio of lifecycles

Cary King — Mon, 04 Aug 2008 04:19:27 +0000

I spent nearly 15 years "doing" MRP/ERP before moving to IT Service and Asset Management ten years ago.

A CMS does not seem to be a big technical challenge. It does seem to be a management challenge. The persistent effort required to break down the silos that exist in IT and instill consistent execution excellence - instead of fire fighting - is, often, a bridge too far. Roger Bohn wrote a nice HBR article about this in 2000 I use to stimulate discussion. I cannot conceive of a reason, however, why an IT organization really committed to these changes wouldn't succeed.

Like any big set of processes, one must break down the overall set into constituent pieces. For instance, customer relationship management is separate from production and production planning which is separate from supply chain...etc. They are distinct lifecycles with distinct roles and responsibilities.

Charles' portfolio of lifecycles does that well. His lifecycle portfolios do, in fact, do a very credible job of matching to the different cycles used by the business.

ITIL does not seem to do as well. The thirty plus "processes" do not seem to clearly deliniate responsibilities. Perhaps that's because they're meant to be implemented wisely, using ITIL only as "good practice" guidelines instead of as some sort of "gospel."

Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com

I agree, "but"

buraddo — Mon, 04 Aug 2008 01:39:23 +0000

The sentiment of get it done is valid, but get done what needs to get done and not some synthetic utopia of a CMDB. I don't think I have seen many comments on this blog saying that CMDB's are not worth implementing. Just the ITIL definition is overly optimistic.

The definition of a CMDB as it stands today is akin to the definition of "a paperless office".. The initial promise of ERP's was complete automation with complete elimination of paper. Sure its possible, but who has the time, money and energy to do that. Most people have not been able to tick that of the KPI..

Brad Vaughan
http://blogs.sun.com/buraddo

What is the ROI on the General Ledger? Or the HRMS?

Charles T. Betz — Mon, 04 Aug 2008 00:19:00 +0000

Not to be too cavalier about ROI, but it's not the sole criterion for needing a CMDB. IT is a major consumer of capital in many enterprises and financial transparency continues to be an issue for IT organizations; shared services and virtualization are only compounding this.

And regulatory and legal issues are making it essential for publicly traded organizations to keep defensible records of their IT processing environments, just as they must keep defensible records of their employees and accounts.

Charles T. Betz
http://www.erp4it.com

CMDB isn't physically impossible, it is just a bad idea

skeptic — Sun, 03 Aug 2008 21:57:00 +0000

Ben, welcome and thankyou for your excellent contribution to the debate.

I don't think I disagree with anything you say :-D The question here is perspective.

Yes, ERP projects succeed. The fact is, a sufficient number of ERP projects fail to provide a steady stream of horror stories and to create the negative perception that they carry. And they fail for all the usual reasons.

The ones that succeed need enormous commitment and expense. There are those that question whether they all pay that back.

CMDB is like a small-scale ERP within IT - on that we agree. So if ERP succeeeds only some of the time and pays itself back even less often, how will we be successful with a project that cannot hope to command a fraction of the commitment and resource required for an ERP deployment. [BTW, there is one thing I disagree with: CMDBs are not "piddling". Years ago I saw a bank, small by international standards, with 500k+ objects in their systems and network management alone. CMDB can be more complex than the business ERP. And CMDBs are highly transactional, since "current status" is in scope.]

Yes CMDBs succeed. There are some success stories. Various apocryphal natter that passes for research in IT suggests about 10%-20% of IT sites have something at least vaguely resembling a CMDB and another third are trying to get one.

In the same way as there is The Argument from Personal Incredulity - of which the original post is indeed an example - there is The Argument from Personal Anecdote, which is how just about all the natural health therapies survive. "My nana's psoriasis cleared up after she rubbed mouse dung on it". "This car manufacturer is running their entire business on SAP". Interesting but not necessarily proving anything. I don't doubt that an organisation as good as ASG can get a company up on their ERP feet. You could get them up on their CMDB feet too.

But

is there a positive nett ROI when all costs are accounted for? (BMC's own research suggests to me it is at best borderline)
is it the best possible use of scarce IT resources?
what is the risk of failure? Do we even have the capabilities we need to do this?
is it the right thing for every IT shop on earth? (ITIL implies it is)

As I've said elsewhere, Bill Gates is probably rich enough to visit the moon now, but I'm happier that he spend the money ending malaria. CMDB isn't physically impossible, it is just (usually, in 80%-90% of cases) a bad idea.