Top 10 reasons NOT to implement CMDB

This article has been podcast

OK I'll bite. One of the nice folk at Evergreen, Jill Landers, posted "Top 10 reasons to implement a CMDB". I'll do the right thing and not quote it in full here so you need to go read that first. Then you can enjoy my "Top 10 reasons NOT to implement CMDB"

  1. You would improve overall release, change and configuration management if only you could bring all configuration items and transactions under centralized change and configuration management control... but you can't. I've discussed the CMDB boundary problem before: No matter how much you store in a central CMDB repository, there will always be some data somewhere else.
  2. You might automatically discover and map all key applications, computing and network IT infrastructure with sufficient technology and enough investment in its implementation and constant adjustment, but you won't autodiscover the most important information: the relationships of CIs to services and to people (ownership, key users, escalation paths...). That's manual.
  3. Having all the data in one place is nice to have, but the actual improvements in efficiency seldom outweigh the enormous investment to get there. Geeks love tidy data, but geeks don't have to pay for it. We've been chasing this "one ring" myth of unification since relational database, through directory, repository, corporate data model, middleware, Web Services... Give it up.
  4. Because the essential CMDB relationships (and much of the data) must still be maintained manually, CMDB is as error prone as any other source. After it gives the wrong analysis a few times people stop trusting the machine and go back to asking or at least checking with the guy(s) whose head was the CMDB before the expensive technology came along. CMDBs don't reduce risks, they just change them.
  5. CMDBs have nothing to do with enforcing compliance. Auto-discovery will detect a few instances of non-compliance such as unauthorised devices connected to the network but you don't need a CMDB for that, just the autodiscovery tool that comes with most systems management tools these days.
  6. Application Management is all about code. While Change Management may store its Releases and Changes in a CMDB, the code entities are managed in specialist Software Development LifeCycle tools. CMDB plays little part in coordination across The Wall, the divide between development/solutions and delivery/production/operations.
  7. Even Change does not need a CMDB. It needs its records of Changes so it can manage change, and report on MACs and other statistical information. It can do that in happy independence from any other system or process if you want to. Most sites do.
  8. The only part of CMDB it is hard to do without is the view of a Service. Somewhere you need to document this. So do it. Use a handy tool such as a Systems management visualiser, or a Service Catalogue tool, or Visio or anything really, and document the relationships between Service and its important CIs. The best place is in the Catalogue (see below). It's manual to find this out, so put process in place so that all Change workflow includes updating it. Get someone to own it. Do everything else the way you always did. There. You have CMDB now. Happy?
  9. It really is cool to be able to drill down on CIs via CMDB relationships to perform analysis. It is also cool to hold all your CAB meetings in a Lear jet.
  10. You can do without a CMDB. You can't do without a Service Catalogue. This documents what the Services are, the impact on them of changes and outages, who the key people are. Once Catalogue matures beyond a "brochure" catalogue to a technical view for use within IT, it often also documents what the key CIs are for each Service. Just because you don't have a CMDB doesn't mean you can't write the important stuff down somewhere. You must, in the Catalogue.

Evergreen usually write really good stuff but I think this post on Top 10 Reasons to Implement CMDB smacks of the "irrational exuberance" (read: vendor and analyst hype) that I spoke of before. It is not as disappointing as another Evergreen post "CMDB Myths Revealed" though, which is not so much gushing as plain wrong. But that's another blog for another day...


Troy DuMoulin said

Troy DuMoulin said

I continually see claims on the internet about the CMDB such as:
It would cost way too much money and we could never justify the business case
It would be far too difficult
It would be much to complex
It could never be in one single database (who said it should be)
We would never have the political ability to achieve it

I'm egotistical enough to think he is refering to me, among others but not many. Unlike Troy I'll give you a link so you can read both sides of the argument and draw your own conclusions.

All I'll say in addition to the original post is that "You Cannot Manage What You Do Not Understand" is such a fundamental assumtion behind lots of methodologies, and like all axioms it is open to challenge. I'll do an article on this some time soon. For now let me just say You Cannot Manage What You Do Not Understand? Try managing people. We achieve this all the time but things staff think or do often remain a mystery.

I don't think Troy has answered the fundamental challenge. He agrees that CMDB is difficult. He avoids the question of how often the significant investment in overcoming that difficulty is (a) cost justified and (b) the best use of scarce resources.

Stop thinking in just IT terms

You want a real CMDB, Real Knowledge Mgt, etc. Have the cahoonas to start with the real issue. Document strategy, capability, process, information and technology as a service and your IT relationships must come out because you actually start to measure how strategy drives projects, capabilities, processes, etc as KPI's. i.e. IT is a service to the business NOT a business in itself. GE has them, Boeing has them and here is a Police enterprise model including links down the applications.

enhancing my cahoonas

You haven't said anything to enhance my cahoonas.

I'm well aware of IT is a service to the business - you might like to read my book Basic Service Management if you doubt I have grasped the concept.
And I'm well aware of the importance of relationship information. My challenge is around how one manages the relationship data and in particular how much one invests/wastes on automating that management.

I don't doubt that GE, Boeing and the UK Police can cost justify a CMDB. I'm quite sure the complexity of their environment makes some automation essential. I'm sure GE and Boeing have the cash for one too. The UK Police less so. I've worked for NZ Police - I know the complexity of their environment and the paucity of their funding. Despite British imperialism I doubt your coppers are any better off proportionally. But no doubt they are big enough to find a few million in a drawer somewhere. I call such organisations the Five Percent Club. It is very impressive that you work with them but I don't think that has much relevance to the other 95% of us who

  • don't have enough money for a CMDB
  • even if we did have the dosh, the cost of a CMDB far exceeds our cost of the errors and delays in managing the relationship data manually in human repositories: there is no ROI
  • even if we can raise a decent business case for automating relationship tracking, there are more pressing demands on our limited funds
  • even if we are awash with money, we don't believe CMDB automation works well enough to solve the problem.

One day CMDB will be an affordable product that comes out-of-the-box, that doesn't require integration, reconciliation, and manual linking of logical concepts. [If you are a vendor who wants to claim you have that now, don't do it here - I'll be very very rude.] I look forward to that far-off day.

In the meantime, you 5-percenters and you poorly-supervised geeks who get to play with this stuff can continue to shovel money at the problem until you learn the answer. But please leave the rest of us - the huge silent majority rest of us - alone to manage relationships exactly the way we do now, and cut this macho my-CMDB-is-bigger-than-yours crap. Yes very impressive toy, now go away.

Ten reasons not to implement a CMDB

Skeptic, you are correct this article smells of a vendor who cannot get a CMDB together...


This is the kind of poorly considered marketing hype that is rapidly giving CMDB a bad name. There are a multitude of distinct systems required here, which for good reasons of cohesion and coupling should *not* be considered as a monolithic whole. Drift control as Skeptic correctly notes is intrinsic to the class of element being managed.

Skeptic, in your evolving concept of "Service Catalog," would you agree that minimally it should include Applications (as a subtype of Service) and their dependencies upon servers, databases, and each other?

Charles T. Betz

*Service* catalog? What is a service?

Charlie, Skeptic...

first we should agree on what is a service. I've seen at least 4 different definitions about what a service is. The most impressive and vague is that extracted from the ITIL V3 books, where a service is anything we provide to a customer and for what that customer does not assume risk and costs...

then we have a definition of service in ITIL V2, something like one or more IT Systems that enable a business process, then we have the CMMI-SVC definition, and lastly, I think that ISO 20k or BS15k have a service definition.

So, if we don't agree on what a service if, how can we agree on what a service catalog is? (for example, consultancy or training is not allowed in an ITIL V.2 definition-based service catalog, but it is fully allowed in a CMMI-SVC definition-based Service catalog)



There are far more than four definitions for Service. A google search, for example, easily turns up more than fifty. The problem is that most are, at best, Class-B definitions. They are easily understood and are somewhat useful in a general context. But while the layman may walk away with a general understanding of the topic, a serious practitioner attempting to apply the definition would have trouble doing so properly or with rigour. They risk undermining the process of derivative works and likely introduce downstream errors.

The v2 definitions (and most of the others in the IT industry) fall under this category. They are easy to digest but make for a flawed foundation when deriving a service catalogue, service portfolio or fully articulating value creation.

The v3 definition, while certainly a mouthful, is intended for serious practitioners, researchers, theorists and students of service management. It isn't a definition for the whole service sector (hairdressers, waiters, etc.), only those in a business and IT context. There does not exist, by the way, a pithy definition of Service for the whole service sector. There are good reasons for this, reasons which explain some of the problems of IT.

As a side note, I can't help but notice some of the difficulties with which SOA struggles can be attributed to Class-B definitions.

Application info is generally useful

Yes. I forget the terminology but V3 has adopted the concept of the two layer Catalogue: one to sell* to customers and one to guide IT staff. Application info is generally useful in a brochure so people can relate it to their own perspective of IT which is via the Apps. It is useful in a technical catalogue because Apps are almost always key CIs for a Service.

* though as I said in a recent article, Service Transition is much too light on the concept of selling

Syndicate content