The Five-Percent Club
The Five-Percent Club is that elite group of the (less than) 5% of organisations who actually succeed in justifying and implementing a CMDB, or the more modern and equally nutty CMS.
The IT Skeptic has guesstimated the successful implementation of CMDBs across large, medium and small enterprise as about 2-5%. Looking at only the larger sites I've charitably allowed the statistic of 5% although I suspect that a strict interpretation of "successful" "implement" and "CMDB/CMS" would result in a lower number.
I'm delighted to see EMA - the analyst firm that leads in CMDB hyperbole, and Service-Now - the leading SaaS service tool vendor - confirming this number in a recent mailout:
Less than ten percent of enterprise IT organizations effectively utilize the CMDB in support of their IT service management initiatives. After years of work, Progress Energy is one of the rare few.
"Rare few" indeed. Welcome Progress Energy to The Five-Percent Club. I sincerely hope that the cost and effort of design, development, integration and ongoing maintenance is sufficiently outweighed by real cost savings, risk reduction and quality improvements so as to withstand the scrutiny of your company's governors and auditors, and that there were no better uses of the money that were left begging. I'd hate to think that - like so many - you had pursued the CMDB as a technologist's wet dream, without consideration for optimising spending across the project portfolio.
To listen to the vendors and analysts and authors you'd think a CMDB was a given for everyone and any site without one is in some way deficient. This simply isn't the case. It is as much a techno-fantasy as a tool to automatically find root cause or automatically test applications - nice idea but the costs outweigh the benefits for all but the most complex environments. The industry has tried to pimp the concept of CMDB for a decade now and it's getting old, even with the most gullible of customers. Hence the new focus on service catalogue and auto-provisioning as the vendors give up and move to fresh pastures.
Plenty of configuration data exists already in all organisations, including quite a bit of explicit or implicit relationship-mapping i.e. configuration. What is needed is a process and a team to understand and use that data in a polished practiced way to answer real-time questions about service impact from incidents and changes. For the Five-Percent Club, that process gets so complex and demanding they need to automate all of it, i.e. build a CMDB/CMS. The rest of the world needs to let go of this geek-magic-dream and pay attention to improving behaviours (e.g. writing things down, being accountable for changes), optimising process (getting slick at working out the impact implications), and refining simpler tools (e.g. ad-hoc correlating of data across sources)
[Moving up some of my remarks from comments below:
yes, semantics again.
The definition I work by:
A CMDB or a CMS is not simply a collection of data sources. It presents a single view of the service, and especially of the impact on the service of changing or breaking any CI. The key is the storage and management of relationships. If CMS is not a specialist term for that kind of database, if CMS means "any collection of configuration data", why have the term at all? It ceases to have any value. Let's just call it configuration data.
By that definition of a CMS I don't think many are around. incidentally by that definition i believe there isn't a single benefit to CMS that isn't actually delivered by the simpler underlying technologies except service impact analysis.
As for the percentage penetration, beware of the bias i have talked about before. if you spend all your time in the USA and all your time speaking to large organisations and all your time being invited to orgs that are already predisposed to having a CMDB, of course you will get a biased view of the world. My view of the world is equally biased the other way, but my personal estimate is 2%. I allow 5% as a correction to my own bias.
Indeed CMS is the future, as we get better at automating it more cheaply. That doesn't change the fact that right now it is a bad business decision for the vast majority of IT shops. That's my position and I stick to that position.
We do impact analysis badly? Add it to the list of processes that need improving. What is the most pressing need? My experience is that all my clients have more urgent problems than poor configuration information.
Even if impact analysis is a high priority, what is the cost and risk of manually determining impact? How often do we actually get it wrong or late? Can we improve that? How much would technology contribute to that improvement (as compared to improving culture, behaviour, process, and procedures)? There will always be a manual component if only to verify the result. Would CMS be the best choice of technology? Are there simpler tools (e.g. spreadsheets, query analysis tools, knowledge sharing ...) that deliver more bang per buck?]
See also Refining the Five Percent Club
Made in New Zealand 
Comments
Maybe a bit more than 5 %
This comment was moved to a blog post
CMDB Debate
Priapism.
Configuration Management and CMDBsj for More Than Just IT
Hello All,
There are many reasons why CMDBs fail but the primary ones I've come across, through my own travels include:
1) Scope : CMDBs only focus on IT infrastructure, applications, sw, etc. when they should also be taking into account things like Business Configurations
2) Manual Entry and Maintenance of CMDB Data : IT, who responsible for automation, appears to have forgotten how to automate
On the issue of "Scope" (#1), IT has forgotten to include the business in its CMDB efforts. I believe this has to do with the fact that like with the definition of "Service", which I believe is only IT centric and forgets to involve all other areas of a business, ITIL gave a highly incomplete view of what a CMDB really is and what it is intended to contain. The IF4IT has identified literally hundreds of different types of "Configurations" that are, at some level or another, important to a business. (This list is scheduled to be published later this year as a subset of the Foundation's Master Inventory of Taxonomies, which will include a Taxonomy of different Configuration Types.) A very small list of examples include but are not limited to:
IT Related Configurations...
- Build Configurations
- Package/Packaging Configurations
- Distribution Configurations
- Installation Configurations
- Execution Configurations
- User/End User Configurations
- Hardware, Network, Software, Storage, Application, etc. Configurations (a very long list of "Noun"-driven Configuration Types)
- Etc.
Business Related Configurations...
- Account Configurations
- Sales Configurations
- Employee Configurations
- Contractor Configurations
- Organization/Organizational Configurations
- Office Configurations
- Role Configurations
- Facility Configurations
- Etc.
So, given that there are so many different types of configurations that need to be inventoried, accounted for and managed, ITIL's view of a CMDB is limited in scope and leaves out all of the important things to a business that help decision making, like business impact analysis through the understanding of relationships between Business "AND" IT entities/objects. To be implemented correctly, a true CMDB must take into account a much broader picture than just a small area of IT. Building effective CMDBs that matter to business leaders have a much higher chance of being funded and implemented. In essence (and at its simplest level) a CMDB is really nothing more than being able to 1) inventory all nodes in space, regardless of their data types, 2) be able to create relationships between any two nodes in space and 3) be able to add context (such as time sequencing, priority, etc.) to those relationships. If anyone is interested in the real future of CMDBs, I suggest you start researching things like the Resource (or more accurately Relationship) Description Framework RDF, which is an open standard, and solutions that use them, such as Semantic Stores (sometimes referred to as "Triple Stores").
On the issue of Manual Entry and Maintenance of CMDB Data (#2), a successful CMDB will contain a huge amount of data that will go far beyond the capability of any enterprise to keep it updated and fresh, by hand. A smart enterprise leverages or builds "Relationship Scrapers" that know how to efficiently go into many different enterprise data sources or tools and harvest relationship information (i.e. dependency information) that gets pumped into their Semantic Stores. An even smarter enterprise knows how to do so "transactionally" at the moment of data creation, update or delete. Some examples of this include...
Human Relationships
---------------------------
- Upon update of an organizational chart, a transactional Organizational or Human Relationship Scraper will know how to create an inventory of all related nodes (Resource, Manager, Administrator, Organization, Parent Organization, etc.) and create or update meaningful relationships between them, ultimately pumping such information in the form of a "Relationship Graph Model" into a live and highly transactional Semantic Store.
Sales Relationships
------------------------
- Upon entry of a Prospect into a Sales System, a transactional Sales Relationship Scraper will know how to create an inventory of all related nodes (Prospect, Customer, Sale, Product, Region, Product, RFP/RFI/RFQ, Sales Organization, Sales Person, etc.) and create or update meaningful relationships between them, ultimately pumping such information in the form of a "Relationship Graph Model" directly into a live and highly transactional Semantic Store.
Software Relationships
-----------------------------
- Upon kickoff of an automated build of Software, a transactional Software Relationship Scraper will know how to break the build into its build dependencies (Source Files, Source File Deltas, Libraries, Modules, Build Computers, Build Environment, Build Resource, Application Name, etc.) and create or update meaningful relationships between them, ultimately pumping such information in the form of a "Relationship Graph Model" directly into a live and highly transactional Semantic Store.
The power that comes with these different types of Relationship Scrapers is that with each Relationship Graph Model that gets put into a Semantic Store, you build a relational piece of a knowledge universe. Graphs will "naturally" start to connect through common nodes, creating even bigger and more powerful Graphs and "this" will allow users to traverse from node to node, from one contextual universe of data to another, allowing powerful impact analysis through Degree of Separation Discovery.
In summary, if you want your CMDB to get funded and implemented, you have to 1) think "automation" to maximize knowledge of nodes and relationships and 2) think much bigger than IT Operations. IT Operations is a sore spot for most businesses (for many reasons, like being too big, slow and expensive) and is not typically considered a space that is high on a business's priority list. However, give your business a Degree of Separation view that ties business constructs together through visual relationships and you'll see a very different reaction from them.
NOTE: Once you have your nodes and relationships in your Semantic Store, you can layer powerful (and cool) visualization tools (because a picture is worth a thousand words) over your Semantic Data. Take a look at things like "http://thejit.org".
Anyhow, I hope this adds value to the topic.
My Best,
Frank Guerino
The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices
CMS
yes, semantics again.
The definition I work by:
A CMDB or a CMS is not simply a collection of data sources. It presents a single view of the service, and especially of the impact on the service of changing or breaking any CI. The key is the storage and management of relationships. If CMS is not a specialist term for that kind of database, if CMS means "any collection of configuration data", why have the term at all? It ceases to have any value. Let's just call it configuration data.
By that definition of a CMS I don't think many are around. incidentally by that definition i believe there isn't a single benefit to CMS that isn't actually delivered by the simpler underlying technologies except service impact analysis.
As for the percentage penetration, beware of the bias i have talked about before. if you spend all your time in the USA and all your time speaking to large organisations and all your time being invited to orgs that are already predisposed to having a CMDB, of course you will get a biased view of the world. My view of the world is equally biased the other way, but my personal estimate is 2%. I allow 5% as a correction to my own bias.
Indeed CMS is the future, as we get better at automating it more cheaply. That doesn't change the fact that right now it is a bad business decision for the vast majority of IT shops. That's my position and I stick to that position.
We do impact analysis badly? Add it to the list of processes that need improving. What is the most pressing need? My experience is that all my clients have more urgent problems than poor configuration information.
Even if impact analysis is a high priority, what is the cost and risk of manually determining impact? How often do we actually get it wrong or late? Can we improve that? How much would technology contribute to that improvement (as compared to improving culture, behaviour, process, and procedures)? There will always be a manual component if only to verify the result. Would CMS be the best choice of technology? Are there simpler tools (e.g. spreadsheets, query analysis tools, knowledge sharing ...) that deliver more bang per buck?
CMDB, like it or not, is in your future
It is probably true that only 5% of organizations have successfully implemented and justified a full CMDB. And, even less a physical CMS.
And, a few years ago I was a monster skeptic of standalone CMDBs. I now see it differently.
I conceive that we might want to consider the value or validity of CMDB as a standalone application a moot point. The big vendors have, or are in the process, of incorporating CMDB into their schemas as an integration tool for all their disparate products. A CMDB helps vendors provide quicker value for their customers that use multiple products - and does a great job of locking customers into their suite of products. CMDB will soon be a done deal for users of most products. Whether or not CMS or CMDB has an ROI on its own, therefore, no longer seems to be an issue worth fighting over. Because CMDB is here to stay for a while.
Let's agree, just for this discussion if necessary, that we should define a systems architecture not only in technical terms, but also how it will distribute political control over information, because all economic benefits arise from use and not from design.
Service Management tool vendors are changing their tools so that their CMDB (uCMDB, MDB or Atrium) is the federated center of their data sharing scheme. These CMDBs are a centralized, federated data sharing warehouse.
It seems to me at this time that the CMDB is to be validated as an extension of all the tools. That the ROI, if any, is to be viewed from the increased usability, and accuracy, of the data that might result in more proactive, coordinated actions among the different IT silos - Service Desk, Asset Management, Operations Event Management, Change Management, Application Lifecycle, Quality Control, Release, Continuity - etc. And, even if there is no proven ROI, probably because the cost of the integrations has not been measured in the past, then one can, at least, measure the cost of the numerous integrations (or, more likely, the cost of what those integratons would cost if you had them).
Since CMDB is in the future for most companies - it is a necessary part of the Service Management products they use - it would be better if we find ways to exploit this technology for the improved IT consistency of performance that, when properly implemented, may result.
We emphasize the concept of stewardship with our clients. It seems to me that the larger organization has entrusted IT with the duty of caring for and managing ALL of the IT delivery. These days this means coordinating a supply chain of externally supplied and internally supplied services and the resources they require. Knowing, in detail, what you "own", how it fits together, who's using it - Kipling's six honest serving men - is key to fulfilling the duty of stewardship.
No Business Case Until Your Culturally Ready to Tackle Services
Hello Skep
As Carlos points out we have had this discussion before!
First I agree with you that there is no business case for a CMDB for a Technology Focused IT culture which does not manage against systems or services. (Many are not even aware of what those are) All you need for Technology Management are stand alone repositories of data managed by each silo or domain for the purposed of inventory or asset management. By the way you can add Service Level Management, Service Catalog, Service Portfolio, and most of the ITIL processes past Change and Release Management to your list while you are at it.
However, the day that same company wakes up to the need to manage their environment in a systems thinking mindset versus pretending that each silo lives in mythical isolation these stand alone repositories no longer cut the mustard as they say. (Enter your 5%)
The real issue here is that 5% of IT companies have not progressed up the maturity latter of IT Management Technology to Value Chain enough to realize they even need one.
Two articles I have written that look at this subject:
Cultural Roadmap For ITSM Adoption: http://bit.ly/dvxAXP
CMDB – Spruce Goose, Death Star Or Answer To World Peace? http://bit.ly/cnaPUl
Slight correction
Troy you state: "The real issue here is that 5% of IT companies have not progressed ... enough to realize they even need one."
I believe you mean 95% have not progressed to that point, to which I would agree.
Regards,
David
Here we go again...........
So.....here we are again....... in a "CMDBs are worthless"...... debate!
I think that the discussion keeps getting smashed against the rail when scope and scale are not introduced or are outright ignored.
As I've mentioned several times in the past, if we focus on the "purpose" and "intent" of a CMDB/CMS it's hard to argue its value. However when scale and scope are ignored, it's easy to say that they are too costly. You continuosuly make reference to millions being spent on this topic (which I don't disagree with you on), but sadly, there are a lot of people who buy the wrong products every day REGARDLESS of topic. Some of these people are the ones who spend $1M to solve a $10,000 problem. People who try to kill an ant with a M1A1 Abrams tank are not assessing their problem properly nor selecting the instrument correctly. Isn't that where the bigger issue is? People not understanding the problem they need to solve before acquiring tools to solve it?
So, that brings us back to the same point we typically end up with in nearly all of our debates: semantics.
I've stated in writing frequently and in many if not most of my speaking engagements/presentations that if you can map and demonstrate your services with spreadsheets and post-it notes then that is the most cost effective solution for you at that point in time, so go forward with it. The key being "at that point in time" of your organizational maturity and need. However, if/when you're company grows, increases the pace of changes/RFCs, enters into a delivery model that is more time sensitive..... then a manual solution using spreadsheets and post-it notes will not work. If they leverage a lot of automation and/or virtualization, using spreadsheets and post-it notes again will not work. Bottom line is that if the problem you're addressing changes in size, scope, or any other characteristic........ your solution must also change.
People who have worked in or consulted for organizations that have a dynamic environment be it because of size or function, understand that there is a definite need for some tools that provide insight into how services are delivered and the IT devices that help to deliver them. Those tools make up the CMS. What those tools specifically are.... well...... that can only be defined on a case by case / problem by problem basis.
Another area that I don't think gets fully assessed is the cost of doing it manually. People are not free or cheap and they leave their jobs at an ever increasing pace so with them goes a tremendous amount of worth that will take months to recoup, if not years, with a new employee. If a fully loaded cost of an employee doing this manually (device mapping, fire fighting, explaining and educating) is $125,000/yr.... how many of these resources does it take before tools are a cheaper alternative? Obviously some of it CANNOT be done with tools but.... a lot can and I don't see a lot of companies doing a lot of hiring. In fact they're looking to automate as many people out of jobs as possible. I would love to see or hear from a company who has authorized the hiring of 5-10 people to do this manually. ( 5 * $125k = $1.25M ) Not cheap for one year!! Even tools are cheaper than that.... 10 people makes it $2.5M for one year!
Statistics and research can be interpreted in many many ways and I have no idea what went into the study that EMA did especially without seeing the raw data, sample size, participants etc. For example, "4 out of 5 doctors recommend using Crest toothpaste" gives you no indication if they are dentists. Maybe they have a Phd in Electrical Engineering. They have a doctorate degree but that doesn't qualify them to make the statement about Crest toothpaste. No, obviously it doesn't but someone watching the commercial would not know that because they are legally a Doctor..... just not a medical doctor or better yet.... a Dentist.
So, with regards to the 5% club, guesstimate you made about organization size and the percentage that EMA speaks to... is the calculation based on outright number of companies? Gross Revenues? Employees? Sites? IT Size? Does it include companies who have outsourced their IT? If so, are they part of the 5% if their outsource partner uses the concept of a CMDB or are they excluded because they don't have one in house? Did they make multiple attempts before fully understanding what it was about? Did that count multiple times? What is the exact definition of a CMDB or CMS that they are using to make the determination? The point I'm trying to make is that numbers like these although possibly true, never give the full story and should always be taken with a 50lb bag of salt.
People and companies need to take responsibility and accountability for their actions. They can't continue to blame a concept for their failures. The companies in the study maybe wanted to lay blame on tools and technology rather than poor planning by themselves or lack of knowledge before venturing into it. CMDB and CMS are concepts that then get implemented. Failure on the implementation does not invalidate the concept.