The value of CMDB seldom exceeds the cost of doing it
Let us summarise the skeptical arguments focused around the value of CMDB . [Updated to move some text up from comments]
When I say CMDB can't be done (the most heavily read page on this site), there are several aspects to this:
1) it is a hugely complex undertaking to design, build, populate and maintain - underestimate any one of those aspects at your peril. It is just too big and complex for many smaller organisations. Do it with humans.
2) even when it is technically achievable, it is at great cost to design, build, populate and maintain, almost always a cost that exceeds the value returned.
3) even in the rare instances where value exceeds costs, could we have achieved the same value for much less cost by improving configuration process and basic tools within a dedicated and trained configuration data team of people?
4) and in the now tiny number of cases where THAT still came out for CMDB, was that the best use of that probably seven-figure sum of money? There was no more pressing project that could have used these limited funds? or perhaps in the small number of organisations that have CMDBs, funds are not limited?
If we break off all the benefits attributed to CMDB (or ITIL V3 CMS) that actually come from much simpler Asset Management and License Management and Network Discovery and Systems Management Console tools (etc), what is left? The ability to link a change or incident in a CI to the associated service(s) to determine the impact. Nothing else is unique to CMDB.
All that is left that is truly a benefit of CMDB/CMS and not of its pre-existing cheaper components is a mapping of relationships from CIs to services (and to business owners, SLAs...). How reliable is CMDB at reporting the relationships? Do we trust the output or do we check with humans anyway? And didn't we have to manually enter the links in the first place? So why not just do it with humans?
We must manually maintain the essential relationships to service. Don't believe the hype: tools can't do that automatically. And even if they could you would still need to check, because nothing is as ****ing dumb as a computer.
Where is the value of building and implementing a new tool, loading and integrating and needlessly redundantly duplicating all that data (don't believe the hype: federation doesn't exist yet and won't for a long time), and then auditing and protecting and updating it forever, just to report on relationships that have to be manually maintained anyway?
To get that sole benefit requires enormous cost. Some of the real costs of CMDB are:
- Initial population with the data that cannot be autodiscovered: what service does this support? to what SLAs? with what business units? where are the supplier contracts?
- Reconciliation: is asset A123 in the financial asset database the same thing as server Zulu in the NOC? and if not, who the hell is the business owner of Zulu? and the warranty supplier? How does the CMDB track that linkage? Who keeps it current with new assets? What effort is involved during the initial load? This task is HUGE
- What are the ongoing costs in hardware, batch processing, data maintenance? How to get the data out? How to respond to an impact analysis request?
- Data audit: has change been subverted? does the CMDB view of the world match reality? are the service configurations up to date (can't auto-discover-audit that stuff)?
- Integration points: who owns these entanglements with other systems? What testing is required if one of the underlying feeder systems is upgraded to a new version and changes its internal data model, API or export utility? or if the underlying tehcnology is replaced entirely? What is the cost of the additional delay and testing every time a connected operations technlogy wants to change?
Made in New Zealand 
Comments
CMDB ROI
Some interesting ideas on where the value is in CMDB came from today's panel discussion at the Pink Elephant conference in Las Vegas: consolidation of assets and eliminating redundant reporting. Clearly consolidation is a benefit of asset management not CMDB. I also wonder if the redundant reporting was in fact asset information rather than service-relationships. Charles?
redundant data capture
Definitely dependencies - assets often have OK processes even in smaller organizations.
See http://www.erp4it.com/erp4it/2005/12/dependency_mana.html.
Charles T. Betz
http://www.erp4it.com
common sense on CMDB
The answers over at the ITIL-Service discussion group on Yahoo are so consistently (and dangerously) ignorant and often stupid - in a word they are awful - that I regularly consider de-subscribing, but every now and then there is a pearl, such as this from Marcus Listas
Another example
>>>f) WHAT DO YOU NEED A CMDB FOR? A CMDB needs a service oriented culture that
99,99% of enterprises do not have.
This is another sensationalist example, condemning practitioners around the globe. This is pearl of wisdom? If you stop promulgating this kind of print, many could start taking you seriously and consider your methods as one of a thoughtful person instead of a loose cannon entertainer.
a loose cannon
Jim, those aren't my words, it is a quote. Yes it is an exaggeration. I took it as clearly a rhetorical figure of speech
I've never been called a loose cannon before - I need to go think about whether I mind. Cannons are destructive - I like to think I'm not.
The web is full of hundreds (maybe thousands) of thoughtful ITSM blogs. This blog has quite a following and I believe that is because it provides both entertainment and substantial thought. If my style annoys you, sorry. I'd rather you continued to engage me in serious debate but I won't be changing my style. It works for me. It rattles the cage, it stops us taking IT too seriously, and at the same time it stimulates useful re-think of some of the industry's comfortable assumptions.
What questions should a CMDB answer?
I believe in the principle of the CMDB. As someone who has personally designed automation system engines to multi-thread and manage system events, I know how important it is to have an infrastructure GPS capability. Many of today's event management systems have this in-built.
If you add other considerations such as Asset Management, Procurement, Inventory, Governance (we have to control access to stuff in a centralized or aggregated CMDB don't we?), and Purchasing systems, and the little known fact that Ethel's fax out there in the sales department may be a critical component of a business process - we have all the ingredients for turf wars and scope creep.
For years each technical silo has matured and managed what is effectively a State run mini 'CMDB' albeit through their own personalized lens.
Enter the CMDB concept. After more than 20 years of discussion in ITIL, and from what I can see a complete ignoring of the non-IT discussions on Configuration Management, we have a bunch of folks with a keen interest to position a solution before the requirement cart has been put in place.
I dread asking but... exactly what questions should a CMDB answer, and for whom?
Perhaps this way we can begin the process of building a supportable business case for federating the configuration information in support of a service culture.
Skep - what chance this question could be elevated to its own thread on your site?
improvement of configuration management
The CMDB should answer the question that arises from working on improvement of configuration management domain. if we work on people and process, the bottlenecks and inefficiencies and weaknesses of the configuration management processes will determine the requirements for supporting technology just as all processes should for all cool tools.
Some sites will need six million dollars worth of automated graphical trees, and some will need a box of file cards. Most will need something in between.
the costs and risks of the configuration domain and the other domains it serves will provide the business case.
CMDB needs Problem Management
Skep - as you can probably guess - today was a slow day so I thought I would chip in a comment anywhere across your site just to help fuel some debates.
In my view most organizations already have a CMDB, albeit fragmented, unrelated to the services being delivered, and owned by discrete teams within IT. I see Network CMDBs, Application CMDBs, and even Service Desk CMDBs, all in operational use under differing names and causes.
I'm sympathetic with ITIL's demand for a singular capability to determine what infrastructure elements are involved in providing a service. For some that could be an information querying engine that aggregates the results into a 'service view'. For others its one database that trawls and extracts any and all information sources for input.
ITIL is unclear in the destination and how we get there. Many read its 'guidance' as the need for a logical representation of the service infrastructure and its relationships. Without special tools, even with, its a daunting challenge that will consume a significant investment in resources unless the scope if carefully predetermined. So vendors suggesting and proving it can be done with ease, deserve to charge higher prices! Consultants claiming similar are likely associated with one or more vendor tools.
Anyway, such an investment will require PRIOR justification, especially if it involves software tools. Apart from the need for the organization's embracing of ITSM, governance rules for access rights to what could be very sensitive data, much of the justification is bound to operational issues.
It is problem management's responsibility to define problems and their impact. Problem Management is one of the first practices to implement and get right, providing every other improvement initiative, such as implementing a CMDB, with evidence of the impact of issues its absence causes, and justification for action.
In my humble opinion, a CMDB requires Problem Management...
No service configuration, no CMDB
I would have said CMDB serves multiple masters including incident, problem, change and SLM, but it doesn't depend on any of them except Change, to maintain and defend its data.
terminological pedantry: I don't think there is such a thing as "Network CMDBs, Application CMDBs, and even Service Desk CMDBs" - they are configuration data but they aren't CMDBs. the defining attribute of a CMDB is that it "determine what infrastructure elements are involved in providing a service", i.e. it relates to service. No service configuration, no CMDB. And I agree that is daunting. I also agree it is trivialised and oversold by the vendors.
As you said, CMDB requires justification, and that is where the crunch comes. I say in most IT shops it is cheaper and nearly as effective to do service impact analysis on demand by hand.
Imposter CMDBs....
Skep - I agree. What I termed a 'Network CMDB' was loose use of how they can sometimes be described and positioned from a Network Analyst perspective. The database(s) are in fact used to manage the network configuration, providing vital intelligence to event and alert management systems. The other examples have similar very personalized uses. All too often, in the absence of a succinct definition of a CMDB, the technical service communities can easily dismiss the need of a centralized capability by saying they already have what they need.
To the untrained eye, a Network Management ("CMDB") Database is where it belongs. The information it contains may be sensitive and copying elsewhere increase the security risk. I have long believed that a CMDB should be designed by an experienced database analyst (DBA) - not an ITIL certified person (unless of course they have designed major information systems). The design should be 'on paper' and driven by stakeholders that can explain what information they need and why, presumably as it relates to their role in fulfilling a a service guarantee.
Another 'best practice' you will find in the USMBOK (@Page 390 - Zero-Cost Operation), a "CMDB" should be self-funding - with sponsors of data elements prepared to rent space in support of their need for the information...
And building a "CMDB" capability - by that I think we both agree we mean the ability to relate any infrastructure item to a service level objective, should be progressed on a case by case, even 'Vital Mission Activity (@USMBOK Page 82 Performance Management Framework Tier 4)' basis.
Don't get me started on the tire tracks the CMDB concept leaves on Service Asset Management...
Competence of practitioners and cost effectiveness of tools
I don't see anyone saying don't do CMDB/CMS or improve Configuration Management process at your concern. Instead, it is very apparent we're indicting the pratitioners' competence in making it all effective and efficient using prevalent vendor tools.
Unfortunately, no one here is just coming out and saying they support the principles but condemn the cost structures of leading tools, and the education, experience and capbility levels of most pratitioners. It comes through in-between the lines, but not tacitly.
What is glaringly being missed here is that second tier tools, in-house tools, top-tier talent, and pure doggedness is building successful real, honest CMS'es for low costs (including professional services! egads!) in sub-regional and mid-tier concerns, not just the hugest 2% of companies. And yes, using PEOPLE. I would agree that the full-program approach is not appropriate for small companies. But the same meta-data is required to run a business, call it whatever you want.
This article almost crosses the line from "prodding hard thought" to "reckless sensationalism" - devaluing the time I spend reading it, to be honest.
please refute my arguments
I'm confused. One minute you agree that it is about configuration mangement process and people, and tools are secondary. then you call it reckless ensationalism. please justify that statement. If I am wrong please refute my arguments, which you haven't done:
Had you wrote this article instead...
...it would not have come off as sensationalism. You want me to refute your arguments, but I never set out to do so, read again. I think you are twisting words for readership omitting contrary case studies for fun and profit and damaging the value of IT journalism in the process, though. Why do I think so? Because my experiences tend, much more often than not, to be contrary to your world views and writings, especially on the topic of CMDB. While I am convinced you have a certain common sense that works for folks, I am equally convinced you have not experienced enough ITSM project time in enough environs to ascribe sensational and authoritative terms to your unconventional opinions. The original article has sensationalist niche appeal. Your bullet-ized reply here has value. The words do matter.
The true Skeptic
Though I agree that very few companies see value from a CMDB I have seen it done well and shown great value, though to be honest the company in question designed and built it's entire IT offerings around the capabilities of it's CMDB almost from scratch, a rare example.
I would be interested in hearing your thoughts on the more advanced discovery tools that are claiming to be able to detect complete transactions through the IT infrastructure, I have seen some impressive powerpoints but that's about it.
What I find also to be interesting is that most organisations do service definition and mapping as part of a CMDB "implementation", I have a feeling it's this effort that shows the most value and if they stopped there and took a deep breath they might not bother going down the road to full ITIL CMS Adoption. (at least for a while)
Regards,
www.Supportthought.com
runs well on Powerpoint
I didn't answer all your questions, supporthought
Auto discovery of transactions: yes I believe it runs well on Powerpoint and in controlled demos on vendor machines. As for producing useful info not exceeded by annoying and misleading errors in the real world for less cost than humans doing it, I'll believe it when I see it. Especially in a cloud :)
Even without a cloud, how do you separate out services sharing a common database, a common web server, common mail server, common code....? When a software product provides transactions for three services how does analysis unravel them? When a service runs through EAI middleware, Web Services or the internet, how do you follow it?
Even if the vendors pull off this trick, a transaction is not a service, though it is getting closer. Manual assembly still required.
I think service mapping shows the ONLY value of CMDB. All other values ascribed to CMDB actually come from underlying contributing simpler cheaper technologies, especially asset management.
There are CMDBs in existence
There are CMDBs in existence. Both I and Gartner believe about 5% of Fortune 1000, which I suggest means about 2% of all IT shops.
That's not the point.
1) Does the value returned exceed the cost to
2) and even in the rare instances where it did, coudl we have achieved the same value for much less cost by improving configuration process and basic tools within a dedicated andtrained configuration data team of people?
3) and in the now tiny number of cases where THAT still came out for CMDB, was that the best use of that probably seven-figure sum of money? There was no more pressing project that could have used these limited funds? or perhaps in the small number of organisations that have CMDBs, funds are not limited?
Not only don't I believe this is true in any but a handful of cases, but I also don't believe anyone has ever done the PIR in real business value terms. Geeks decide they need a technology solution to a process and culture problem, or that they need everything to be perfect, and they spend their employer's money. That's how CMDB happens.
If stands stiff
While I agree with you about the true cost of a CM(S)DB, and I also agree that many are rolled out by geeks spending employers money....
I do think that you may underestimate the value of a CMDB that is FULLY utilized by a business that understands it's competitive advantage of using it.
Now when I say you underestimate, we are talking a few degrees here, you say there are probably none, I say there are a few out there. :)
The real factor that makes up this value is usually the kind of business being managed by "IT": if we are referring to email in a Chemical plant, the value is never going to materialize.
However if IT is the business and every hour or down time, or every 1st level engineer that can be on call instead of a second level engineer is money in the bank, we do start to see value.
Though the focus bordering on obsession required to make this a reality is rare, I have worked in some businesses that have made market inroads by being this (relatively) agile/cheap.
in complete opposition to what ITIL says
No argument there. i said "a handful of cases". Those who need to be at maturity level 4 or 5 of configuration management for good compelling business reasons may well need a CMDB. It is the final result of a long journey where 98% of sites will not need to go. That's what I'm saying.
that simple fact is in complete opposition to what the vendor and analyst industry is shrieking at the poor punter. it is also in complete opposition to what ITIL says.
Okay. But. Answer these on
Okay. But.
Answer these on behalf of someone 'doing ITIL' without 'Configuration Management'. Either one CMDB as v2 implied or a collection of data sources in a CMS according to the v3 clarification.
"How do we know we are doing Change Management when we can't be sure what will change and has changed?"
"How do we know what tin we have and how much it is costing us"
"Wait, where is all our tin?"
"Is all our stuff licensed?"
"What kit can we stop powering and storing?"
You get the idea...
ITIL doesn't really say you MUST have a CMDB but it says you need to be able to answer all these questions when you need to. None of those questions are really about CSI so my point is that you can't really be CMMI 2 without answering some of those so forget about 4 or 5.
My issue with the so-called CMDB tool vendors is that they try to sell on the basis that their product will do it all (when they aren't mistakenly calling it a Service Catalogue tool). With v3 ITIL essentially said that it's unrealistic to try and do it all in one database. All the stuff you already have in your IT systems (such as Active Directory or logfiles) form part of your CMS. As long as you recognise that, can get to it and leverage it then you are doing Configuration Management. But you should have some kind of system (manual procedure or some software tools) to connect them and build the relationships.
ITIL doesn't really say you MUST have a CMDB?
"ITIL doesn't really say you MUST have a CMDB "???
ST 4.3.4.3: "SACM requires the use of a supporting system known as the CMS"
Happily - and contradicting this - ST says eminently sensible things that are ignored by vendors and practitioners alike:
ST 4.3.4.1 "There are significant costs and resource implications to implementing SACM and therefore strategic decisions need to be made about the priorities to be addressed"
ST 7.3 says "For large and complex infrastructures, Configuration Management will operate more effectively when supported by a software tool that is capable of maintaining a CMS"
A system. Sure why not. I
A system. Sure why not.
I have a system where every morning I take a dump before showering. Fortunately I don't need a software tool for that. Thank GOD I don't need software for that. Or a consultant.
Having said that when you open up the statement it does actually make more sense:
ITIL v3 Service Transition book 4.3.4.3 Configuration Management System: "Service Asset and Configuration Management requires the use of a supporting system known as the Configuration Management System"
On the other hand it's also a waste of print because all it really says is:
Configuration Management System: [Service Asset and Configuration Management requires Configuration Management]
I've got nothing to say about those later two excerpts because they are, as you say, sensible and often ignored.
Nice system
I wonder if the focus on tools to do CMDB work (when for example we make people do most of the work in Change management) is because of the vendors selling hard, or the fact that Configuration management is considered very boring work.
We would really rather just have someone sell us something to take it all off our hands?
"oh you have a tool that can do all this tedious stuff for me? sweet, how much? (gasp)"
people get all in a tizzy
Who said anything about "without Configuration Management"? Configuration Management is essential. We are in 100% agreement. "you should have some kind of system (manual procedure or some software tools) to connect them and build the relationships". Absolutely. All I'm saying is it can be manual, with simpler tools, and I propose it can be on-demand. It usually is now. Why not try doing it better, with a professional, practiced team using documented tested optimised on-demand configuration reporting process? Why is it that people get all in a tizzy when i suggest this for configuration while it is precisely how we approach other ITIL processes?
I think we agree too. I just
I think we agree too. I just got distracted by the CMMI reply bit without remembering all the other stuff you said elsewhere on the thread.
CMDB costs
I think that you make good points when you are looking at using heavyweight CMDB's such ar [product deleted] that require a lot of expensive professional services to set up and configure. There are much cheaper solutions that also are better architected and so deliver huge cost savings on these 2 often overlooked areas.
The better solutions have been architected from the outset to be multi-domain and federated whilst easily integrating with other applications. This differs from the heavyweight contenders from the big multi-product vendors (BMC, CA, IBM etc. etc.) who have a solution that has been extended from one of the domains (service desk, network, bsm etc.) in an attempt to fit all domains.
Has anyone looked at some of the "best-of-breed" solutions from vendors who only sell CMDB enablement technology or Configuration Management systems.
I have seen a demo of [product deleted] and it looks pretty good but would be very interested to see what else out there claims to do the same as the big vendors, but quicker, better and at greatly reduced cost. Only then can CMDB implementations really expect to achieve an ROI in less than several years.
Alternatives to the big CMDB's
I have not seen [product deleted] - though the website seems to indicate that they know what they are doing.
I can add another to the list - [product deleted] - I saw this when I had a demo of [product deleted] and I thought it was just going to be a CMDB specific to Business Service Management but it seems to be a complete CMS too. On their website they state that it is available from $30k which seems very cheap.
It is packaged as an appliance and they lead with ease of use and pricepoint so might be a good option for you to look at.
desist from name-dropping products
Will readers please desist from name-dropping products. If you read any of the other posts on this blog you would know i consider it entirely inappropriate. If you get off on geek toys discuss them somewhere else - technology is the least of our worries.
1) Anyone who thinks they understand a technology based on a vendor demo is delusional
2) All CMDBs are overhyped unnecessary toys for the majority of IT installations
3) Thirty grand is only cheap if it is somebody elses's money. The real cost of the implementation and ongoing TCO will be hundreds of thousands of dollars. You should spend your employer's money as if it were your own
4) Configuration management is a domain (ITIL insists on calling it a process). It has culture and process problems. Technology doesn't fix them.
cmdb made sense until the product vendors changed the meaning
I still don't understand why the term CMDB moved from describing the set of data that describes CIs and their relationships, and CIs as being those things that you need to control to manage your IT operations, to a detailed and pointless single view of how everything in your IT estate happens to be set up now (I paraphrase as I don't have any of the books to hand).
Under the current use of the term, I don't think that there is much value in a CMDB, per se. Like any other piece of infrastructure (an asset shared by many to get economies of scale with the aim of reduced unit costs), it's unlikely to achieve much value until it's shared by users with differing intents.
As originally envisioned, I believe, based on some of the people who worked on the project, that the term was deliberately vague and analogous to the set of data that you use to run a business - and no one would envision trying to put a common schema or implementaiton around that.
It's such a shame that IT ops people just keep trying to use tools to make things work. I can build a CMDB to find out what I've got deployed and then use that info to do all sorts of stuff, but it's of no use in itself, and, usually it's not a good idea to encode what you first find as it's probably not what you thought you had and it needs fixing before you set up a system of record for it.
Skeptic's right, certainly for the products that I've seen. We did some work with a client who bought one of the big 'cmdb's and who wanted to use the standard schema. This generated 1M CIs from just the server end of a 1500 server estate. It would have cost more to maintain the data (let alone to build and maintain a more suitable schema), than it was costing to manage the servers to provide a near appropriate service level for the business.
It is possible to get value from a cmdb, even to use one to support ITIL processes, but just not what the product vendors call a cmdb. The simplification needed to bring the data volumes to a tractable level necessarily complicates Skeptic's points about identifying, reconciling, spotting the dependencies between and then tracking assets.
tools up the wazoo
"architected from the outset to be multi-domain and federated whilst easily integrating with other applications" oh crap. Federated using what API? To what standard?
Delivering what value? At what cost? the "huge cost savings" are in licensing which is almost trivial compared to the overall costs. the real costs of CMDB are:
Configuration is not a technology problem and even CMDB is not a technology problem so please don't ask about nifty tools as a solution to it. We've got tools up the wazoo thanks to the vendor/analyst hysteria over CMDB and as usual they aren't solving anything (except the mortgage payments for a few salesmen)
Incidentally Mike, if you made full disclosure instead of saying "I have seen a demo of [product deleted] and it looks pretty good " you'd tell us that you actually sell [product deleted] at SXC
CMDB
I am actually interested in what other best of breed solutions are out there.
At SXC we are always looking to find the best technologies. If I had wanted to generate business for SX Consultancy I would have mentiioned the company and given our website address. I tried not to do that, and to add something constructive based on my personal experience, and I have indeed seen it demo'd.
Your initial comments were rather broad brush and surely a one size does not fit all when you are talking about technologies that are vastly different to each other in architecture, design, use and also price and implementation speed.
I do not really see why it matters how the cmdb is federated at the moment (as there is no standard), and I tried to point oiut specifically that it is ease of use and speed of delivery that differs from one solution to the next.
I was actually hoping to find out from others what cmdb or cms's are in fact good at doing this for my own interest and education, though as a good cynic, I am sure that this would not have registered with you :)
Management of configuration, and modelling of change to configuration is a technology problem and can be solved (or at least helped) by the application of appropriate technology.
You ask some pertinent (if oft-raised) questions and most of them have answers of sorts, though my intention was of general interest in the different technologies that can be used to help to alleviate these issues, and not to publicise SXC.
[product deleted] does seem to have a number of uniques, but as you have probably not heard of it, why not ask them these questions directly and see what they say.
Regards
Mike Paterson
Interested in all new technologies in systems management, service level management,BSM, and infrastructure management for my own personal development!