The CMDB as a dead elephant, it cannot be done ... NOT

[The following post appeared as a comment on this blog on the original "dead elephant" article, but I like it so much I've moved it up to a posting: "work with your supplier like your business did 20 years ago when they were starting with ERP in getting the functionality you need into your CMDB of choice. In short, step out of that damned box, stop moaning like silly end users and get the job done!"]

It never ceases to surprises me as an IT veteran how little people change while the technology evolves around us. In part I agree with some of the statements made here, but a lot I just do not.

It was about 15 years ago when I was talking to the logistics director of a retail company in Europe about implementing the ERP system they bought. Their 6 warehouses he managed were going to be rolled out and upgraded into the system. He assured me it was impossible, and he used more or less the same arguments that are used here. They had over 100000 items (counting seasonal goods), high and low turnover, emergency orders, people already too busy (and dumb) etc etc. In short: could not be done.

Now we in IT are used to end users saying their business is unique, not like anything else, impossible to capture blah, blah, blah. We tend to learn to ignore most of the chatter because at the need of the day we are able to address almost all issues. Users lean towards the logical fallacy that is well known, The Argument from Personal Incredulity, ie I cannot explain or understand this, therefore it cannot be true, or in our cases, be done.

To cut a long story short, 2 years later the system was in, running these warehouses very efficiently, the system was ordering goods and they were saving money. O yeah, before I forget, the logistics director was replaced 6 months into the project.

Lets move it up a notch. How about a car manufacturing plant, multiple product lines, and the whole thing run in JIT logistics? For those not at home in this field, JIT stands for “just in time”, ie the car manufacturer does not have any stock, he receives daily the parts required to achieve what is planned to be produced for that day. Think about it, for example the car seat required for that day. The exact number of seats for all cars, in the correct color and upholstery option are delivered daily to the plant or even in multiple deliveries during the day. This seat is only one of maybe hundreds of thousands of items, with a production line that does NOT stop for almost anything. But yet, they manage to make it work.

Apparently we as IT have cracked some very tough nuts in the past. Through the use of a good architecture, good software and changes to the underlying business processes we are successful in supporting our IT customers.

After reading this article I could not help but think that I had taken a time machine back 20 years. A CMDB has a low number of items, low turnover and probably no transaction data attached to it .. when compared to the business we support daily. It then stuns me when people say: can't be done. My current role that has changed from 20 years managing on the business IT side to managing implementations in the IT arena, the likes of CMDB's and other tools. I am confronted daily with the arguments (fallacies) I stated previously, and I use the same examples I user here (and more) to break those doors down. Basic number comparisons tend to humble the IT department when they see what challenges the business end is faced with, and that we as IT have resolved!!

Hard to initially populate?

Once more, look at how businesses do this. In my example of the 6 warehouses they had to come in on a Sunday, count everything in one day, enter that data and have everything ready for the Monday morning business. Easy? Heck no, but doable and done hundreds of time across the globe where stock levels have to be accounted for in a new system. In IT, where large numbers of stock (configuration) items can be reached automatically, where item turnover is measured in years, where we have low numbers of items (compared to the business), no transactions and no business pressure to fit in one day (or week or month), and this is not a doable action?

Also, a typical ERP implementation needs to take on existing data, a data load of 1 million+ records from 30+ entities is not that untypical. In IT we have maybe 30k, from about 3 different entities. The effort is truly trivial. We were implementing a help desk and one of the “issues” the management raised was the difficulty of the data load, ie taking on and converting data from the existing system. We went to the business, got the numbers from a recent data load for the ERP implementation they had completed two years back. They were stunned and rather shame faced when we put those numbers up on a slide.

Hard to sync and keep up to date?

I have been asked this question by C-level types a number of times. I turn around and ask them what their (IT) supply chain looks like. The look I usually get back is once of amazement and confusion. It never dawned on them to not only document and stream line the supply chain of the business, but also their own!! Businesses manage to sync their supply chain, track every item they have to infinite detail ... and the IT department cannot? There is no fundamental difference: there is a need, a purchasing process, goods received, warehousing and life cycle management. No rocket science here, just basic process definition and alignment.

Before I go on ... yes, in this process there will be manual effort involved. For some reason IT always thinks that they can only reach maturity through automated process. Crap (if you forgive my English). If it is good enough for the business then it is good enough for us. The CI is created when ordered, not when installed, it is activated when it is received at the goods in department, not when it arrives at the desk to some technician, etc, etc. We need to stop thinking like silly techies and learn from the businesses (that use solutions we as IT provide and support, oh the irony here).

We also sell tools to support data warehouses. I have been to major international banks that run data warehouses feeding off of 15 different data marts (all with unique data sources), containing tera bytes of data. These are kept up to date daily, where data lineage, reconciliation, consolidation, data redundancy checking etc etc is all done to deliver a data warehouses that supplies data to comply with some of the most strict laws on the plant, ie reporting in the banking sector. For those not familiar in this area I suggest taking a glance at the BASEL II regulatory requirements. If banks do not comply they loose their credit ratings, and we all know what that means. They keep this all up to date using solid tools we in IT provide (ETL tools, meta data repositories etc etc ... the irony starts dripping off at this point)

Now, here we sit with our piddling little CMDB, carrying maybe 200k records, most likely no transactional data, just “is” data, with turnover measured in years ... and it we cannot keep this up to date? If we were a business we would not survive for more than a week, and to honest, I would be ashamed to even make a statement like that.

No standard model?

Show one standard ERP model, and this will make sense to me. Our IT model is infinitely simpler than what businesses have implemented thousands of times. I actually had to read that statement a number of times to grasp what was being said. Huh? I strongly suggest counting the number of entities and attributes in ORACLE's or SAP's ERP model. Then please explain why this DOES work and any model we can come up with cannot.
Does a CMDB make sense?

This is all so reminiscent of the discussion in the 1980's about ERP packages. Would they bring the benefit they projected? Were they mature enough? They we are all sooooo complicated to implement. We are now 20 years on, and you would struggle to find any business that does not have some type of ERP system implemented. Not because of the hype, but because of the solid business benefits they all have achieved, after going through the pain first of course ... and the help of some very innovative IT folks!!

Sorry about the rather long rant here, there are a lot more example of here that are sorely based on the logical fallacy I mentioned previously. My basic message to all you IT operational types out there: Do not be so parochial, step over to the business side and talk to them. Look at the issues that have faced them over the years and how the resolved them. Document what you feel is important to your CMDB implementation and then talk to the business for advice on how to proceed. If you have a logistics director or other person in the know ask him to present supply chain basics to you to understand how this works. Find a good business analyst to help you document what needs to be done. Find an architect (preferably one that helped with your data-warehouse initiatives) to help you define your infrastructure to keep your CMDB up to date and tip top. Finally, work with your supplier like your business did 20 years ago when they were starting with ERP in getting the functionality you need into your CMDB of choice. In short, step out of that damned box, stop moaning like silly end users and get the job done!


lost in translation

I like this example and I especially approve of the need for IT to be run like a business. I think that it misses a couple of important points, however:
- CMDB is the responsibility of IT operations, ERP etc are built by IT projects. IT ops seems to be mostly weak at understanding what it means to manage a business. IT ops also seems to have an even deeper fascination in technology (over processes and people) than your typically naive business manager.
- when the ESM vendors started building "CMDB"s, the term meant something closer to a CMS in ITILv3, ie the total repository of all information about CIs. This is about the same as the scope of "all state changes for each individual item of stock tracked by an ERP system." I've seen CMDB projects generate 1M CIs in the shared estate of only 1500 servers - this is the usual mess that you get with poor analysis. Managing this amount of data and the schema to represent it would blow any business case.

I don't think that there's a proven need for ERP in most businesses and as often as not it's just used as an excuse to break existing, broken, business processes. Nevertheless ERP vendors (or at least those who are literate in data management and business analysis) would be much better builders of ITIL/CMDB products, and SIs at implementing them and the supporting business processes and technology adoption, as there is a lot in common between these problem domains. At least they'd not allow the scope creep and runaway expectations of typical CMDB projects.

I agree, "but"

The sentiment of get it done is valid, but get done what needs to get done and not some synthetic utopia of a CMDB. I don't think I have seen many comments on this blog saying that CMDB's are not worth implementing. Just the ITIL definition is overly optimistic.

The definition of a CMDB as it stands today is akin to the definition of "a paperless office".. The initial promise of ERP's was complete automation with complete elimination of paper. Sure its possible, but who has the time, money and energy to do that. Most people have not been able to tick that of the KPI..

Brad Vaughan

CMDB isn't physically impossible, it is just a bad idea

Ben, welcome and thankyou for your excellent contribution to the debate.

I don't think I disagree with anything you say :-D The question here is perspective.

Yes, ERP projects succeed. The fact is, a sufficient number of ERP projects fail to provide a steady stream of horror stories and to create the negative perception that they carry. And they fail for all the usual reasons.

The ones that succeed need enormous commitment and expense. There are those that question whether they all pay that back.

CMDB is like a small-scale ERP within IT - on that we agree. So if ERP succeeeds only some of the time and pays itself back even less often, how will we be successful with a project that cannot hope to command a fraction of the commitment and resource required for an ERP deployment. [BTW, there is one thing I disagree with: CMDBs are not "piddling". Years ago I saw a bank, small by international standards, with 500k+ objects in their systems and network management alone. CMDB can be more complex than the business ERP. And CMDBs are highly transactional, since "current status" is in scope.]

Yes CMDBs succeed. There are some success stories. Various apocryphal natter that passes for research in IT suggests about 10%-20% of IT sites have something at least vaguely resembling a CMDB and another third are trying to get one.

In the same way as there is The Argument from Personal Incredulity - of which the original post is indeed an example - there is The Argument from Personal Anecdote, which is how just about all the natural health therapies survive. "My nana's psoriasis cleared up after she rubbed mouse dung on it". "This car manufacturer is running their entire business on SAP". Interesting but not necessarily proving anything. I don't doubt that an organisation as good as ASG can get a company up on their ERP feet. You could get them up on their CMDB feet too.


  • is there a positive nett ROI when all costs are accounted for? (BMC's own research suggests to me it is at best borderline)
  • is it the best possible use of scarce IT resources?
  • what is the risk of failure? Do we even have the capabilities we need to do this?
  • is it the right thing for every IT shop on earth? (ITIL implies it is)

As I've said elsewhere, Bill Gates is probably rich enough to visit the moon now, but I'm happier that he spend the money ending malaria. CMDB isn't physically impossible, it is just (usually, in 80%-90% of cases) a bad idea.

CMDB ... yes we can!! (to plagerize a phrase)

Hi “Skeptic” and others

Thanks for the welcome, hope to be back here more.

You have out-ed me I fear. Yes, I work for ASG, which is a CMDB vendor, and I am VP for Professional Services. I was trying not to make that too obvious as I was not writing this from a vendor perspective, but hopefully IT in general and inserting some experience we have in this area.

I posted a reply in the original thread as well yesterday, where I talk about how ROI and the chosen implementation method should be linked together, and that the CMDB is built up of discrete layers. Also, it is very important not to allow technical resource decide what is populated into the CMDB, but the “business” end to make that decisions. Hence when you state you have seen CMDB's with 500k CI's just related to networks, a couple of bells start ringing.

Let me explain further on how I see the CMDB, a baseline is needed here to even discuss ROI. I think we have a very different view on this than some others here as they maintain that transactional data is part of the CMDB, while I struggle to see that.

The CMDB contains the baseline information of CI's, and the relationship between them. It is in fact a CI repository, nothing more and nothing less. Some might feel that something is missing:
state information: this is contained in your monitoring tools, why move that across in real time to your CMDB? Leave it there as it does not add anything to the CMDB.
service desk: all information regarding support, problems and issue tickets should be kept in the service desk tools, why would you want to merge that into the CMDB. You might want to merge some basic KPI information about the BI but no the complete history of the CI.
Release and change management information: once more, leave that in the workflow tools supporting your efforts.

Your CMDB should be the (master data) hub, and not the single data store (which actually only replicates data from one tool into another). I think this confuses a lot of people, for some reason the CMDB has morphed into this humongous store all repository. There is no need for this, your CMDB should federate and not replicate, a key distinction.

As for ROI, there are lots of white papers surrounding this subject so I will avoid redoing them here. But I do like the comparison that Charles made “what is the ROI for a General Ledger”, or one I used before, the ROI for a carpenter's hammer? Has the CMDB not become the heart of our IT governance, something that is impossible to achieve without?

Does it make sense to make sure your IT is aligned to your business … If it does then how can you achieve this without understanding what IT artifacts are used in relation to any business service?

Does it make sense to lessen the risk of change … If it does then how to do want to achieve this without an overview of what IT artifacts are effected by a change?

Does it make sense to look at the number FTE's in your IT department and make sure this is aligned to your needs … How can you achieve this without understand what your IT environment looks like and measuring relevant KPI's?

In fact, you can sub divide these questions in multiple more atomic questions. Here lies your ROI, if you want to achieve a next level of maturity (whatever that may be), then ask yourself what tools you need. I bet a CMDB like offering will pop up somewhere. It is not the CMDB that drives the ROI, it is resolving real IT-business issues that creates the requirement for a CMDB.

“Cannot be done”, that statement if nothing else is what has driven IT forward. As I said before, it can be done. Should it? The answer lies in “What are your strategies and how will you achieve them?” My bet is that you will need the CMDB beast to help out. The typical end-user did not want ERP, but it got implemented because that was the only way to reach the next maturity level and reach the strategic goals.

Now, you can keep on flailing around in a twisty maze of passages, all alike, but you have been handed a torch and a map. Your CMDB vendor is not the enemy, most are more than happy to work with you and help you create the best solution for your business. They won't? Kick them out and give me a ring :-)

what I meant by "can't"

I'm fascinated by the way so many debates hinge on subtleties of definition.

Ben said "Your CMDB should be the (master data) hub, and not the single data store (which actually only replicates data from one tool into another). I think this confuses a lot of people, for some reason the CMDB has morphed into this humongous store all repository. There is no need for this, your CMDB should federate and not replicate, a key distinction."

This is in fact what ITIL says, at least in some places, or at least what the authors meant, but it is far from clear from the books and it sure as heck ain't what some vendors and many implementors have interpreted it to mean. The concept has indeed morphed out of control, as the industry terminologically debases it to mean what suits them.

What we mean by "CMDB" matters. So does what I meant by "can't". I meant it is not sensible, not practical. I'll keep bringing us back to those four questions I posted above.

Reasonable arguments, but, I

Reasonable arguments, but, I think, destined to not go far. As long as the argument for a CMDB/CMS reads like a manifesto for operational excellence, this skepticism won't be resolved.

I have seen large-scale CMDBs successfully implemented (and multiple SKMSs, for that matter. Really, Skep). But here is the catch: they were done by business units, not IT. They each required significant investments and long-duration efforts. McKinsey has a nice ROI on SKMS – though they call it something else. In fact, it was so nice, the business unit of a firm invested almost $20MM in the effort, including the provision of a 30-million-item CMDB/CMS. The system is operational and, thus far, fulfilling expectations (generating revenues). (Before they naysayers start howling, I cannot provide proof or names. All the work is under heavy NDA. Sorry. These firms prefer if competitors remain oblivious.)

IT had zero involvement in these initiatives. Worse, if I look at those firms, the same constructs do not exist on the IT side. Why? Because they ignore technology’s potential to affect business outcomes, the goal to make IT a differentiating factor; instead, they concentrate on rolling the IT machinery faster and cheaper. In other words, they don’t seek to support the business’ aspiration to leverage IT as a differentiating factor.

What is the ROI on the General Ledger? Or the HRMS?

Not to be too cavalier about ROI, but it's not the sole criterion for needing a CMDB. IT is a major consumer of capital in many enterprises and financial transparency continues to be an issue for IT organizations; shared services and virtualization are only compounding this.

And regulatory and legal issues are making it essential for publicly traded organizations to keep defensible records of their IT processing environments, just as they must keep defensible records of their employees and accounts.

Charles T. Betz

ROI and the CMDB

There are holes with this argument. For any “major consumer of capital”, ROI becomes more important, not less.

While ROI can be qualitative and quantitative, ROI isn’t achieved by putting data into a system. It is achieved when business productivity is improved or additional value created. And the value should exceed other potential investments.

Even G/L and HRMS is subject to this standard. If they weren't, then the investments would be spent elsewhere. In the case of G/L, for example, ROI can be assessed through:
- Timely financial visibility to stakeholders and improved financial control
- View lines of business as profit centers
- Compare forecasts with budgets through variance analysis and reporting

Also, a positive ROI is seldom sufficient. A non-regulated investment should return, at a minimum, more than the cost of the capital required to fund the initiative, often 18% for many of the global Fortune 500. Can the CMDB meet this minimum threshold?

When the argument is IT has no choice (regulatory requirements) then the discussion moves to fulfilling the requirements in a cost-effective manner. Can the requirements be fulfilled by a sound asset management process and quality Bill-of-Materials, for instance? If so, then the regulatory argument for a CMDB is moot. I believe this is The Skeptics point.

Portfolio of lifecycles

I spent nearly 15 years "doing" MRP/ERP before moving to IT Service and Asset Management ten years ago.

A CMS does not seem to be a big technical challenge. It does seem to be a management challenge. The persistent effort required to break down the silos that exist in IT and instill consistent execution excellence - instead of fire fighting - is, often, a bridge too far. Roger Bohn wrote a nice HBR article about this in 2000 I use to stimulate discussion. I cannot conceive of a reason, however, why an IT organization really committed to these changes wouldn't succeed.

Like any big set of processes, one must break down the overall set into constituent pieces. For instance, customer relationship management is separate from production and production planning which is separate from supply chain...etc. They are distinct lifecycles with distinct roles and responsibilities.

Charles' portfolio of lifecycles does that well. His lifecycle portfolios do, in fact, do a very credible job of matching to the different cycles used by the business.

ITIL does not seem to do as well. The thirty plus "processes" do not seem to clearly deliniate responsibilities. Perhaps that's because they're meant to be implemented wisely, using ITIL only as "good practice" guidelines instead of as some sort of "gospel."

Cary King
Minerva Enterprises
Managing Partner

Several times now you've

Several times now you've expressed your admiration for this multi-portfolio approach. Is there any evidence of its efficacy?

My readings of it show it to be another "design-build-operate" model of IT; what some describe as the Sisyphus-like struggle of rolling IT initiatives uphill only to have them come rolling back down as legacy systems in need of support. In other words, it provides a tactical means for IT survival but ignores the business' aspiration to use IT as more than a passive order-taker.

Is vs. ought

As the one who proposed the multi-portfolio approach that Cary and Skeptic have both favorably commented on, let me make clear that I propose it as an explanatory model, not a recommendation. It has originated from my own (also NDA) experience, as I reflect on the dynamics and interactions characterizing my day to day activities in the midst of a $3bn IT spend.

I have no idea whether it is the way things ought to be, and certainly no evidence. But I think that accurately understanding the reality of how things are, is a first step towards changing them. At this point it is merely a hypothetical model. My next priority, in my copious spare time, is devising some falsifiable tests to determine whether this model has superior utility, as compared to ITIL's overly numerous processes-cum-functions. One basic granularity principle in process analysis is "fewer=better" and any time processes start numbering more than a handful, we probably have opportunities for aggregation and synthesis.

Who has invoked the Sisyphus analogy? And what has been proposed as an alternative to the "design-build-operate" paradigm? Little to be found in ITIL v3 I fear, with its lifecycle model essentially framed around same.

And suggesting that CMDBs only succeed if owned by business units is interesting; I have worked in multiple organizations where that would simply mean no CMDB.

Charles T. Betz

The suggestion was not that

The suggestion was not that only business units can succeed with a CMDB. IT should have been involved. Moreover, they should have led the way.

The point was about business impact. ERP, JIT, SKMS, and the like, get traction in business units because the thread is woven between investment and business outcomes. When the argument for a CMDB leads with these effects, then many of the objections on this blog become irrelevant. When IT abandons this premise, ignoring it in favor of “few IT initiatives are truly strategic”, it steps into well known management trap generically described as a vicious cycle.

Every service provider is subject to competitive forces. It may not be for market share or revenues. It may compete simply for the goodwill of its stakeholders or for scarce budget dollars. If the provider doesn’t grasp this, if it doesn’t make explicit that internal initiatives aimed at improving operations are based on its direct effects on the day-to-day realities of its business’ life, then it won’t prosper for long.

When customer needs are predictable and well-defined, a service provider can afford to be a passive order taker. But this is seldom the case. Customers have to deal with their own competitive forces, financial problems, directives to please shareholders, or the need to improve their own internal efficiencies. IT has managers also. And it doesn’t take long for an IT organization to be put on its heels as it realizes it is capable of efficiently churning out robust systems but for the wrong services. [To mangle another Drucker quote.]


Also, it is a misreading to say that the lifecycle portfolios reduce down to a simple design-build-operate model. The whole point is that they have independent logics which interact in non-deterministic ways.

Charles T. Betz


Is there some way that we could arrange an on-line symposium/masterclass to cover both Charles's and Ian Clayton's ideas?


Peter Drucker wrote that, "The productivity of work is not the responsibility of the worker but of the manager."

Whether IT is more than a passive order-taker is entirely up to IT - based upon the capability of the IT business relationship managers and the IT service management product teams.

Few IT initiatives are truly strategic - in the sense that they create a meaningful shift in a company's capability relative to competition. IT is a service provider.

Like any service provider IT can choose to get to really know their customers needs and anticipate those needs with service products that support their customer, or they can choose to wait passively until their customer tells them what services they need.

In a competitive marketplace, those service companies that are passive market followers must compete on low price. In the world of IT - that's simply an other word for outsourced.

The point of the portfolios is to provide a business-like structure that delineates roles within IT with a business perspective - to run IT like a business within a business.

To bring this back to CMDB - it seems to me that a CMS is a tool to provide information to IT decision makers so they can improve the consistency and quality of their execution.

My issue is that companies approach building a CMDB without first defining clear decision roles. And the result is muddled decision bottlenecks - and poor results.

Cary King
Minerva Enterprises
Managing Partner

Syndicate content