ITIL's CMDB can't be done, no-how

This discussion of CMDB and its total impracticality has got legs. Let me reinforce two points please: (1) CMDB can't be done because of the data and regardless of the implementation and (2) I'm talking about CMDB as specified by the ITIL books, not any old database. It can't be done.

Frank Guerino was nice enough to quote the "CMDB can't be done" blog entry on the ITIL Community forum - I finally got back in after deleting all cookies, so it may have been a technical rather than political problem ;-)

He is absolutely correct and I want to stress the part about burning money on an irresponsible scale. If you convince your management to allow you to build your CMDB, you should consider whether or not you are doing it for your own personal gain versus for the good of the whole organization. The person that wrote this article has a very realistic view of CMDBs. He backs it up with a significant amount of very obvious and valuable experience and with a significant amount of supporting reference data and useful information. My advice is that you think long and hard about building your own CMDB. I believe you shouldn't do so. I'm betting that if you show all the information to your decision makers, they will be skeptical about doing so, too.

I feel that Frank slightly mis-represents me here. I didn't say CMDB can't be built. I said it can't be done. No-how. I don't care if you build it, use a spreadsheet, buy a Service Desk with one in it, buy Frank's CMDB tool, or post it all on Wikipedia for the world to see. The technology is - as in most ITIL issues - irrelevant.

CMDB can't be done because it is too complex to load or maintain the data, however it may be stored.

The IT Skeptic Looks at CMDB - cover Out now, a new book The IT Skeptic Looks at CMDB

Available as a digital download for $7.95 or as a traditional tree-eating book for $9.95+p&p. This book lays out the case against CMDB.

While we are here, let's address the points raised by Frank's correspondent from that same (long) forum topic in response to my blog.

CMDB needs not to include every single little thing (Every single little change or release), in fact nowhere in ITIL does it say so. CMDB is the most open tool of interpretation. It needs to capture only the information required capturing for an organization (I.e. to meet the business requirements). If Business need is only to capture information of one PC so be it, CMDB will only capture information for that one PC, if Business need is to capture information of all PCs and more so be it as well. CMDB can be everything and anything (In scale and in size) as required by the Business need as long as it is centralised (One stop shop) and ITIL methods are applied for controls and management.

We will talk about "sheep-dipping" soon. The author "finally got my Foundation Certificate" and I think is about to learn how a little knowledge is a dangerous thing [not that I can talk as I have no more than Foundation either - just a few battle-scars as well and a skeptical mind].

Well actually , Skip [let me call him/her "Skip": the author was from Sydney], if you read the book ITIL specifies that CMDB should hold "Every single little change or release". I quote from Service Support:

Configuration Management provides a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items (CIs) in existence. The goals of Configuration Management are to:
account for all the IT assets and configurations within the organisation and its services

"all the IT assets and configurations within the organisation". The word "all" is used a number of times throughout the Config chapter. The question of CMDB scope is what NOT to regard as a change or release.

Skip said: "It needs to capture only the information required capturing for an organization (I.e. to meet the business requirements)". Oh absolutely yes yes yes. "CMDB can be everything and anything (In scale and in size)" Well y-e-e-es maybe. In reality, even if you limit yourself to a few critical services, the underpinning web of CIs they depend on take you to most of the CIs in the business in a complex modern IT environment. Bear in mind, config management is a tactical process (service support) not a strategic one (service delivery). So the data needs to be sufficient to support day-to-day impact analysis and change control. And by the time a couple of key stakeholders wade in with their own agendas, everything is in the pot.

Stop me if I've told you this one: this guy was telling me how his CMDB was going to be successful because he focused on what mattered and left out all sorts of irrelevant stuff. Like what, I asked? Like desktop PCs. So there is no application code on the PCs?. Of course it turns out key app was client/server. OK so now PCs are in the pot. But we won't track peripherals like printers. Oh really, and what proportion of your helpdesk calls are for printers? OK printers are in but not keyboards or mice. Hmmm... but you are a government department: I bet you have to be sensitive about OSH [occupational safety and health] requirements [not to mention political correctness]. Got any disabled staff with special peripherals? By this time he's pale and sweaty and hurrying off...


The author of this article [that's the Skeptic] failed to address that most organizations already have CMDBs of some sort (In a disorganized manner). How often do we hear about 1001 spreadsheets? This is a CMDB (Of sorts). Difference between ITIL CMDB and existant CMDB (of sorts) is the control and methods of management applied.

Wrong. CMDB arguements so often turn into semantic games. It is a bit like the Bible. "When it says people should have their eye torn out, what it really means is..." "When it says wives are the property of their husbands, what it really means is...". The book (Service Support that is, not the Good Book) is quite explicit:

Detailed objectives for Configuration Management should include:... identifying, labelling and recording the names and versions of the CIs that make up the IT services, infrastructure and their relationships... reporting the current status and history of all items on the IT infrastructure... ensuring that all Changes to CIs are recorded as soon as practicable


it should be clear that Configuration Management is not synonymous with Asset Management, although the two disciplines are related... Asset Management systems maintain details on assets above a certain value, their business unit and their location. Configuration Management also maintains relationships between assets, which Asset Management usually does not.

Pretty clear, Skip. The stuff lying around your office isn't a primitive CMDB. You may be able to build what you are defining, but it isn't a CMDB.

Other stuff on CMDB:

Read all on CMDB from this blog


Skeptical of the sketpic!

Sorry, but The Skeptic has it wrong here...fundamentally wrong. I'm admittedly 1 day into this blog thing, so a little hesitant to jump in with both feet, but here goes!

First off, I do agree with the Skeptic's (and other) assertions that CMDB has been grossly oversold. And, I know that many (probably most) ill-advised CMDB adventures resulted in nothing more than wasted money and time.

However, the reasons for that shortfall have less to do with ITIL itself than they do with overweening vendor claims, a failure to take the process side of things seriously, a commensurate over-focus on technology, and poor understanding of ITIL (or just plain configuration management) in the first place.

The most basic message of ITIL as a Good Practice framework is: "Here are some things to strongly consider. They've worked elsewhere. Check them out first, think carefully, and then do what works best in your environment. Then, measure your results and re-cast your efforts."

Approaching ITIL as a sort of literal cookbook (as our fearless Skeptic seems eager to do) is both misguided and predictably bound to disappoint. Finding inconsistencies in ITIL is not only easy (trivial), but silly and, again, beside the point. The authorship of ITIL v3 literally stretches into the hundreds if not thousands of writers. The essence of a 'good practice' framework is not that it provides a logically coherent, consistent, and precise specification for configuration management or for anything else. Rather, ITIL's aim is to lay out a basic series of guiding parameters and considerations which can save real world IT shops vast amounts of time and effort in their work to improve their own specific practices. Basically, ITIL provides good shoulders to stand on. What you do once you're up there is up to you.

This message about ITIL's positioning is actually spelled out quite clearly in the guidance. In my experience working with many (many) technologists (I am one) around ITIL, we make the mistake of viewing ITIL in the same way that we'd view a block of code or a device configuration, e.g. it's either right or wrong. That approach to ITIL, unfortunately, plain wrong and, more to the point, just plain unproductive. Such an approach does certainly provide great grist for the blog-mill: 1500 pages of straw-man to take jabs at!

To the specifics around configuration management and the feasibility of creating a useful CMDB, I'll add the following:

First, completeness of data is a useless criterion for CMDB content. Usefulness of data is everything. This message also is quite clearly established in the OGC guidance, most importantly in the discussion of appropriate breadth and depth of CMDB data. More generally, the scope of any process (certainly including configuration management) needs to be chosen judiciously so as to make the process relevant, useful, and supportable in the specific environment it is intended to serve.

At a more hands-on level, decisions about how to productively scope the breadth and depth of CMDB data can be pretty easily gleaned from looking at incident logs, problem logs, and change logs. Stuff that matters and that breaks frequently should be placed under configuration management. Stuff that both matters and changes a lot may also be a good bet. Start small (tiny!) and drive your choices with very specific objectives. Increase the scope of your process as your resources, needs, and objectives give you good reason to do so.

Next, many failures with early efforts at configuration management stemmed in fact from failures of change management. Even if you scope configuration management appropriately, you'll lose if you don't have change management dialed in.

Lastly, the mischievous tool vendors I mentioned earlier are certainly culpable in some measure, but I'll only point out that their over-enthusiasm for tool solutions is more than matched by process-poor customer technologists all too eager to jump into configuration management buoyed by the faith that the tool will take care of the details. I've got plenty of time in the trenches with tools of all stripes. They all have massive potential to disappoint...or worse. Sadly, a majority of the organizations I work with still only begin to take process seriously after they've bought and installed the tool. Results are almost always predictably sub-optimal.

CMDBs do exist - sort of

Depends on what you mean by a working one....

As with many of the previous comments - if you use the ITIL definition then no, there is not such a beast.

In practice there are things called CMDBs implemented within service desks, which help to categorise incidents, changes, problems etc. I know because I see them and extract all the data out into my own toolsets. The reason why they are not working ones are various;

1. CMDB data is not looked at because no one understands it
2. CMDB data is inaccurate so no one has confidence in it and therefore doesn't use it
3. CMDB data is scoped (rightly) to be a partial representation - networks, some hardware, software not covered so some incidents are classified as "network related". So it can't really be a perfect CMDB.
4. Performance - extracting complex reports can slow down the service desk system, which is not welcome!
5. No verification process to bind manual and automated data discrepencies

These are a few real issues from people who have spent big sums implementing CMDBs covering 1000s of servers. It has still been worth it though as what choice do you have when managing change across multiple services and technologies - another set of meetings for every change, incident and problem?

As with other blogs on the skeptic site, some of the hype is dying down and the reality is setting in. If you want to manage and coordinate complex services as best possible, at some stage you will need to define the configuration items you want to control and find a place to store and use it to support multiple processes. In a small IT group its called "the technician", in a large group its called the knowledgebase (of which the CMDB is a part, not the whole). The natural place is the service desk, but not if you have multiple service desk systems or outsourcers involved.

The concept of the CMDB is good - as what is the alternative? The reality is that you need just enough to deliver benefits.


These are not unique to CMDB

Responding to Dave ("CMDBs do exist - sort of")

All of the problems you enumerate also occur in line of business facing systems, and yet are not considered evidence that those systems are infeasible. Instead, we have requirements engineering, process analysis, data architecture, usability engineering, data quality management, business intelligence, and a variety of other well understood practices.

Re: reporting, long established practice is to replicate the transactional database to a reporting instance (sometimes doing double duty as the BCP instance).

Re: reconciling automatically discovered data with manually entered, the CMDBs I am familiar with have workflow-driven reconciliation functionality here that they are continuing to improve.

Re: human comprehension, see usability engineering. Re: data inaccuracy, see data quality management and process improvement. Re: scope, see requirements engineering and the concepts of cohesion and coupling. Etc.

There are no mysteries here. Just a lack of management attention and investment, because IT (even as the biggest consumer of capital in many industries) is still a cost center and investing in improving its efficiency is viewed as "overhead on the overhead."

The barefoot cobbler's child still has no shoes. That's the real problem; not CMDB over-reaching.

And yes, CMDBs do exist.

Charles T. Betz

Alice in CMDB-land

Business facing systems also offer up evidence that they are worth the time and investment.

No denies that CMDBs exist. They seem to be breeding like rabbits. But no one can seem to produce evidence of their promises. Just-Enough-CMDB seems to be Just-Another-Rabbit-Hole. Where is the proof?


Well, people do deny that CMDB's exist, or at least that CMDBs as defined by ITIL exist or are even possible ... But if you concede that they exist but are now looking for evidence of their business value, there is good research by IDC, Evergreen and EMA.
A better focus is not "does a CMDB have value?" but "what must be done if a CMDB is to be valuable?". Consideration might then shift from "what kind of rat trap works best" to "how should my organization and processes be designed to make my chosen rat trap effective?". Of course I think my rat trap is best ... but if you are still debating the possibility of value it's too early to worry about technology.
And while you are questioning the business value of the CMDB, perhaps you can share what business or technolgy problems you are trying to solve,and what alternatives to a CMDB will be more effective?

a CMDB called Sue

I've addressed the alternative in my article: a CMDB called Fred, or in these PC times a CMDB called Sue. No technology can match the effectiveness of humans in any but the biggest and most complex sites, particularly in staying current with major changes in the business, and certainly not at the price, even when Sue has one or two understudies to insure against the proverbial bus.

Sue is supported by a raft of simpler tools such as auto-discovery of network, devices and inventory; asset/procurement database; and integrated service desk.

That's one tough CMDB

I can't stop laughing. Are you a Johnny Cash fan?

5 +/- 2

Yes, but the pesky thing about those evolved primates is their clinically proven inability on average to keep more than five plus or minus 2 bits of data active in main memory... and their long term storage is subject to all kinds of retrieval and integrity issues. The data replication required for understudy-based fault tolerance occurs over low bandwidth, fault-prone channels, so you cannot be assured that the stand-in will function correctly.

Charles T. Betz


If you are referring to George Miller's famous 1956 study, it's actually 7 (plus or minus 2) not 5.

“The Magical number seven, plus or minus 2: Some limits on our capacity for processing information.” Psychological Review, 1956, vol. 63:81-97.

It is the reason why (U.S.) phone numbers are 7-digits.

While a catchy factoid, this number is a gross oversimplification of the study (to Miller's great annoyance) and isn't intended as a measure of an individual's or organization's capacity for knowledge, absorption of knowledge or the application thereof.

the fallibility of "wetware".

Charles' point is good though, about the fallibility of "wetware". My response is that computers are equally fallible, just in different ways that are more irritating, spectacular or downright stupid.

before long, most CMDBs produce a silly result when asked what service is impacted by an outage. Either the automated relating of CIs makes the wrong inference, or that danged wetware lets you down and causes GIGO syndrome.

Humans may make mistakes but they are unlikely to tell you that payroll is part of the sales system just because they happen to share a web server. or at least they are no more likely...

For all their failings, they are quick to implement, portable, and self-healing. They require no additional power supply or cooling, and run on coffee which is widely available. Admittedly their hardware footprint is large and they are not rack mountable, but they interface to just about anything. No other available CMDB can accept input from whiteboard sketches, napkin doodles or conversations overheard in the kitchen. The data rate is very slow, but it is the same rate as the other wetware components that need the data.

CMDB is about people

...which is why, when presenting internally or to industry, I emphasize that the primary enterprise CMDB value propositions can be best expressed in human terms:

- are the right people on the change approval review call?
- are the right people on the incident conference bridge?

If the payroll people are called in, better that they find they aren't needed but were called, rather than finding they were needed but weren't called - a situation I see all too often. And - upon noting such errors - we can tweak the inference business rules; that's "special sauce" functionality the CMDB vendors are competing on.

7 +/- 2, my mistake.

Charles T. Betz

I have sufficient

I have sufficient proof for my purposes, and sufficient support... Sorry I can't share a case study with names and dollar figures with you; that's the nature of the business world.

Whenever you have a phenomenon "breeding like rabbits" there may be a business driver.

Charles T. Betz

Staying out of rabbit holes

There are many "breeding like rabbits" phenomenon I have been all-too-glad glad to avoid. My alarms go off when told the proof exists but can't be revealed for good reasons. Isn't that how the yanks got stuck in Baghdad?

I started off in favour of CMDBs. In light of the logic on this board, that illness seems to be passing. There seem to be more agendas than evidence. One topic is wrong for lacking "CACM-Class" evidence but CMDB gets a pass?

Two different issues

If CMDB lacks CACM-class evidence in 10 years then maybe I'll toss it out. It's a matter of time frames. But CMDB also is more tactical - IT as a major business function inarguably has data management needs, and the debate is really just around how you want to scope and frame them. So maybe it's not even an "interesting" problem at the CACM level.

(CACM = Communications of the ACM)

And if you wait for that level of evidence, you'll be a late, late adopter, having forgone all possible benefit in your quest for evidence-based risk avoidance.

I have no agenda. I own no stock in CMDB vendors, I don't sell product, I have a full time staff position, I get a couple dollars for each copy of my book I sell, and not even advertising pennies from my blog. I'm just trying to help my peers as best I can within the constraints I live in.

Charles T. Betz


Wait 10 more years for evidence? Hasn't the CMDB drum *already* been beating for 10 years? It just doesn't add up.

Good point.

Actually a good point. So why hasn't it been an "interesting" question to date for peer reviewed research? Visitor is correct that the concept has been extant for 10 years at least.

'Fraid I don't have a response, but my suspicion is that the question is probably becoming "interesting." Belated, true.

Charles T. Betz

Vendor hype, myth, ideal, or work in progress?

Disclaimer. I am an interested party as the Product Manager for a CMDB technology, and a repeat offender as the long-time product manager and previously development manager for significant enterprise repositories.
The CMDB (or perhaps better, the configuration management system) is an information management technology for a particular class of information. It supports applications that are dependent on configuration information. (The same, by the way, is broadly true of the enterprise metadata repository.) Anybody that has configuration-dependent applications has a configuration management system. Some are good and some are bad. Some are based on vendor products, some are based on spreadsheets, some are based on sheets of paper in a manila folder ... My objective in developing a CMDB technology is to produce a better information management technology. As I am now fairly ancient, I watched the emergence and evolution of DBMSs. They addressed -- for general business information -- many of the management problems that CMDB technology seeks to address for configuration information. To that extent, I argue the CMDB technology is good, or bad ... but has a contribution to make. But as a vendor I would not claim that it is -- or needs to be -- all embracing.
That still leaves open the question of whether the all-inclusive CMDB is desirable or achievable. Incidentally, I'm not sure that ITIL V3 mandates such a comprehensive CMS. It talks about the configuartion item as a "Component that needs to be managed to deliver an IT Service". By implication, not every component needs to be managed. SO perhaps this whole thread is based on a myth ...It's been interesting to see industry analysts like J.P. Garbani of Forrester advocate the "just enough" CMDB and Ronni Colville of Gartner Group argue that CMDB implementation will be a long journey. I think that makes sense. There is a point of diminishing returns. Where that point is will shift as dscovery and application mapping technologies change, and as the CMDB technology -- in general -- improves. It will also vary from organization to organization. But as long as there are IT and business services that depnd on accurate configuration information for their sustainability, the Configuration Management System exists a work in progress.

Hi Dave Nice measured

Hi Dave

Nice measured summation as usual, thanks. But i disdagree with one point. The concept of CMDB is bad: the super mega uber-store of everything (any other concept is not CMDB, it it terminological debasement). the concept of Configuration management as a process is good.

have a process, an activity, a function that tracks CIs and relationships for key CIs in essential services. Don't fixate on the thing: focus on the process. Good process can deal with bad tools. Good tools don't compensate for bad process. Don't get suckered by the vendor pitch of the CMDB as snake oil. Do configuration first, don't build CMDB. the tools will come later, as needed.

CMDB Design Seminar - for skeptics!

Thanks skeptic for your kind comments. I acknowledge your wisdom and indeed a CMDB is part of configuration management, and you don't even need a CMDB to do configuration management - but it helps.

Anyway, I thought for the skeptics in this blog that may like to know that the BCS-CMSG (British Computer Society - Configuration Management Specialist Group) have defined a couple of events which will produce some materials for public consumption. This trade group has tended to specialise in software CM where CMDBs don't exist and is well established.

Next week (11th October) there is a session on the impact of ITIL3 on configuration / knowledge management. The presenter is Shirley Lacy who is one of the ITIL3 authors. She also did alot of the work on V2 config mgmt and BS15000/ISO20000. There should be some materials on the BCS-CMSG web site a few days later.

On the 5th December there is a whole day workshop devoted to designing and implementing CMDB with various specialists involved. I've been volunteered to lead the design and implementation section - which I will ensure is practical and real world! Yet again, the normal format is to put the materials on the web site for public viewing.

If any of your readers in the UK want to attend, contact the BCS-CMSG through their web site and present any skeptical views to make sure that the presenters have to work a bit!


Wonderful! Ms. Shirley Lacy

Wonderful! Ms. Shirley Lacy is certainly a credible expert. I'll be in attendance.

Terminological debasement

Skeptic you seem determined to preserve the ITIL mistake of an overly monolithic system so that you can then beat up on it. I say that CMDB can be scoped as appropriate and done incrementally as needed. You say then that's "not CMDB." Which of our perspectives is more useful to the average practitioner?

I say that a more modest system *is* still a CMDB. Who gets to decide?

ITIL v2 also had an impossible scope for its concept of Change Management. Is Change Management therefore also impossible?

Charles T. Betz

We violently agree again:

We violently agree again: the ITIL concept is a mistake. Unfortunately vast chunks of the world march to the ITIL drum right now. You know I won't agree to redefine the term to suit ourselves - right now it is what ITIL says it is.

I have to go away and ponder your Change question. Did ITIL overstate Chnage? I've not felt they did to date. Do you want to elaborate?

Section 8.5.9

Section 8.5.9 of Service Support indicates that the Request for Change precedes software construction, backwards from how most shops I am familiar with do it. At that point, you're talking Demand Management, not Change Management. v2 generalized both into "Change Management" while seeing Demand Management only as a subset of Capacity Management.

I'm still skeptical of your skepticism. The ITIL guidance must be tailored. Who would attempt to do *all* of any of the process areas all at once? One does this kind of work iteratively and incrementally; it's a journey. Deciding on CI granularity and scope of inclusion is an implementation decision.

The concern I have with CMDB (and I have the same issue with how COBIT defines configuration management) is the potential for inclusion of far too detailed parameter management in the central system. I also don't care for the lack of attention to data architecture, but that is remediable.

I would note that the Opsware product however is substantially covering both element and enterprise configuration management, in the context of a provisioning system. It does both dependency and element parameter management (for a fixed number of platforms, not including midrange and mainframe), including auditing to baseline and identifying/restoring configuration drift. However, it is marketed as a provisioning system, not a CMDB.

Charles T. Betz

ITIL's CMDB Can't be done!

I dig this! Finally someone gets it! Just came off of a project implementing BMCs CMDB. When I looked over the ITIL docs, my immediate thoughts were "this is rediculous". \

For example, you would need to track the accuracy of each data element in a CI. This includes state changes. In effect, the CMDB needs to understand whats connected where and to what process. So, I have a biz app thats in a Web page and it uses a simple CGI to do a SQL Query lookup of a data element for the user. My connection to Oracle only occurs when the cgi is executed. However, because it changes the connectivity and functionality of my CI's I must track these in the CMDB!

Of course, the BMC guys thought I was crazy ... Apparently, they were told not to worry about that and to not implement the transitionary connection into the CI records. However, our OSS Architect thought it apropo to incorporate all of the TMF CI modelling functionality. In doing this, some ID 10 T thought it would be nice if we could od Correlation in this CMDB at the very top of the architecture.

To top it all off, one of the other Architects refused to be outdone and mandated that all events, configuration changes and the like were to go through TIBCO Hawk and SOA store and forward SOAP mechanisms to xfer ANY data!

I heard the crap about Federated... To BMC, it means that they have CMDB data internal to Remedy ARS and they have CMDB data. In effect, its Federated! Federated to me means that they have Metaindexed all of the data in its various forms.

I like the concept of a CMDB but does it have to be this Pig in a Poke crap? Somebody pass me some more Koolaid - I'm not seeing the colors like you CMDB Groupies are!!!!



A brief comment on CMDBs

I've been writing for 3 years on CMDBs & related issues at I don't agree with this post that CMDBs are absolutely impossible, but they are most certainly prone to "fools rushing in where angels fear to tread."

My fundamental issue with the whole CMDB discussion as kicked off by ITIL is that there does not appear to have been a data architect within 50 miles of wherever the Configuration Management section was authored. What's a data architect? They hang out at, belong to, and attend conferences hosted by

Some might respond that ITIL was just laying out requirements, and that involving a data architecture perspective would have been a premature jumping to solution. I beg to differ.

1) A good data architect starts with clarifying language, not building technical solutions. Identifying the universe of discourse is a critical part of requirements analysis. The ITIL universe of discourse, while moving the industry in the right direction in several respects, becomes rather incoherent around the topic of Configuration Item (among other challenges).

2) Stipulating a CMDB per se (as ITIL does) is an architectural statement of solution. If they had wanted to purely stick to requirements, that notorious picture of the CMDB database with the process boxes above it should never have been created. There was no need to specify a common datastore as part of a process analysis. That is technical design and best left to software engineers and architects.

More to follow, time permitting-


CMDB and Data Architecture

I work a pharmaceutical company in NJ who has been intimately involved with the HPs ServiceDesk implementation (SD) of ITIL. I can tell you I couldn't agree more with Mr. Betz. What I have seen with SD is that the data model violates somemany basic tenet's of modeling it is hard to describe in a brief passage. But lets leave with you with a few:

1. The primary key is not on the business asset. The primary key is on an internally generated number called an Object identiifer ( OID ). And it is easy to find many cases where more than one business asset is listed with different OIDs and worse different historical logs.
2. There is no declarative business rules in fact this is seen as some sort of acheivement because the vendor claims it provides flexibility.

There are dozens I could list in fact it seems that HP is starting to address many underlying integrity issues ( surprise ) and believe it or not many of there solutions are for problems they caused. This is foolish obviously.

The main point here is that without a precise definition of the domain space how in the hell do you model it. I am sorry, but it needs to be said. HPs ServiceDesk CMDB data model is pathetic. Additionally because of the enormous ratio of constraint ( especially foreign keys ) the database performance is not scalable.

One ring to unite them all

I agree that there are a lot of zealots out there preaching on the ultimate CMDB. I do fear is that while there are a lot of valuable parts to ITIL, the focus on the CMDB will distract IT planners from focusing on their customers for the next three years. These zealots will be outsourced or swapped for people who listen. It has always been thus; it will be thus in the future.

I am in violent agreement about the need for a data model here. We lack formal API's, Data model, and federation API's. We lack a reference model. When I think of these issues, it's clear that an open standard is needed here. So I wanted to ask you gentlemen, if we were to start that from scratch what existing standards and models should we begin with? I have my eye on LDAP as one of those. Please feel free to tell me the pluses and minuses.

You can respond to me on my blog: or rodrigo
at newscale dot com

CMDB standards and models

Hi Rodrigo

Depends what you mean by LDAP. LDAP is not a model - it is a protocol for exchanging information. So I suspect you mean Microsoft's Active Directory data model. Speaking personally, I'd say that Microsoft have a proven track record of bastardising standards to their own purposes, which means Windows-centric (of course) and anti-competitive (also of course).

Let's talk about protocols for a moment before we move on to models. LDAP is itself a bastardisation of a superior protocol, X500. Let's not debate the merits of those two here though: in either case they are directory protocols, good at what directories do, which is the exchange of reference information, e.g. and most commonly authentication. Directory protocols are not good at communicating update information in a federated model. That is to say they can distribute updates in a proprietary manner within one product (e.g. Novell), but as an open standard they suck. No two-phase-commit for starters. I think in this case both have been superseded by a more recently emergent protocol: XML. XML is more general in application (read and update), and more loosely coupled.

So, back to models. There is Mickeysoft's AD model, yes. There are any number of vendor models: one for every service desk product for starters. The pre-eminent open model is DMTF/CIM, but see also OASIS/DCML.
CIM is used by a number of groups agreeing standards on several protocols, including XML (WBEM) and directories (DMTF/DEN). DCML is XML based.

There is talk of a consortium of vendors looking specifically at CMDB. But so far it is only talk (try to find something other than a press release), and they have chosen to operate outside of any industry standards group. They say this is so they can work quickly. It also, conveniently, means they don’t need to publish anything to show progress. So don't hold your breath. I've seen the work involved in this stuff from the inside of a vendor. Even if they can agree on a model, the minimum work required by each vendor is to create a translator to accept and send XML framed in the standard model, and map that to their own internal proprietary model. There's a million bucks right there. Optimally, they need to rewrite their product to change the database and code to the new model. This is a top-to-bottom code rewrite. It costs millions (hundreds of millions for a big vendor with many inter-dependent products) and it throws them back to effectively a 1.0 release with all the stability issues and support costs.

I wouldn't be starting from scratch: these organisations are vendor based and have far more resources (and expertise) than any volunteer open group. The key to the success of such a model is that the model be adopted by enough vendors to ensure the other vendors get on board. The best way for that to happen is for the vendors to be involved in its development.

And as we have said before: where the hell are OGC and iTSMF while all this is going on?.


More insight into the CMDB Federation Consortium


I too, was very skeptical/courious about this initiative because all I saw was PR. That's why I took the initiative to dig internal to IBM and find out what's happening and share it with practitioners worldwide.

I'm taking the interview approach to a series of postings on "An Insider's Perspecitive" to the CMDB Federation Consortium. My first posting is available here

Take care - and keep it up! I'm interested in how you expand your focus throughout IT!



Thanks, Doug, for digging for more info for all of us.

Thanks, Doug, for digging for more info for all of us. Most interesting.

...and sorry for the hard time IBM's been getting around here :-D I know you guys can take it. Don't worry, the others will get theirs along the way :-D

From your interview: "...the publication of a draft specification. Our plan is to do this by the end of the year." That's a nice clear target - I wish them luck in herding the cats. At least the objective is federation not standardisation, i.e. I interpret the reference to "Federated Data Model, Authorization, Query, Subscription and Import/Export Exchange Formats" as "everyone can continue to have their own schemas so long as we work out how to glue them together".

As for expanding my focus (BTW if you expand your focus you lose it... a danger I'm aware of) my life is full of ITIL these days so that will still be a dominant topic going forward. It is just that I have seen a few other low hanging fruit that I can't resist a swipe at. Hints of these are in the "Look Out!" box on the right.


We are in violent agreement again

Too right! Where the heck was the data model? Why does every organisation re-invent such a basic thing? It's like saying every organisation needs a different general ledger data model. Crap. Cop-out.

The vendors are reputedly starting to do the heavy lifting here by trying to agree on a common standard data model, as discussed in a previous blog. At any rate, they are doing the hard yards now by creating their own proprietary models. As they work their way up from tools to process, OGC should be working their way down to meet them. We can only hope some of that work will be done in ITIL 3. It should have been done in ITIL 1.

My thoughts on this subject: use the common sense!!

Hello Mr. Skeptic:

I want to add my comments to this post and expand it as a comment to the previous post. I think your are right in the strict terms, and that you are doing a really good job in opening people's eyes in this and other areas.
Everytime I've been asked to help a company to implement or to start the design of ITIL processes, I've started (or tried to start) with some kind of training sessions where I explain my point of view. This is very important because if a company hires your services because you are supposed to be an expert and you are not going to be rigorous in your ideas it might lead you to problems.

The concepts behind these training sessions are quite simple:

1.- ITIL is NOT religion, books are NOT the bible, and even if it was, we CAN interpret "the word".
2.- ITIL are Best Practices: recommendations about how to implement a concept called IT Service Management. If those best practices don't fit your organization, please feel free to modify them!
3.- Books are written by human people: they can be wrong, they can have "not so good ideas", and of course, they don't know your bussiness
4.- Use the COMMON SENSE, please!

So having this in mind, everybody has shown to be developing a different definition of CMDB. You always focus the main use of the CMDB in impact analysis and change control, but people use to give it other uses, like contract and guarranty management, relationships between servicecalls and problems, reporting, etc.

So a well designed CMDB should give the IT organization what it needs if it fits the budget and the ROI as you said before.

But I agree with you that this is not the strict definition of CMDB done in the ITIL V2 books. So, if Mahoma doesn't go to the mountain, then the mountain will go to Mahoma (it is a literal translation of a Spanish ditto): the actual strict definition of CMDB can't be done? so let's change the definition and then CMDB will be done.


Ops! And I forget a last message for Skip:

It needs to capture only the information required capturing for an organization (I.e. to meet the business requirements). If Business need is only to capture information of one PC so be it, CMDB will only capture information for that one PC, if Business need is to capture information of all PCs and more so be it as well.

Business don't need a CMDB, IT does. It is an internal tool used by IT organization to try to keep things under control.

I'm just here to keep the zealots in line

Hi Antonio

As you know I'm just here to keep the zealots in line, so we agree 100%; build what makes common business sense, not the formal definition of CMDB.

Your philosophy works great for ITIL. It isn't going to work for ISO20000!!! As far as I understand it, ISO20000 is all adopt and no adapt, amigo. No latitude, no slack.

All adopt and no adapt

As far as I understand it, ISO20000 is all adopt and no adapt, amigo.

Ufff.... that's why I don't like ISO9000 ... no place for common sense.
I have to read a lot about ISO20000. I don't like to be restricted in a model. I like to feel free to make the best I can.


CMDB can't be done in a business context, with acceptable ROI

I have to stop saying "it can't be done" without a qualifier! It can't be done in a business context, i.e. with acceptable ROI. Anything CAN be done if you throw enough resource at it. Anywhere I make the absolute statement, please assume that qualifier.

Syndicate content