CMDB inappropriate for ITIL - The IT Skeptic
- Artist: The IT Skeptic
- Title: CMDB inappropriate for ITIL
- Album: ITIL
- Track: 7
- Genre: Speech
- Year: 2006
- Length: 6:24 minutes (5.86 MB)
- Format: MP3 Mono 22kHz 128Kbps (CBR)
This is a podcast of the original blog post by the IT Skeptic
...the kind of platitudinous claptrap peddled by vendors and their analyst sycophants to lull people into adopting their lunatic ideas (and buying their products and consulting). Make it sound easy, obvious and do-able....They see CMDB is too hard, so they are trying to come up with methodological approaches that will lessen the problem, by breaking off bits and calling that a good-enough CMDB. But they are addressing the symptom not the problem.
The problem is that CMDB is an inappropriate underlying concept for ITIL. It is fundamentally at odds with the basic principles of ITIL: pragmatic and conservative use of existing environments in better ways; fixing processes not technologies. It can't be done practically but people are busting themselves trying and they are living with half-baked compromises like this one.
We need to come to terms with the fact that CMDB is an alien intrusion in the ITIL world. It is a nice-to-have peripheral technologist's fantasy that we can do without.
- Download audio file
- 3302 downloads
- 142 plays
Made in New Zealand 
Comments
CMDB or how to overcomplicate the simple things in life
When I was working for a major IT Outsourcing provider, I argued that a Real CMBD like a Real Project Plan was a word processor document not a database product. The CMDB is the descriptor of a configuration, not an Asset Management System on Steriods.
Why do I need a tool other than a Word Processor to say:
Config ID: 10-0001-200701
Config Type: Desktop
Config Name: Basic Desktop Workstation
Processor: Intel Core 2 Duo
Speed (GHz): 3.5
Bus Speed: 600 MHz
Memory Min: 1GB
HDD Min: 100GB
OS: Win XP SP2
Patches: See Config ID 30-0500-200612
Related Config ID: 10-0101-200701, 10-0201-200701
Replaces: 10-0001-200607
Authorised Suppliers: Dell, Hewlett Packard
Notes:
Config ID: 10-0101-200701
Config Name: Enhanced Desktop Workstation
Processor: Intel Core Duo
Speed (GHz): 3.0
Bus Speed: 533 MHz
Memory Min: 512 MB
HDD Min: 60GB
SOE: 30-0500-200612
Related Config ID: 10-0001-200701, 10-0201-200701
Replaces: 10-0101-200607
Authorised Suppliers: Dell, Hewlett Packard
Notes:
Config ID: 30-0500-200612
Config Name: Win XP SP2 - Base SOE
Patch Level: All patches issued by Microsoft up to 01 Dec 2006
Related Configs: 10-0001-200701, 10-0101-200701, 10-0201-200601, 20-0001-200701, 20-0101-200701, 20-0201-200701
Replaces: 30-0490-200611
Authorised Supplier: Software Spectrum, Microsoft
Notes:
This is a CMDB. These Config ID's can now be used in the Asset Management System for reference. The Config ID's use descriptive numbering. 10 is PC's, 20 is for Laptops, 30 is for OS etc. The last six characters show the year month (Version Info). The middle 4 characters are used for unique Config identification.
I continue to watch in amazement as vendors try to out comply each other with more features and complex functionality. CMBD is not complex. The Asset Management System, if kept current, can provide details of the volume of each configuration in your environment. How hard is this?
VaioBoyAus
Look at what a CMDB is
Look at what a CMDB is primarily for:
a) to check the impact of proposed changes,
b) and to measure the impact of an outage or degradation on a service and hence SLAs
The key thing about a CMDB is the relationships and the ability to walk them fairly easily and quickly to find the impacted services and SLAs.
Another essential is that the CMDB record not just the atrributes but also the status of the CI. if it is down, the CMDB should reflect that.
So I find myself in the unlikely position of defending the CMDB concept against an oversimplification.
You can't do CMDB in a static doc because CMDB is not static documentation. Your doc is a very useful artifact but it isn't a CMDB as the beast is defined.
Ah active discussion about a CMDB
Configuration Management Database - A database used to manage Configuration Records throughout their lifecycle. The CMDB records the attributes of each CI, and relationships with other CI's
Configuration Item - Any component that needs to be managed in order to deliver an IT Service.
Cofiguration Management - The process responsible for maintaining information about Configuration Items required to deliver an IT Service, including their relationships.
So lets look at my CMDB example doc.
1. I have the attributes of the CI.
2. I have the relationships with other CI's
3. Using the CI identifier, I can go to the Asset Management System and determine the volume of a given CI within the business and/or at a specific location.
4. If I need to vary a CI or instantiatate a new Variant or Version I can do this.
5. I have the level of control that the Business deems both manageable and with the degree of granulatity they expect.
6. I can cross refer to the DSL as can be seen by the OS link
7. It is easy to add new CI's and Delete old CI's
8. Support for the managment and use of configuration baselines.
Sure it does not satisfy all the requirements of 7.9.1 of the Blue Book but it sets me up to look at the gaps I need to fill and I can now start to envision the complexity of my environment.
I can do some trend analysis, albeit limited, of the effectiveness of Change Management in the environment.
Sometimes we have to crawl before we can walk, some people don't crawl and just start walking because they get it.
Hence as a rudimentary CMDB my document example serves its purpose depending on my organisational maturity.
I believe that the perfect CMDB is a pipedream foisted on an unsuspecting world by people who have never operationaly managed a large IT environment.
The real CMDB is a combination of a number of datasets, the Asset Management System, the Incident Management System, the Problem Management System and the Change Management System. The accuracy, level of integration and data matching will determine the usefulness of this pseudo CMDB. I would expect that the data model from the technology supplier would expose this integration of views and data. Am I getting ahead of myself here?
As is almost universally the
As is almost universally the case, we are in perfect agreement and any apparent disagreement is a consequence of terminology definition.
On this webiste at least :-) a CMDB is what ITIL defines it to be as ITIL coined the term. One of our hobby horses is terminological debasement: people redefining terms to suit their own purposes. As you say the thing you have defined "does not satisfy all the requirements of 7.9.1 of the Blue Book". It is therefore not a CMDB.
As you also say "the perfect CMDB is a pipedream foisted on an unsuspecting world by people who have never operationaly managed a large IT environment." I actually think they did operationally manage some extremely large environments, but otherwise I completely concur. CMDB is a techno-geek's fantasy technical solution to a process problem. It should never have made it into the ITIL books and it most certainly should not be a central pillar of ITIL.
So let's not let them off the hook by re-defining it as something weaker.
Hmmm a joint Glossary may be a great idea
You, Mr Skeptic, are indeed an observant and insightful man. Perhaps that is the real problem here, given the hype associated with ITIL, CObIT etc a working persons guide to ITIL starting with a Glossary would be a great idea. I have checked some of the hyperlinks you suggest and would not want to reinvent their work.
I might have a soft disagreement with your statement "I actually think they did operationally manage some extremely large environments", I actually think they would have liked to have managed some extremely large environments. to test their theories.
I apologise for my oversight, I will do my best to use terminology both correctlly and in context in the future.
unfortunately they didn't stick at what was proven
I know some of the original people and they knew their stuff. they also drew from many more who did too.
unfortunately they didn't stick at what was proven but also reached out to what would be nice to have in future: CMDB
"Glossary" implies a comprehensiveness i don't want to aim for, but definition of some mis-used, ambiguous or controvertial terms would be a good idea, thanks
Must disagree - CMDB concept is worth striving for
Don't agree with your interpretation of what a CMDB is, or should be. Can't be done solely as a word document, though word docs such as build standards (what you are describing is certainly to be included. A few reasons why the CMDB approach is worth adopting.
a. A config item (h/w, s/w, service, etc.) requires to be identified so it can then be logged, tracked and relationships with other CIs logged. Its good to agree what is a service, what is our lifecycle for dev/test/production, what do we mean by an application - this is common sense, just emphasised by ITIL. Relating builds, status to CIs is the job of a database, not the spreadsheets I see most IT groups try to use. A word doc is the not the way to try and understand and track the guts of your IT infrastructure. Key to this is that it forces IT groups to own sets of knowledge which are shard by others.
b. If you did progress down the route, irrespective of what vendor solution is chosen (or even worse - self built) then you will get the benefits of a common knowledge base shared by all. The alternative is the hotch potch of word, excel, access, visio, powerpoint, service desk etc where not much is trusted and manual communication is used (often meetings) with every change or project request.
c. I agree that CMDBs from vendors are becoming over-complicated (i'm one myself) but that is because internal IT systems have evolved and do multiple jobs. The CMDB concept already exists in the aircraft world - lots of different pieces of hardware from multiple vendors, at different s/w versions all helping to get us from A to B. If IT processes and ownership issues were as mature as transport or other industries then we all agree that the CMDB is just the way we document and understand how services are delivered.
In the day job I apply the CMDB approach to power, cabling, desktop, networks, SANS, WAN, servers, software, services, systems, processes, environments, data centres, etc. It works well even if it just replaces a few spreadsheets because it delivers some benefit which is tangible.