What do all the sites without a CMDB do?

This post has been podcast

There are some fundamental fallacies behind the arguments for CMDB and a recent article encapsulated a number of them. Why do we keep getting told a CMDB is essential when almost nobody has one?

I read a good article today in the DITY Weekly Newsletter by Chris Matney of EMA. Those who have heard me have a go at EMA in the past may be surprised to hear that I agree with much of it, and less surprised to hear that there are some bits I take exception to. I believe there are some basic assumptions made in the article that are incorrect.

The first one is the first line of the article: "A CMDB is much like the tires and wheels of a car." No it isn't. EMA's own numbers, quoted in the article, show that less than 5% (I think way less) of IT sites have a CMDB, hence the second assumption I disagree with: "CMDB implementations are happily in the mainstream of IT operations".

95% of the cars on the road have no wheels or tires? I don't think so. 95% of cars have no GPS navigator, which is a far more valid analogy for a CMDB. A GPS navigator can be a very useful tool to high-intensity, mission critical drivers, such as emergency services or couriers. In the same way a CMDB shows benefit to the small percentage of sites that are so big or complex or critical that the tool is worthwhile.

For all these vendors and analysts who go on and on and on about how essential a CMDB is, I have one question: what the heck are 95% of sites doing without one? Functioning, that's what. So CMDB isn't essential like wheels. It is nice to have: a gadget like a GPS navigator that occasionally has a valid business reason for existence but mostly is there to appeal to the geek driving.

The third assumption is "the seemingly unstoppable tide of CMDB implementations" which is obvious analyst hype in the face of contrary evidence and needs no further comment, except to say (see, I can't resist) that these people need to get out more and stop talking only to the few sites who can afford to talk to analysts, and to build CMDBs.

I find it interesting to hear of

23% of respondents in EMA’s latest research report whose CMDB budgets are being redirected towards IT investments considered “new and more urgent” by management

A quarter of CMDB projects that actually made it up are admitting to analysts that their project is being judged a poor investmemt. I'm guessing the real number is much higher and expect that figure to grow as CMDB passes the peak of the hype wave (PLEASE SOON!).

EMA is now measuring an increasing rate of projects hitting a brick wall when it comes to justifying the ROI for CMDB efforts which are now going into a second year with price tags commonly exceeding $1M.

EMA need to share this with Forrester, who seem to think a CMDB costs $263k over three years, which would be an order of magnitude out on EMA's experience of $1M or more after year one. All depends what you are trying to prove I guess.

The original fallacy is repeated in "The CMDB is a foundational element to any IT organization’s efforts to improve efficiency, provide scalable services, and handle increasing complexity. " If this were true then the only organisations that improve would be those with a CMDB, and those with a CMDB would improve. Yet CMDB supports only a tiny proportion of sites and surely some of the others are miraculously improving without one? I don't doubt a CMDB is useful for improvement. I do doubt it is "foundation" and I strongly doubt it is the most cost effective means or the best use of funds.

In fact I put it to readers that basing improvements on a CMDB (which is how I interpret "foundation") is once again looking at the problem from the wrong end as geeks are wont to do: it is seeking a technology solution to a cultural problem. Improving people will improve process which will identify technology improvements, but it does not flow the other way.

Lastly, and a fundamental fallacy behind CMDB business cases, is "A simple human error ...caused an outage of the public internet for two hours when a patch was applied. Avoiding that single mistake would have paid for the entire CMDB project ". Oh right, and once you have a CMDB that human error will be eliminated? A CMDB will not introduce the potential for any alternate forms of human error and so all the costs of human errors can be included in the ROI for CMDB? Who is going to operate the CMDB? The tooth fairy?

"Did you like any of the article?" Well, lots of it actually. The line "Ask any of your peers who have successfully implemented the CMDB how they would track relationships between applications, services and the infrastructure without it" made me wonder whether CMDB maybe (just maybe) is not like a GPS navigator but more like a mobile phone. Once you have one you wonder how you ever survived without one. If this proves to be so, then CMDB is at the same stage as those concrete-blocks-on-a-strap phones that posers used to lug around on their shoulder and dump prominently on the bar where everyone could see it.

"ROI calculations are based on ...understanding how the CMDB is improving the efficiency, availability and performance of the IT processes that consume its data." Absolutely.

"don’t expect to see the 200% or 400% returns commonly quoted in the press today. Your hard ROI calculations are going to show less than a 25% return". Too bloody right mate.

"remember you are setting expectations with an ROI calculation – and eventually the piper must be paid" Wise words.


Who and how does a CMDB actually help?

Hi skep,

Having viewed the CMDB chatter for a few years, it still seems that the CMDB concept is one of the best drivers for vendor marketing campaigns of any form of repository of information about the technical or services infrastructure. I'm a vendor myself and I've dropped the term CMDB from most of our literature and the product name as I found myself explaining what a CMDB could be, might be, should be. So we don't cmdbs now - we do service mapping tools! Even more ironic, we link our service mapping tools to CMDBs! This could be called a federated CMDB - but that would be even more confusing so we provide "integration".

As a long term skeptic, but someone who has to make a living from delivering software and services in this space (mainly through passion) I thought a few words on justifying a CMDB approach from my own experience might be helpful. The problem is I that I have to define what I mean by a CMDB first. In my case I'll choose the mapping of services to components, as the asset side does'nt tend to do much for service management processes like change, incident and problems.

You don't need a CMDB for change/incident/problem management, but it does help. Without a CMDB I find the following happens;

a. Technical teams can't easily understand the potential risks of a change, it relies on personal energy and experience
b. Its difficult to identify the service owners for communication and involvement
c. Change submissions have many errors or omissions which require additional filtering / interpretation
d. New information comes to light during discussion of changes, which results in re-submissions or unnecessary risk
e. Incidents are initially allocated ok, but never closed off against defined CIs, so service reporting can't be automated and problem analysis becomes protracted
f. The usual confusion over naming because without a CMDB, it often difficult to ensure consistency of terms
g. Dashboard, monitoring tools etc. all use different interpretations of whats makes up a service so there is additional mis-communication.
h. Risk disciplines - security, business continuity, capacity have to duplicate data to try and get a "business" view for their own needs.
i. And the big issue - It takes a long time to get a change through the system, not the change form, but the whole project - request, requirements, planning, change, scheduling, reporting etc.

Many of the above aren't an issue for smaller organisations because there is less people issues and fewer silos. With additional skills (training, product knowledge etc) and good motivation then the need for a CMDB is less. In bigger organisations then there are probably outsourcers involved, teams are spread across multiple locations and so on, communication becomes more difficult and the systemic problems above start occurring. The ROI can't be identified because communication is the problem and that's a strategic issue. So without a CMDB, people have to work harder at communicating - not always a strong point of IT.

If management teams want to change the working practices and get better controls in place, they will have to bite the bullet and look to a CMDB as a foundation for improved communication across teams. But it does depend on what you mean by a CMDB....


most sites don't

Hi dave

I'm impressed by your approach of selling something clear and useful instead of a colourful bandwagon. And I think we are in agreement. To summarise your position in a few of my words: you need a CMDB (or somethign like it) if your site is sufficiently complex or advanced.

Which is the exact flipside of my position: most sites don't.

Syndicate content