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?