More discussion of CMDB: not the best use of funds

Lately I've been involved in a fair amount of debate and discussion over CMDB. The lucrative over-hyped CMDB-building industry has closed minds to the possibility that just perhaps this isn't the smartest thing to be concentrating efforts on. I thought I'd gather together here my recent statements as to why CMDB is seldom the best use of funds, i.e. why CMDB can't be done within reasonable business bounds.

We had a fabulous discussion of CMDB on a LinkedIn group (you need to be a member of ITSM (ITIL) Professionals group). I'm capturing my views here. If you want a balanced view of the conversation you need to go look at the thread.

I take an extreme position on CMDB in order to get the mesaage out to people that they don't have to have CMDB (as ITIL defines it), they can have a few bits of it. They do have to have good configuration management process but that is not the same thing and not to be confused with CMDB. OKOK I'm fanatical on CMDB :D Having been a guilty party on previous vendor hype waves (relational database, 4GLs, corporate data models, repository, directory, portal, Y2K...) I tend to go on crusades against the current ones.

Defining terms
ITIL very clearly (well OK fairly clearly) defines what a CMDB is. In ITIL V3 it is in section 7.3 of Service Transition (most of p195 for paper-based folks).

Confusion arises when "CMDB" is used colloquially to mean "data to support Configuration Management and/or other processes".

An asset database is not a CMDB.

A network topology is not a CMDB.

if you don't have all the CIs under change management, you don't have a CMDB.

If you don't have the relationships between physical CIs and services, between services and SLTs and hence SLAs, between SLAs and business owners, between services and contingency plans etc etc then you don't have a CMDB.

If you don't have the relationships all the way up to Service and SLT and SLA you don't have a CMDB.

You don't. You have an asset database. Let's not start slapping the term-du-jour onto everything. "CMDB" has to mean somethign distinct else lets not have the word. It means a database where you can walk the configuration to determine impact on Service. if you can't determine the impact on service in the context of agreed service levels, it is not a CMDB.

if you hold a CI in your hand with smoke coming out of it and that CI is not in the CMDB then you can't determine whether this is going to have an impact on a Service.

I don't believe that's negotiable. This industry has a long history of making words mean whatever it suits us to mean at the time (actually it is mostly the vendors making a term mean whatever they are SELLING at the time). The#1 benefit of ITIL is a common agreed clearly-defined language. A CMDB means what ITIL says it means else let's not have "CMDB" and lets not have ITIL either.

So whatever you want CMDB to mean I'm using it in the ITIL sense.

CMDB is aspirational, an idealised model
CMDB is an idealised model defined by ITIL. It is aspirational. In fact in V3 it's blue sky - it is theoretically a good idea but untried except in one or two sites. Show me one site (ok show me three) that have full blown V3 SKMS and CMS. Most sites will bankrupt themselves if they attempt 100%

But people try. They think that they must have a CMDB as I described it because that's what ITIL says, the analysts say and the vendors say. And they want one because it is cool and geeky and seems to be a technology solution to the process problems they are having.

Not a technology problem
ITIL is about process improvement. By talking about “on demand CMDB” I’m making the point that we could do the config mgmt process smarter without needing all that technology fix to what is basically a cultural problem: tech geeks don’t like to write down what they do.

Appropriate tools
I’m convinced integrating config mgmt data is the monolithic-vendors’ job (CA, BMC, HP, IBM). As close as we ever get to CMDB will be done by vendors. The whole idea of a standalone hand-integrated CMDB or - god forbid - an in-house developed CMDB is just nuts. If the change-incident-problem-asset data is all one, and the system-network-app-servicelevel data is all one, and folk can assemble a Service view quickly on demand, then the site is at a very high level of maturity right there.

The technologies are massively over-hyped. One commenter seriously suggested that autodiscovery tools were relevant to Service Portfolio Management!!! No really. Service Portfolio is at a more abstract level than Service Catalogue. While I haven't tried this (yet) I'm thinking that Project Portfolio Management tools or other financial tools (e.g. one commenter used QuickBooks) would be a more appropriate place to start than geeky CMDBs when looking at Portfolio tools. Autodiscovery such as Tideway is about getting some useful information for CMDB. Even at the Service Catalogue level you shouldn't be down in the weeds of auto-discovered tech stuff and at the Service Portfolio level it is just irrelevant. SPM is about business - the geeks aren't in it. Moreover SPM is all about relationships (people ones), politics, business value, and process. Tools are a very minor consideration.

And at the CMDB level, autodiscovery is inappropriate for keeping a CMDB current, unless your site has zero change or configuration management. Autodiscovery is solely for initial population and then for ongoing audit.

The need for CMDB
One commenter said:

CMDB's in Service Management implementations are like brakes on cars. Sure, you can head downhill without them, and you'll surely make some progress and maybe even delude yourself into thinking you're good enough to drive without them, but in every single instance eventually you're going to lose control, crash and hurt yourself. Bet on it. :)

By my estimate 2%-5% of sites have a CMDB. The other 98% are crashing? CMDB is not fundamental. It is more like a GPS navigator on a car. Essential for a small number of specialist drivers like couriers and emergency services. For the rest it is a dashboard ornament to make the geek happy, with no ROI. If you are a really advanced, complex shop I can see it. For the rest, there are more effective uses of the funds

CMDB is always a hot topic. One reason is because it is a technology - IT people love technology. Process discussions should preferably be technology-agnostic, and configuration is a process issue.

I'm all for Config mgmt and I'm all for Config data. I challenge the value of the attempt to integrate/federate it all, and the attempt to maintain the relationships betwen the physical and the conceptual CIs, in the quest to attain the holy grail of the holistic CMDB. Undoubtedly life would be better with a CMDB just as life would be better with a GPS navigator in the car and a Lear jet on the personal airstrip. I say it is not the best use of limited funds.

I believe almost all the ROI ascribed to CMDB is ROI of the discrete technology parts of CMDB: asset management, license management, network discovery... these are all management of the discrete CIs not their relationships (stretch that a bit for network discovery - consider the network as a group CI).

The only ROI that comes from a CMDB as distinct from one of its parts - i.e. the only value from integration/federation and service relationships - is the value of better impact analysis for incident and change. The cost of getting there, of getting past having distinct asset management etc, is huge and the cost of maintaining it is nearly as huge. Federation is not a development project - it is an ongoing develoment effort as feeder systems constantly come and go and change version.

This huge cost is almost never repaid by multi-million dollar benefits. Even if it IS in a small number of massively critical and complex sites, even if reduced change failure and reduced MTTR is going to give that kind of payback, I maintain that the huge investment involved would almost always be better spent giving greater ROI to more critical projects elsewhere, and the same ROI can be achieved by using better human processes and more flexible human knowledge to improve impact assessment instead of some uber-geek mega-tool

In the unlikely event that you are new to the CMDB discussion on this blog, you can dig deeper with this thread and/or in my book.

Syndicate content