Am I wrong about CMDB?

It may surprise you that someone as pig-headed as the IT Skeptic ever has doubts, but I do wonder if I am right about the impracticality of building a CMDB (let alone a SKMS). AFAIR, only one reader has said "this can be done and I've done it" and he works for mega-corporations. What about other readers? Drop me a note if you have a CMDB.

I'd like to know any or all of the following;

  • does it work?
  • what did it cost? was it worth it?
  • what does it cost to maintain?
  • what benefits are you seeing? who benefits (e.g service desk)?
  • how "pure" is it to the ITIL definition?
  • how many entities? are they all related to the dependent service(s)? how is that maintained - manually?

I don't want to know company names. All responses will be strictly confidential. Create a gmail account and mail me from there if you like.

So if I'm a grumpy old whiner and CMDB is a great idea, tell me.


Adopt and Adapt and the CMDB implementation

Hello Mr. Skep and all the audience:

I think that the main reasoning to say that "the CMDB can not be done" is the fact that the requirements proposed by ITIL about the CMDB are really difficult and poorly cost-efficient to obtain. Having the list of all the CIs after defined a coherent CMDB level can be done, having all the information "on line" and ready to assess the impact of a change is quite difficult to do, but having all the relations between CIs (keeping in mind that this is a simple algebra problem: A is related to B with an infinite number of relations if you are allowed to creatively invent the relations) is mathematically impossible.

So we get something like a demonstration that CMDB can not be done... but... what about "Ad@pt"? We use the idea behind the concept of a CMDB, adopt this core concept, adapt this to our possibilities and needs and we get that thing that everybody using ITSM processes has: something like an inventory with more or less detail, more or less online and more or less integrated and may be with some relations between those CIs.

But nobody will tell the Skep in this blog that they have a CMDB, because they strictly don't have one.But if we think in a more flexible way, we can say that "we have something similar to the conceptual CMDB, that helps us managing our services"


algebra problem...

I think the algebra in question is relational algebra, and I think it would show that relating CIs together is quite possible - a good data architecture is essential... we don't relate hard drives directly to business processes... Semantic Web would also work...

Charles T. Betz

Keeping a CMDB real

Hi Skep,

When doing implementations I try to get people to think along the lines of a supply chain. Basically, look at how Wal Mart and UPS track their inventories. Tracking a package around the world is done through relationships. Package X is now part of plane Y...Offloaded to truck, scan and now package X is part of trailer Z etc... Wal Mart built in mechanisms to control and track inventory throughout the supply chain. (Note I have not done work with either of these, but do know how to read a book)
A second thought, coming from a production background, we used to use the materials management portion of SAP to track the required resources to run the factory. The General Manager could tell at a glance what was needed to run the production lines. I have adapted that in a couple of clients to build a pseudo CMDB. Create IT as an entity in the SAP. Identify the components that are required and manage them. Build in update and trakcing activities. (you get the idea)

Using either of these approaches helps organizations create a referential database that adds value. Maybe not a full blown ITIL defined CMDB, but the clients got value from having the relative required data available to make informed decisions.

Last thought, a good DBA I worked with used to challenge everyone with some key questions...How will the data be used if we add it? How will you maintain it?
What level of detail do you need to make a decision?

Its not just Keep It Simple, its Make It Simple.

Seen one in the wild...


Have seen only one that I'd really consider a success "in the wild". Very well designed and useful. Integrated into the firms operational procedures, because they needed it. Too much stuff over too great a distance. It's a homegrown product, NOT an off-the-shelf. Extreme focus on practical benefits. Facilitates integration with other systems through a decent API... other systems including their change management system tie into it directly. Leverages discovery technologies very well. Fairly good reporting capability and very usable. It's definitely not "pure"; definitely delivers the intended results. Best example that I've seen. They have a 2.0 FTE assigned to the maintenance and enhancement of the system.


ROI on the investment?

Thanks Ken.

And ROI on the investment? best use of scarce funds? How does the project rate as a financial asset?

Not sure...

I don't have an explicit answer for your questions. I can say that they are making additional enhancements ongoing and I don't see it going away. It's that important to how they work. If I get some more time in front of them, I'll certainly pose a few questions to them.

Telecommunications companies and mobile operators

Although the CMDB pipedream is not realized, I do think that telecommunication companies and mobile operators hit it damn close. For them it is all about moola and uptime, which is what drives them. If a tower fails, they know, where it is, when it precisely happened, what went wrong, who will fix it, how it impacts their services and why they should minimize the downtime! What drives this? You can bet your life that they don't wait for customers to complain about disconnects, they are there proactively fixing them.
In this neck of the Kalahari a couple of mobile operators have a message broadcast feature per tower that discounts connections based on congestion. The less the congestion the greater the discount. Imagine any ITIL type service desk informing an incoming customer that since the current call volumes are low, their service request will be done at a 70% discount. I think the customers would go into shock!
How about building a list of visible characteristics that should be present in a company that has a well oiled CMDB, e.g. demand based billing on service requests, etc?

Fancy network and/or systems monitoring isn't CMDB

Fancy network and/or systems monitoring isn't CMDB.

Telcos have it easy because their service is a very low-level simple one. I had a real battle with a client who was ex-telco and couldn't see why service catalogue should be so difficult, but they were now in a complex high-level applications environment which is orders of magnitude more complex than the telco world. A telco service is not even one step removed from the network.

So i don't doubt that telcos come close. But I bet they still struggle with mapping physical objects to conceptual entities such as services. And I'd also take a longer-odds bet that many of them rely on auto-discovery instead of maintaining CIs via change control.

Simple services are the best?

I think you are not judging the Telcos fairly. Yes they have been able to make their services simple and that leads to their success, but because other organizations are clumsy and monolithic shouldn't reflect on them.
There was a time when Telcos were like today's complex IT shops, when manual operator's filled rooms the size of stadiums. They have innovated themselves out of that rut.

telcos are puppies

Telcos sell roads where other companies sell trucking logistics

telcos sell paper where other companies sell training materials

telcos sell pipes where other companies sell petroleum distillates

I've worked in both telco and non-telco. telcos deal with incredibly complex technology but at a service level they are puppies. [there's that puppy again]

Telcos make the Skep grumpy?

In this neck of the Kalahari we have a web site, where service complaints or complements are logged. The mobile operators are always in the good column while the telco monopoly is always in the bad column.
This site gives a real good impression of actual service issues and I often read it just to be able to say that I feel damn lucky that what happened to some of the complainers didn't happen to me! When I complained on this site about the delivery time on my new mobile which I had bought, the mobile operator service director phoned me, arranged for the phone to be dropped off the next day and reversed all the charges.

The original post was about CMDBs and then we moved service. Is there a correlation between CMDB maturity and service quality? (or do we care?)

BTW: I have my shirt!

The assumption that service quality correlates

Love the shirt! And the business between the P.O and some Kiwis - gotta watch those guys!

There is a correlation between CMDB maturity and service maturity. As I said once

if you are NASA or Boeing or TATA or EDS, ignore me. You want level 5 maturity and you'll need a CMDB to get there ... or rather you'll need to start working on a CMDB. I'm still not convinced you will ever get near the idealised model. I still think it is too hard and too expensive.

And man it is going to cost you trying....

But that is not the same thing as service quality. The assumption that service quality correlates with service maturity is unproven.

I think that it is more likely there is a correlation between service maturity and decreasing cost to maintain quality as complexity increases. That is, complex environments that require high quality probably need high maturity.

But whether simpler organisations or lower quality requirements will benefit from increased maturity, beyond some lowish breakpoint, is debatable. And that breakpoint is, I feel, below the need for a CMDB.

A story from ITSMF 2004

So, I presented at the 2004 ITSMF on metadata and IT service management. During that presentation I walked through a list of configuration items, asking for each one, "who has this in their CMDB":

Workstations/laptops (~80% hands up)
Servers (~60%)
Applications (~10%)
Databases (~5%)
Flat files
Batch jobs
ETL feeds
Message queues

My memory is a bit vague on the exact list & percentages, so caveat lector. But one thing I remember clearly: by the time I got to the last four, there was just one guy in the room with his hand up and a big grin on his face.

He was from Sprint.

Charles T. Betz

Dependancy mapping

If someone has successfully implemented a CMDB, I would love to see a screenshot of the dependancy mapping interface..

Brad Vaughan

Dependency mapping UI

It's very easy to get a dependency mapping interface wrong, especially if you are mapping dependencies across two large source/target sets, perhaps with ambiguous names. Most of the commercial products I've seen could use some usability engineering.

I like to give people multiple ways to find a source or target node, e.g. fast filter based on any fragment of the name, and hierarchical drilldown based on the service or org structure. Scrolling picklists of >500 just don't cut it - what works is a fast filter executed on every keystroke, e.g. with an XML island and XPath.

Supporting application/service aliases is also key.

I devote some pattern analysis to this problem in my book, page 336 "Scalable Dependency Entry" - apologies for the shameless plug.

Charles T. Betz

Dependency mapping UI in practice

Hi Charles and all,

We found that you need a combination of user interfaces to get across understanding of CIs. The main difficulty is that a heirarchy based service is not easily understood beyond one or two levels.

1. Simple query interface. Select a CI (component or service) and then select a target group or level and then run a query to bring back the results. Or in plain words - type in a server name, then select the impact on software, services, systems etc and return a result ( no matter how many levels). This enables anyone who is filling in a change form to fill in the "services impacted" box consistently.

2. Service Map generation. Select a CI (component or service) and then draw the relationships up to and out to as many levels as you want so you see why you got the answer in 1. We use Visio or netViz as the visualisation tool for convenience. This works well when you have more than 30-40 servers involved in a service, when you're getting a service owner to validate the relationships or when you want to understand multiple service impacts for migration ot transition planning.

3. List views - for hard copy and identifying service owners (need the CIs and some attributes)

The service mapping data in a service desk is difficult enough to get, but it often stays hidden and isn't understandable so people don't use it. I'm now have a side line delivering training specifically on mapping services to systems - its great that ITIL has confused everyone by mixing asset, release and technical issues with what you need to allocate incidents and changes consistently. The one thing I've learned is not to try and replicate technical architectures in a "cmdb", just focus on service relationships.


Syndicate content