Living without CMDB

This article has been podcast

CMDB is positioned as the key underpinning foundation to ITIL:

Configuration Management provides the foundation for successful IT Service Management and underpins every other process. The fundamental deliverable is the Configuration Management Database (CMDB) [Ref 1]

This is wrong. It is a peripheral nice-to-have. In a previous blog we discussed how it is currently an infeasible nice-to-have. Let's talk about doing without it.

There is a boundary problem to CMDB: no matter how good your CMDB tool and processes, there will always be CIs that matter to your environment but are outside the reach of your CMDB: closed proprietary databases, service providers’ networks, itinerant devices that attach casually, paper documents… So if you are going to have to interface from your repository to another somewhere, what does it matter where? i.e. if you have three repositories, each holding 33%, how is that worse than three holding 90%, 5% and 5% respectively? So lighten up and learn to love mentally reconciling and integrating data from multiple sources.

But what shall we do with no single universal CMDB? What we always did, though ITIL asks us to do it better. Only people can really analyse impact. Only people can reconcile conflicting information. Only people can deduce how complex systems will respond to perturbation. No tool is going to have the smarts to do what ITIL asks of Configuration Management in the foreseeable future. The functions of Configuration Management that are defined or inferred in the process are people functions. Stop trying to automate them [sorry Frank]. ITIL is about improving process, not throwing technology at the problem.

Go on, prove me wrong. Prove a tool can do those functions as well as a person or better. Set up a complex environment of integration, reconciliation, synchronisation and whatnot to give a single virtual view over data from umpteen sources. Then measure the amount of work invested to buold and maintain that versus the work to manually do it ad-hoc as required. Then propose changing something in the Citrix load-balancing and check the impact analysis from the tool against the impact analysis from Ralph the sysprog. Use your new tool to drive automated notification and SLA impact reporting, then stand back at your next Priority 1 outage and see how much it gets right; who gets called, what turns red?

People are doing fine without CMDB now. Look at the statistics for implementation of ITIL processes: Configuration Management is always one of the lowest percentages. For example, Incident-Problem-Change works fine on top of a single asset database with basic “depends on” links from key services to essential objects. Whether Availability or Release or Continuity or Financial or other disciplines use the same repository isn’t actually that important.

We desperately need some solid research on ITIL. I would love to know what proportion of CMDB projects have shown a positive ROI. How many have caused a measurable change in the effectiveness of other processes? And even when something positive is measured, how much of that stems from the presence of a shiny new repository, and how much from people focusing on Configuration processes? I argue you could re-engineer your processes using astrology instead of ITIL and you would see a positive result. Any process benefits from some attention. But that is yet another blog…

It is nice to store those basic “depends on” links to show the key CIs that services depend on. My experience is that organisations can manually maintain these service mappings for about ten to fifty services. Yet most have two to ten times that many services. They all seem to end up pragmatically picking the top services to store the mappings in the database. What happens to the rest? They wing it; they work it out on the fly; like they always did. It works.

Neither relational database, datadictionary, repository, nor directory succeeded in unifying our environments. Nor will CMDB (nor Web Services nor SOA nor .NET nor …). I have spoken previously about how so many of us in process methodologies and operations delivery tend to be anal obsessives. Lighten up and stop trying to find one repository to rule them all. Let our data be untidy. Let go of that old “everything has to be complete and correct” mindset. Live without CMDB.

See also The key to living without CMDB is process maturity level

1 An Introductory Overview of ITIL, itSMF, 2004


Poor Skeptic

Hi Skeptic,

I'm sorry to disappoint but I'm going to have to agree with you on this topic, too. I agree that a CMDB is not something that is "necessary". I'm also going to agree with you that throwing technology at the problem is not going to solve it. As a matter of fact, I've found that most people that talk about CMDBs have never actually seen a real one. So, you're right! If IT has survived this long without one, then it's not really necessary to perform the job. However, it is necessary to perform the job faster and more efficiently... assuming it's done correctly! What a properly constructed CMDB gives you is "visibility" into your organization. Before we go any further, let's list the different synonyms for a CMDB...

1) Configuration Management Database (CMDB)
2) Knowledge Management System (KMS)
3) Geographic Information System (GIS)
4) Organizational Memory & Information System (OMIS)
5) Informatics Platform
6) IT Data Warehouse
7) Enterprise Information Management Platform (EIM)
8) Enterprise Resource Planning for IT (ERP for IT)

(I'm sure there are more but it's late and I'm drifting...)

As you can see from the list above, there are many different descriptions for this holy grail of IT, yet, if you break down the requirements for each one, you'll find that they're all common: 1) The ability to track entities; 2) The ability to track data within the entities; and 3) The ability to track relationships between them. You'll notice that many people talk about these things but few have ever seen working examples. What this means, to your point, is that you can live without them.

However, if you have a truly successful implementation of a CMDB (yes, they do exist) you will also get to the critical information you need "faster" and with a higher degree of confidence. This will "help" to improve the quality and efficiency of work performed. Going to one place to quickly know what you own, what it's tied to, who's involved, etc. is a great reason for a CMDB... if the price is right. Too many people don't know what they're getting themselves into when they start on a CMDB implementation project. The end result is usually something that was built to gratify their own sense of learning and is throw-away, after years of expensive investment.

So, I agree that throwing technology at the problem will not necessarilly make it go away. However, correctly placed technology can help reduce it. I want to throw "appropriate" technology at the problem to help improve visibility and quality, help facilitate automation, and to help reduce costs. Technology can be a good thing when used properly.


Frank Guerino
CEO & Founder
On-Demand ITIL

yes technology works in its place

People Process Technology. How many times do we hear that? (or ITIL sources add a fourth dimension: Partners. An Introductory Overview of ITIL, Colin Rudd, itSMF 2004. An even more complex model includes vision and strategy, steering, processes, people, technology, and culture. Planning to Implement Service Management, Vernon Lloyd, The Stationery Office, 2002)

The key is to start them in that order (People then Process then Technology) and keep them in balance. IT people too often start with the technology, occasionally start with the process, and seldom start with the people (culture, team, approval, support, enthusiasm...).

Exactly as you say Frank, technology works where it is a tool to assist people and support process, where it has been selected or designed to suit those processes and people, and where the people and process work with or without it. Technology makes people more efficient and processes more reliable (or is that vice versa?). It seldom makes something possible that was impossible without it, and I certainly don't think this is one of those cases.

So if the configuration and change and availability and release and other processes are good, and the people have enough resource to cope and the right mindset to care and be particular, then a CMDB tool will make them do it better. Agreed.

BUT... The Skeptic still challenges the business case. To do all that people and process stuff just to get a CMDB does not, I contend, return an ROI to warrant it. CMDB is a concept that appeals to process people who want everything neat and tidy and comprehensive and accurate. It does not compete financially with ad-hoc best-efforts analysis spiced with a bit of old-fashioned gut instinct.

The Savage Journey continues...PMDBs

Dear Mr. Skeptic,

I just had to start up this swirl was too much fun the first time! An excerpt from Fear & Loathing on the Road to ITSM Excellence...

[By far, most of the carnage I've witnessed has more to do with people than processes or technology, but in this case I simply must blather on about a recent Gartner research paper titled, Expect Performance Management Databases in the Future .

That's right, PMDBs. The CMDB, CDB, CMS, SKMS, Service Catalog, et al lay fertile ground for serious confusion and weird scenes inside the data center. If you talk to a real geek, you can get a killer dose of future shock.

So I thought, as a certifiable 'non-geek' I would rant on about what I've seen (and what I think I'm seeing), in the desperate hope of getting some validation as to what's really happening "out there".

ITIL Version 2 defined two principal data bases; the Capacity Data Base (CDB) in the Service Delivery book and the Configuration Management Data Base (CMDB) in the Service Support book. When I blogged on the IT Skeptic a couple years ago (see CMDB Kool-Aid can result in a Bad Trip... ) I was simply offering a view that there was more than one path to service excellence (and it didn't have to include an "ITIL-defined" CMDB.

As luck would have it, it seems that I just had my terminology wrong. I was really talking about a PMDB. Had I only known! In fact, it;s not just Gartner that leads me to see the light. Enterprise Management Associates also has published some papers describing a 'CMDB Evolution' as depicted below.]

See EMA's White Paper: HP’s Universal CMDB: A Balanced Approach to Unifying IT Operations, Service Desks, and Business Objectives

[Look, I'm not the geek here. I understand that the vision for truly integrated ITSM management environment will take time (and money).

However, while you're waiting for nirvana, you might want to get something done (and numb some of the pain) along the way. Look at your stakeholders and services, establish a simple Catalog matrix and begin Cross Silo base lines as you proceed with process improvement cycles.

It will help get everyone on the same page and avoid some of the most challenging issues associated with your ITIL initiatives; People.

Understanding the inter-relationships between silos that make up end-to-end business services does not require a 'CMDB'. Ok, maybe a 'CDB', PMDB' or 'Real-Time CMDB'...

but what the hell do I know? ]

All the Best.

John M. Worthington
MyServiceMonitor, LLC

IT data mart

BPM in the meaning of Business Performance Management has been around for a number of years. If that is what they are talking about with their PMDB, it is absolutely needed; Peter Brooks' work on IT metrics is the thought leadership here. (Full disclosure: I was reviewer for his second book.) No reason to be overly skeptical. Any major business endeavor, including large scale IT, needs analytics. Calling it a "PMDB" is typical Gartner market-making, one of the reasons I don't care for them. It's an IT data mart.

The problem is that most ITSM practitioners don't have the requisite understanding of business intelligence to even begin to implement an IT data mart. Once you've read Brooks for your requirements, go pay your dues with or

And for heaven's sake let's stop appending the two letters "DB" to IT enablement systems (CMDB, AMDB, CDB, PMDB... yechhh!). Databases are repositories, nothing more; they require use cases and business logic *using* their data before they are of any value whatsoever.

Down with DB-itis.

Re: the EMA "real time" versus "process centric" CMDBs, they are right on, and I have seen this in reality. You need complex dependency maps in BSM tools, and complex dependency maps in CMDBs supporting Problem/Change. They should be aligned, but I only know of one or two smaller vendors where the same data is used for both purposes. In products from the big CMDB & management tools vendors, you have to integrate across the two: Atrium to Patrol, Tivoli CCMDB to TBSM, ServiceCenter to Service Navigator...

Charles T. Betz

at least some of the big boys

Some fine skepticism here :-)

How about the Unicenter R11 unified database? [Disclosure: I worked for CA so I know about it]. Aren't at least some of the big boys reengineering the internals to share a common DB [oops I used the acronym, sorry]

Dependency management

For another perspective see

At least in my world, we are spending way too much money and staff bandwidth rediscovering the same core data, and this re-work is reaching crisis proportions.

Full disclosure: I work in a HEAVILY regulated industry and I think the drivers are somewhat different here than in other verticals. Another variable to consider.


yes and no

In some ways I agree, in others not. It is nuts not to automatically maintain dependency information where that can be automatically maintained - absolutely agree - and there are plenty of tools out there that will crawl a network and discover the network connections, interrogate SNMP and whatever that Windows interface is called and ask all about what a device is and what's on it, and they'll monitor said devices for status and performance. The good ones aren't cheap and the cheap ones aren't bad, so why wouldn't people do it? The ROI stacks up for sure.

I get stuck at the next step: storing all the "intelligent" stuff on top of that: the real dependencies and the logical views, consolidating up to service views correlated against SLA definitions. My experience is that mapping about a dozen services and their SLAs to the underlying stuff is about all one person can cope with. So it gets hard and expensive.

Sure there is a cost when no-one can find Fred. There is a similar cost when everyone acts on incorrect information because it came from a computer so it must be right. To err is human - to really cock things up you need a computer. Personally, I'd be checking with Fred anyway which kinda renders all that fancy-work redundant in my eyes...

Syndicate content