What a load of .... Computerworld: How Much Is 'Just Enough' for a CMDB?
This article has been podcast in slightly modified form.
Antonio gave us an interesting link in a recent comment. Excuse me folks, but what a load of crap it is.
"A just-enough CMDB should provide a full picture of the following:
All technology components related to the specific service.
The relationships and interdependencies among those components, including relationships between logical and physical components.
Context from a service perspective -- role-based views of the technology that consider the requirements of the audience.
State, in terms of availability, business performance and technology performance.
Governance -- automated management of what is currently running versus what should be running and was last approved.
Management of service through defined, monitored and automatically managed service levels.
It is important to note that a just-enough CMDB must include definitions of services and information on state and automated governance/management, all frequently updated."
Dear God, what isn't in there? How does "just-enough" differ from "everything"? This is "top-down" alright: "top-right-down-to-the-bottom".
This is 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.
"less is more ", "top down", "just enough", "relationship-discovery tools", "design and implementation can be made much easier", "critical services".... Crap.
If you drill down far enough to find everything listed here for just one service, the complexities and inter-dependencies of a modern IT environment mean you will have found a fair proportion of your entire environment. And wasted plenty of time and money doing it... if you ever get there.
Made in New Zealand 
Comments
Phew, what a rant
I've calmed down now. I thought of toning down my remarks, but in the interests of blogalistic integrity I'll leave it there.
What is happening with the vendors and analysts with CMDB as represented by this article is interesting.
What is being left out of this proposed "just enough" CMDB? The whole concept of the CMDB as the CHange Management repository, that's what. Presumably the JECMDB does not include desktop devices and their software. It does not include objects that support only a "non critical service".
It has all the functional complexity of a full CMDB, just less data, which confirms my thesis that scale of data is the fatal flaw of the CMDB concept.
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.
Which is what this article was saying without them realising it, which is why Antonio drew it to our attention. "You can [have to?] do without a full CMDB to get the job done". So before I went off my head over vendor sweet-talk I should have realised that this article is actually wholeheartedly supporting me, and I am supporting it.
Coming soon to this blog: living without CMDB.
Full or partial CMDB coverage
hate to repeat what someone has probably already said, but I might have a slightly different perspective on what level of coverage delivers value.
1. Full coverage or not worth doing.
If you're covering space, capacity, assets, work orders, future reservation, and other things in your CMDB then anything less than 100% is not going to enable common processes as you woudl hope as you don't have a high degree of confidence to be able to plan changes. Knowing all the hardware is necessary to mop up warranty, spares, value, ownership, billing etc. So typically physical infrastructure is - do it all, or carry on with site surveys, emails and meetings to communicate local knowledge.
2. Partial coverage, still worth doing
Mapping processes, apps, servers, networks etc. is worth doing, even if it is not 100% of all potential objects. Why? because the most critical things are what you most need to control. So any service, or app that is covered by internal business criticality and also DR, SOX, regulators, etc is worth doing. It saves on duplication and gives a higher degree of control than without it. Call it logical infrastructure as a generic term. The complexity problem of mapping databases, to apps, to hosts, to customers, to storage and so on means you can only get a handle on a few. But it is still worth it.
If you try and get your CMDB to do both and be 100%, then you will fail spectacularly. I know implementations that have over 10,000 servers worth of stuff - but the only apps that are mapped and verified are the top 150. No desktops at all. If the CMDB didn't exist then change requests would have nothing to reference to manage multiple changes by project teams and outsource partners. It works mostly, which is good enough.
Irrespective of whether the CMDB data is comprehensive or acccurate, it still has to be looked at. The expression RTFM comes to mind.
dave
Another voice for fullCMDB can't be done
Thankyou Dave for supporting our position on CMDB. "If you try and get your CMDB to do both and be 100%" [i.e. if you try and do CMDB as defined by the ITIL books] "then you will fail spectacularly". And thanks for a different perspective on slicing the CMDB problem.
Lean, Federated CMDB?
If you are a CIO do not read any further....
I'm sorry to be so dense on this but... so after a few years of wondering what a CMDB was - and waiting for a gaggle of vendors to define for us what their software should be doing in this area, we have now gravitated somehow to the conclusion that we need a lean, federated, just enough CMDB that according to ITIL V3 (I have just finished mapping all the new terms!), may include the 'Availability Management Database', 'Definitive Media Library', 'Service portfolio', 'Service Catalogs', 'Software Asset Management Database (V2)', 'Release Records', 'SLAs', 'OLAs'.............
and is a component of the Service Management Knowledge System (along with the Supplier and Contract Database).
I for one am so hoping the 'Introduction to the ITIL Service Lifecycle' book provides a diagram of this Russian Doll CMDB! as I remain unsure where to put the Change and Capacity databases, contract portfolio, core service package, service pipeline, customer portfolio, SLAM charts, service reports, knowledge base, and service level requirements... hhmmm...
I think we need help... will the real definition of a CMDB please take one step forward.
we got a double shot...
I like v3, particularly the lifecycle, some of the 'new' processes and some of the organizational stuff; but I agree with your comments...I think the 'CMDB movement' is more vendor driven that customer driven....so many data bases! such room for innovative tools!
why don't we simply say that tools is tools, you gotta map them to your specific needs and don't look for 'out-of-the-box', visions of nirvana, 'integrated ITSM solutions' or easy answers...and certainly not the ITIL pubs....
everyone has thier own opinion on what 'tools' should be doing, and I am certainly no exception...there is never 1 right answer and likely never will be...I know many people who looked for erp solutions for 'integration'....some got it, some not.
how 'bout a homogenized CMS leveraging an integrated portfolio with a dash of active catalog and a splash of dikw analytics? won't do much but won't give you a hangover either.....I agree we got a double shot with v3
personally, I'm in favor of a 'rent a tool' movement anyway; solve a need or be excreted. seems quite consistent with a service movement...
the more some things change, the more they stay the same....
do your homework....balance the long term with the short, validate vendor claims, and most important know yourself first....where are you spending the most time and money?
adopt and adapt, right?
John M. Worthington
MyServiceMonitor, LLC
The return of the IBM Suppository?
Great verbiage John, somewhere in a previous life I vaguely recall the last 'CMDB soft-sell' does anyone remember the IBM DB2 AD/Cycle 'Repository', nicknamed by many of us in the Performance (Capacity) Management profession the 'Suppository'..... seems like IBM had it right - put everything you can in one database - or was that the black hole theory?
one repository to rule them all
from a previous post on this topic:
or on a different topic but the same theme:
That's why we need a distributed systems architecture
It's a distributed systems architecture. That much is obvious. But there are lots of overlaps. See "A story of too many tools," http://erp4it.typepad.com/erp4it/2003/12/a_story_from_a_.html
Also see http://erp4it.typepad.com/erp4it/2006/04/here_is_a_simpl.html, which is only a highly summarized version of chapter 4 in my book.
Charles T. Betz
http://www.erp4it.com
CMDB Kool-Aid can result in a Bad Trip...
drinking the CMDB Kool-Aid without starting out with a clear head can result in seriouos flashbacks, so attention all you customers: be careful of anyone offering up a CMDB as "the road to ITIL enlightenment"...we've seen this before...
remember when we had a management console for each device? the solution was SNMP, and we implemented 'frameworks' to 'unify' our management/operations centers...a good thing, but of course too much of a good thing can be dangerous and we had many casualties...remember most of your dollars going to getting those frameworks implemented? (they are implemented, right?)
starting a journey down the Right Road (ITIL) means heeding the Good Book's advise that one should ALWAYS understand your existing processes first, BEFORE any attempt to automate.
the fundamentals for buying tools don't change just because you've seen the light and are moving toward it (that's not a train up ahead, is it?)...you apply the tool based on what will bring you and your business the greatest return based on where u r today and where u need to be....ITIL does not re-define common sense...
there will be a point at some time along the journey when you realize that you've created a fairly decent CMDB for your needs, and it is enabling you to achieve higher levels of automation and process maturity; but coming out of your Foundation class, putting 90 pounds of air in the tires, and stepping on the accelerator may not be the safest path to enlightenment.
do the grunge work first and understand that the CMDB is not the exclusive highway to heaven; in fact, taking this ride without some serious preparation can result in a savage journey indeed...
I've had success leveraging some newer (and less well known) tools that do not create (or even attempt to leverage) the CMDB hype. For example, I know of a service monitor that creates a "virtual operations bridge"...it does so by creating more of a CDB than a CMDB, but who cares? Customers who have implemented it (even those that did not know they were on the RIGHT ROAD) have achieved a greater paradigm shift (and greater ROI) than many I've seen who are (still implementing) a CMDB...
don't get me wrong, I'm a believer in ITIL and feel everyone needs to get on the Right Road and building a CMDB is part of that. However, people need to look in the mirror and see what path is thier path; by all means drink the Kool-Aid, but know yourself first...
John M. Worthington
MyServiceMonitor, LLC
CMDB: the all-embracing, multi-relational Hydra monster
You know what John, I agree with everything you say. "Coming out of your Foundation class, putting 90 pounds of air in the tires, and stepping on the accelerator " LMFAO!
There is an interesting issue of semantics here which leads into the next blog post, coming soon. That is the distinction between having a repository of some info and having a full ITIL CMDB. I'm all for having a good database under the service desk, and under the systems management and under the financials etc... But they aren't the same as an ITIL-defined CMDB. You make that very clear "more of a CDB than a CMDB".
So all readers please understand my beef is not with collecting data. I am against attempting to create the all-embracing, multi-relational monster that ITIL specifies. Let's be careful to use CMDB only when refering to that Hydra, and not subsets of it which are generally useful.
And John, thanks for reminding me of the SNMP frameworks as yet another example of the one-technology-to-rule-them-all mindset of geeks gone mad. Those who know my past know it is a bit embarassing that I left that one out!
The hydra revisited
Hi Skeptic!
When I read your comment about the multi-relational Hydra monster, I recalled about the first post in my blog, talking about the concept of FCMDB (Federated CMDB)... I think you will like them
http://gobiernotic.blogspot.com/2006/03/la-cmdb-federada.html
http://gobiernotic.blogspot.com/2006/03/ms-reflexiones-sobre-la-fcmdb.html
Regards!
Antonio
Hydras and Gorillas...
When you hear about hydras 'cooperating' on a standard for FCMDB, it always makes me nervous...hope they'll be enough newbies left to keep the 800 pound gorillas focused on customer value (rather than protecting marketshare)...see CMDB Interoperability: waiting for nervana
John M. Worthington
MyServiceMonitor, LLC
all on the same wavelength
Yes I saw your comments. You and Doug McClure and Antonio and I are all on the same wavelength on this one!!
Right on
You've said it all before Antonio (if I decode Babelfish correctly)! Thanks for those links. Always nice to know I'm not alone in the wilderness :-D