The madness mounts. When will the CMDB reality check come?

Dennis Deane, head of program management in Europe for Scottsdale, Ariz.-based delivery company DHL...
"In order to really implement a good CMDB, the team has to get granular with the information," Deane says. This translates into working with individual CIs and entering them manually into the database. "Every laptop and registration number has to get into the program somehow."

That means a team is dedicated to working on the CMDB -- entering data piece by piece and laying the foundation that the program will run on.


A dedicated team? How did they find ROI for that?


HP sauce

My guess is back when HP said they were helping out DHL with ITIL and before they had to go and buy Peregrine a deal got struck.

Now DHL probably has a nasty little addiciton to ITIL related invoices from DHL but that's anyone's guess ;-)

I think there's an article here that hints to insinuations above:,1895,1931147,00.asp?rsDis=OpenView_Throws_Its_Hat_into_the_CMDB_Ring-Page001-172192

No doubt the parent company will be noting the style of IT purchasing and wondering when it will ever end.

ROI is not the point

How does a Finance team find ROI on entering every transaction into the General Ledger?

We agree on much, but you are hopelessly off base in your CMDB bashing - and misusing the concept of ROI. ROI relates to a business's primary value chain activities, and is often inappropriate in considering supporting activities.

I can give you an alternate definition of ROI: Risk of Incarceration. Quite simply, there is a solidifying social expectation that IT shops will start to be businesslike in their handling of assets and associated risks.

I can also point to cost avoidance (which is not technically ROI); CMDBs are a classic "pay me now or pay me later" investment. Without them, the IT environment has to be continually re-surveyed. I asked an audience of 80 folks at the recent EAC conference if tactical re-collection of IT data had become an issue in their shops and about 50% raised their hands. I know one large organization where the application teams are in open revolt against any further centrally-driven data collection efforts, precisely because those efforts always start from scratch instead of starting with well-tended, centralized data, such a CMDB might offer.


I do over-do the ROI argument with respect to CMDB

You are right Charlie. I do over-do the ROI argument with respect to CMDB because it is infrastructure. Your finance system analogy is apt.

I do it because people still need to think about whether this is an appropriate or optimal use of funds. I better come up with a clearer way of driving that thinking.

I don't doubt that a nicely kept CMDB offers value and makes many things easier. I just dispute whether those benefits outweigh the effort to get them. Many people are today asking the same questions about SAP: it may be infrastructure and core systems, but the cost of implementing it has broken a few companies and set back many.

I also understand the risk argument but companies take risks every day: it is all about knowingly taking measured risks because the cost of minimising or eliminating the risk outweighs the benefits.

My particular area of interest is also my greatest area of concern for CMDB in particular and ITIL in general: smaller companies. The smaller they are the less they can afford a project that does not directly or indirectly improve the bottom line, and the more they have to take risks simply because they don't have the resources to address them.

So a huge telco can spend millions on ITIL, one million going on a CMDB, and nobody much cares what the return was so long as management thought it was a good idea, and the board can see one less thing to get SOX-slapped for. That doesn't make it any better a business decision - it just means they can absorb the bad ones.

But a company of 500 employees with 20 in IT cannot make the same cavalier decisions: the half-a-million of internal and external costs they blow over two years on ITIL better show up in the balance sheet or there won't be a balance sheet. And one of the biggest costs for the lowest benefits will be a CMDB.

I still maintain that the CMDB should reside in people's heads. I feel an article coming on.... Thanks for the muse :-D

For smaller organizations, maybe not

I agree that smaller organizations probably cannot justify a full CMDB, any more than they can justify robust enterprise architecture or metadata management. If you have 1-20 logical "systems" they can in fact reside in people's heads. I see the CMDB as something that only starts to make sense for IT budgets over $20 million or so. Maybe over $50m.

But past a certain level of scale, you spend more time re-surveying than you would just maintaining the data, and dependency blindness starts to really impact availability. This is not theory, it is direct experience working in shops with a combined total IT spend of $4.5bn+.


I defer to your experience

I defer to your experience Charlie. But what are your views on this?:

It seems to me that the bigger the organisation the harder it is to maintain this data due to a factorial problem with the inter-dependencies, i.e the complexity does not go up linearly. Hence as you say it can't solely be in people's heads any more. The few sites I have seen doing this at that scale ended up managing a crude database of the main dozen or so services and the key objects they depend on. They left out a lot of lesser services and they left out a lot of CIs. So I would maintain that what they were doing was not an as-defined-by-ITIL CMDB. Absolutely agree it is important to have operational databases, just don't agree they measure up to what ITIL specifies we should have in a CMDB.

And I suggest these tools are there to help the people who still have it in their heads :-) It is a mutual dependence: the tools are useless without the additional human knowledge, and the humans can't cope without the tools to manage the data and remind them. Anyone who hits the "Priority 1 alert" button and scrambles their boss and the customer stakeholders based on what an impact analysis tool says without double checking it with a human expert gets what they deserve.

Data maintenance, the Achilles' heel...

Data maintenance IS the weak point. But let's look systematically at this:

- Some data - lower in the stack - CAN be discovered (networks, attached devices, OSes on those devices, virtual servers on physical machines, and commodity software on those devices).

- Custom software CAN be discovered IF you build the fingerprints.

- The logical "application" and "service" concepts and their dependencies require some manual maintenance, which means you need a defined business process and assigned roles and responsibilities to manage.

What seems to have failed for you is having a central team maintain the logical dependencies. That never works. The application to database and application to server dependencies need to be owned by the application teams. They understand their dependencies. What is required, is getting senior executive buy-in to making each and every application support manager responsible for the accuracy of the CMDB data related to their business-facing service. This can be done by training them in about 6 major transactions:

- Add application
- Establish app/server dependency
- Add database
- Establish app/database dependency
- Establish app/app dependency
- Establish app/infrastructure SW (e.g. app servers, development tools) dependency

(The lower level CIs and dependencies are owned by the infrastructure team.)

What is the incentive for each app team to keep this data up to date?

- If you don't have your app/server dependency documented, the server may be rebooted or even re-provisioned without your notification
- If you don't have your app/database dependency documented, the database may be re-indexed or even shut down without your notification
- If you don't have your app/app dependency documented, the other app may be altered without your notification
- If you don't document your dependency on commodity IT products, they may be de-installed on a given server, or the license may not be renewed
- If there is a service outage, and inaccurate CMDB data is detected as part of it (to your last point) the "ding" hits the person who was responsible for keeping the CMDB data up to date. It shows up on their scorecard and their team's annual bonus goes down.

There's a ton of assumptions here. It assumes a mature hosting environment, a willingness to have a few public hangings, and rock solid executive support that the Change process notifications are ONLY based on CMDB dependencies. I got it in one of my companies from a senior VP who'd led IT at a telco...

Once you get the model running, it works. I know of at least 3 other large IT organizations that have INDEPENDENTLY discovered this. It is the ONLY model that works at scale that I have heard of. Centralized configuration teams charged with all data entry, DO NOT work.

Also see

Hope this helps.


can't fault your reasoning

It helps alright. Thankyou Charlie, can't fault your reasoning. I knew folks were doing it and you define nicely how that can be. See my recent article for why your best practice is unlikely to show up in the ITIL books any time soon.

However, your assessment that the result justifies the effort remains subjective, as does mine that it doesn't. Until someone does some real research we are both just whistling.

  • What is the real cost to the business if it isn't done? If it is?
  • How does a group who did ITIL without a good CMDB compare to a group that did CMDB too? and to a group that never looked at ITIL?
  • What is the probability that a CMDB project will get to a successful system?
  • What is the probability that a CMDB system will still be useful after n years?

The waste involved in the search for the CMDB

New to this site, so apologies - I like CMDBs cos I make 'em and they make me dosh.
I see lots of customers and run various seminars on this area so your questions caught my attention.

1. Why don't IT managers ask your questions before they let their technical teams loose. It would save a lot of time and money for everyone. The amount of people I talk who are "interested", but have no goals, objectives, direction or money. The point is that a structured knowledge base of your infrastructure is strategic and cuts across groups, outsourcers and processes. So why are so many CMDB projects started without a delivery date, milestones, or clear sponsorship? IT teams can deliver complex strategic projects for business users, but not for itself.

2. How much time is involved attending seminars, workshops, ITSMF conferences where the cost of the time and expense is not detailed. We commonly come across people who say they want to develop their own CMDB because they have no money to buy one and internal costs don't count - oh, and they don't want any help, apart from knowledge. One outfit had 5 developers for 3 years developing middleware to link their service desk to an asset system - at no cost, cos slaries don't count. I worked out 5 times 3 times 50K (all in cost) to end up with 750,000 uk pnds. Never mind the data capture and time spent with technical teams - probably 2Mil in total. They decided to drop it because a new outsource partner wouldn't participate in updates. At least it didn't "cost" them anything.

3. While I am probably scum to many true purist engineering professionals (being a vendor, a director and commercial), at least when I am faced with having to deliver something I haven't done before, I ask for help, cos its quicker, less risky and if the help is bad, you don't pay them. My experience over 20 years is that many IT types don't think like that. May be pay should be linked to successful delivery to create personal focus. Which is more likely to fail to deliver as a succesful project (time, money, quality) - a CMDB project, or a government software project? At least one has a business analysis phase, a specification, milestones and an owner.

4. As regards comparing CMDB implementations, I think in practice it is too difficult as you have differences in scope, accuracy, usage, maturity and of course honesty. How many IT managers, or in fact any managers be pleased to be audited and have all the gaps in their processes or data laid out for all to see. Many live within an imperfect world, still returning to work the following day, caught in the middle, with many still wanting to do the right thing. It does make you think how organisations get a kite mark like ISO20000, because who is expert enough to validate the "CMDB" as being fit for purpose. For example I know one organisation that has been certified, but they still don't know where their kit is and things go wrong in the data centre due to basic coordination problems.

5. Having some knowledge is this space, for what its worth, the ITIL CMDB can never be delivered. Its still worth however establishing what information should be owned, kept up to date and used for managing change - call it a CMDB (controlled, managed, delivered, base of knowledge) if you wish


No let's not call it a CMDB

Thankyou Dave for your input. Welcome.

No let's not call it a CMDB. ITIL already defined that, and as we agree it is a fool's quest. let's call the achievable database something else.

I've already had a go at you vendors redefining everything ;-)


Just reading your comments on ITIL and in particular the CMDB.

One thing people forget is that ITIL is only a framework for best practice and not a standard. You can pick and choose what you want to implement, rather like ordering a sandwich from Subway. The other thing many don't realise is that many of the disciplines contained with ITIL are practices that were quite common and implicitly understood in the centralised-IT mainframe-centric world of yesteryear. This is true of the CMDB. Somewhere along the way, when decentralisation happened (I think alongside the introduction of the PC into the workplace) those disciplines got thrown out the door.

As a service tool, a CMDB can be valuable but that can only be realised when the logical groupings of physical items are linked to services, supported by SLAs. Until that point, it is nothing more than a glorified asset management database with some relationships thrown in.

For the record, I have yet to see a CMDB as described in the ITIL books. The complexity of IT infrastructure makes it very difficult to map the relationships (after all that is what the CMDB is all about). The most I've seen it working is where the services are mapped to key infrastructure items like servers, databases and applications.

I have yet to see a CMDB as described in the ITIL books

After your paragraph about " practices that were quite common and implicitly understood in the centralised-IT mainframe-centric world of yesteryear. This is true of the CMDB" I was about to take you to task: I too started out in MVS and I don't remember ANY decent tools for mapping relationships and dependencies (though we did have production problem analysis tools that still leave the modern ones for dead).

But then you redeemed yourself with "I have yet to see a CMDB as described in the ITIL books" :-) We're on the same page. Welcome, cuz.


Excuse me but I am a little new to the CMDB debate. However, if we accept that (1) the CMDB is a superset of an asset management database and (2) the SOA community is philophising about the link to SOA registries. Where does it leave us when the majority of organisations still struggle with the maintenance of reliable asset management data. As for a centralised repository of information. All very well in theory but when you don't know what you don't know....ya de ya.


Syndicate content