heretical views on ITIL Configuration Management

Recently Stephen Mann had the temerity to suggest Dear #ITIL, Please Kill Off The Configuration Management "Process", a variant on the heresy I've been proposing since 2007. Stephen said:

reconsider the ITIL process we call “configuration management” and, rather than just looking at its worth, consider it from a real-world perspective.
Who can afford to do configuration management?
And who can afford not to do configuration management?
But in many ways this is a red herring. People might find configuration management hard to justify and therefore hard to resource in cash-strapped IT organizations. They might even find it hard to do. But if all they are doing is configuration management for configuration management’s sake then does it really matter?
...how often is a CMDB the place where IT data goes to die?
...Like knowledge management, surely configuration management should be part of operational processes?
It’s not a new concept – that for knowledge management to have any chance of really working it needs to be embedded within business processes rather than being a discrete and disconnected activity that in reality never gets done. For me the same is true for configuration management.
By all means we can still talk of configuration management. It could even be a sub-process of the ITIL-espoused processes that people do actively use. And, yes, we could still have someone responsible for configuration management. But having configuration management as a separate process? I think we have proven that it doesn’t really work outside of large organizations that have the funds to apply significant resource to it.

When he posted a link on the LinkedIn "ITIL & ISO20000 Service Management + ITSM " group, the defenders of the ITIL orthodoxy fizzed, (and clearly they hadn't read the blog post):

Sure, why not kill it off when you don't understand it. There's nothing new about doing that...
Could this urge to kill it off be driven by the lack of capability in the ServiceNow tool? I think your lack of understanding of the process and capable competing tools is blinding your judgement...
Knuckle head! CMDB is the glue used to bind all the process together...
A CMDB to a service management is like petrol for a car if you don't have them you won't get very far...
Impossible to implement higher level processes (design) without proper CMDB...
Without a Proper Configuration Management, the Service Management implemented for a process or a project is useless...

of course some talked sense

These things can all be overcome with commitment, hard work and - often - a lot of money. The challenge lies in being clear about the value of doing so, and ensuring that the value outweighs the cost.

but they were pretty much drowned out amongst the outrage.

I tried to comment on the LinkedIn post but it seems not to have got past the moderators (more defence of the dogma), so [After posting this, my comment was enabled. To be fair it may have got blocked by LinkedIn because it had links in it. Nope: all my comments on that group go to moderation. When you piss people off you probably hit a nerve :)] here it is:

How many organisations have a CMDB? About 5-10%?
So the rest aren't doing service management? Their processes are useless?
Actually everybody does SM. There is no such thing as an absence of SM. The question is one of maturity.
Everyone does configuration management. Not all do it well. Many do it well enough to meet the business's service needs. And they do that without falling for the craps that they must have perfect configuration information. This is technical fastidiousness, divorced from business realities. I call those who actually really need a full CMDB "The Five Percent Club". The rest of us get by just fine thankyou with fragmented data and stuff in people's heads.

Stephen's suggestion that we stop glorifying configuration management with a "process" of its own and treat it as an integral subset of other practices - in as much as we can afford to do I've discussed Configuration and CMDB ad nauseum on my blog since 2007 http://www.itskeptic.org/cmdb
but since I led with my chin, I'll summarise some of the arguments here:

The "purist" ITIL definition of a CMDB is a database of the relationships which define the configuration of a service. No relationships, no parent service CI, no CMDB. Anything else is just buckets of configuration (or asset) data. Very few organisations have a CMDB and many of them work just fine.

Likewise Configuration Management as a practice (I hate the word "process") for its own sake is an over-investment, an over-complication for many organisations, who work just fine managing those islands of configuration data as part of Change Mgmt and Asset Mgmt (and network Mgmt and ...). Stephen's point.

In fact, for many organisations the best place to track the complexity of service relationships is in people's heads (or have people to deduce it dynamically from the islands of information on-demand as needed for impact assessment - which is what happens in the majority of organisations today). Humans are cheap, flexible, and self-correcting. Our lust for perfect information stored in technology is a symptom of Excessive Technical Fastidiousness. If we determine impact of incident and changes fast enough and accurately enough tro meet business needs, and if improving our performance would cost more than the money we save, then CMDB is a bad business decision driven by "ooh shiny" technical thinking. Often the money would be better invested in making sure we have human redundancy, and in training those humans to do configuration management better.

For those organisations (a) whose service configuration is so complex and dynamic that humans cant track it or deduce it fast enough, and (b) who can build a business case for saving money by tracking it better, and (c) who have enough available funds to actually implement a dedicated Configuration Management function and build a CMDB without better uses for the money, .... welcome to the Five Percent Club.