ITIL's CMDB can't be done, no-how
This discussion of CMDB and its total impracticality has got legs. Let me reinforce two points please: (1) CMDB can't be done because of the data and regardless of the implementation and (2) I'm talking about CMDB as specified by the ITIL books, not any old database. It can't be done.
Frank Guerino was nice enough to quote the "CMDB can't be done" blog entry on the ITIL Community forum - I finally got back in after deleting all cookies, so it may have been a technical rather than political problem ;-)
He is absolutely correct and I want to stress the part about burning money on an irresponsible scale. If you convince your management to allow you to build your CMDB, you should consider whether or not you are doing it for your own personal gain versus for the good of the whole organization. The person that wrote this article has a very realistic view of CMDBs. He backs it up with a significant amount of very obvious and valuable experience and with a significant amount of supporting reference data and useful information. My advice is that you think long and hard about building your own CMDB. I believe you shouldn't do so. I'm betting that if you show all the information to your decision makers, they will be skeptical about doing so, too.
I feel that Frank slightly mis-represents me here. I didn't say CMDB can't be built. I said it can't be done. No-how. I don't care if you build it, use a spreadsheet, buy a Service Desk with one in it, buy Frank's CMDB tool, or post it all on Wikipedia for the world to see. The technology is - as in most ITIL issues - irrelevant.
CMDB can't be done because it is too complex to load or maintain the data, however it may be stored.
While we are here, let's address the points raised by Frank's correspondent from that same (long) forum topic in response to my blog.
CMDB needs not to include every single little thing (Every single little change or release), in fact nowhere in ITIL does it say so. CMDB is the most open tool of interpretation. It needs to capture only the information required capturing for an organization (I.e. to meet the business requirements). If Business need is only to capture information of one PC so be it, CMDB will only capture information for that one PC, if Business need is to capture information of all PCs and more so be it as well. CMDB can be everything and anything (In scale and in size) as required by the Business need as long as it is centralised (One stop shop) and ITIL methods are applied for controls and management.
We will talk about "sheep-dipping" soon. The author "finally got my Foundation Certificate" and I think is about to learn how a little knowledge is a dangerous thing [not that I can talk as I have no more than Foundation either - just a few battle-scars as well and a skeptical mind].
Well actually , Skip [let me call him/her "Skip": the author was from Sydney], if you read the book ITIL specifies that CMDB should hold "Every single little change or release". I quote from Service Support:
Configuration Management provides a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items (CIs) in existence. The goals of Configuration Management are to:
account for all the IT assets and configurations within the organisation and its services
"all the IT assets and configurations within the organisation". The word "all" is used a number of times throughout the Config chapter. The question of CMDB scope is what NOT to regard as a change or release.
Skip said: "It needs to capture only the information required capturing for an organization (I.e. to meet the business requirements)". Oh absolutely yes yes yes. "CMDB can be everything and anything (In scale and in size)" Well y-e-e-es maybe. In reality, even if you limit yourself to a few critical services, the underpinning web of CIs they depend on take you to most of the CIs in the business in a complex modern IT environment. Bear in mind, config management is a tactical process (service support) not a strategic one (service delivery). So the data needs to be sufficient to support day-to-day impact analysis and change control. And by the time a couple of key stakeholders wade in with their own agendas, everything is in the pot.
Stop me if I've told you this one: this guy was telling me how his CMDB was going to be successful because he focused on what mattered and left out all sorts of irrelevant stuff. Like what, I asked? Like desktop PCs. So there is no application code on the PCs?. Of course it turns out key app was client/server. OK so now PCs are in the pot. But we won't track peripherals like printers. Oh really, and what proportion of your helpdesk calls are for printers? OK printers are in but not keyboards or mice. Hmmm... but you are a government department: I bet you have to be sensitive about OSH [occupational safety and health] requirements [not to mention political correctness]. Got any disabled staff with special peripherals? By this time he's pale and sweaty and hurrying off...
The author of this article [that's the Skeptic] failed to address that most organizations already have CMDBs of some sort (In a disorganized manner). How often do we hear about 1001 spreadsheets? This is a CMDB (Of sorts). Difference between ITIL CMDB and existant CMDB (of sorts) is the control and methods of management applied.
Wrong. CMDB arguements so often turn into semantic games. It is a bit like the Bible. "When it says people should have their eye torn out, what it really means is..." "When it says wives are the property of their husbands, what it really means is...". The book (Service Support that is, not the Good Book) is quite explicit:
Detailed objectives for Configuration Management should include:... identifying, labelling and recording the names and versions of the CIs that make up the IT services, infrastructure and their relationships... reporting the current status and history of all items on the IT infrastructure... ensuring that all Changes to CIs are recorded as soon as practicable
it should be clear that Configuration Management is not synonymous with Asset Management, although the two disciplines are related... Asset Management systems maintain details on assets above a certain value, their business unit and their location. Configuration Management also maintains relationships between assets, which Asset Management usually does not.
Pretty clear, Skip. The stuff lying around your office isn't a primitive CMDB. You may be able to build what you are defining, but it isn't a CMDB.
Other stuff on CMDB:
- You have probably already read ITIL’s dead elephant: CMDB can't be done
- What do all the sites without a CMDB do? Fallacies behind CMDB arguments
- Live without CMDB
- Top 10 reasons NOT to implement CMDB
- The CMDB boundary problem: stop chasing this technological rainbow of a unified CMDB repository
- Get it straight: CMDB can not be auto-discovered
- Don't fall for the demo: an asset database with bells and whistles is not a CMDB
- Technology does not fix process
Read all on CMDB from this blog