The IT Skeptic - Comments for "A review of The CMDB Imperative"

5% Club

skeptic — Fri, 13 Aug 2010 20:37:57 +0000

Your comment echoes my own arguments:
Plenty of config data exists already, including plenty of 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
For the 5% Club (the tiny proportion of sites where this applies), that process gets so complex and demanding they need to automate all of it, i.e. build a CMDB/CMS

CMDB in the real world

Glen — Fri, 13 Aug 2010 16:13:02 +0000

Have to comment about the need for CMDB / CMS.

Must confess, that when I first took up ITIL, I asked my essentials instructor if the CMDB concept was a joke.
Need to knowing everything about all things in IT to make decisions sounds like a lot of heavy lifting. His response was to think of the CMDB like an indexing process. Imaging you have 1000 keys in a drawer, how would you identifywhich key goes to which lock.

The human brain makes intuituve leaps of logic. Individuals can llok at the physical connections and make the leap that connects them to a serivce interruption. Databases are not so flexible. However, When doing assessments around Configuration Management, I was typically told that "we dont have one."
But I always asked about network topology maps, relational databases, service mappings, etc. suddenly the lights would go on. People would start to realise that architecture and topology maps capture a large part of the spirit of what the CMDB refers to.

So some real world (ITIL Lite examples)
1) Utilities companies (i.e Power, Telephony, Water) around the world map the way devices connect to each other to delvier core services.
2) Airlines know how every component fits together within an airplane
3) In Apollo 13, knowing what was onboard to build a filter on the gorund and walk them through building it in space. (Smile its Friday)
4) Manufacturing JIT processes demand an intimate knowledge of what is required to keep the plant running, who supplies which elements and when they need to show up.
5)Librarians and the Dewey Decimal system. A logical model that lets them identifty, track and manage everything in their infrastructure.

Its about right sizing the level of detail to your needs. (I.E. Alignment of IT to the Business)

Practical approaches I have used include:
Identifying key services and mapping the underlying infrastructure that encompasses said service.
Mapping an LPAR to determine what is made up in delivering the print and accounting services.
Using price mapping to determine relevant resources.
Identifying critical CI's that make up Key controls and certification requirements.

Just a few thoughts.

Glen

wow

skeptic — Thu, 12 Aug 2010 18:59:50 +0000

The comments on this blog just get better and better. What a great point. I'm off to ponder that.

P.S. readers, never say "thanks for sharing" in a comment. It is the mark of the beast for spammers (I think it is the only English some of them know). I came so close to deleting this comment which would have been a dreadful mistake.

Nice excerpt. Thanks for

Visitor — Thu, 12 Aug 2010 11:42:22 +0000

Nice excerpt. Thanks for sharing.

I wonder what Miranda would have thought of Google Maps.

the $64 question

skeptic — Wed, 11 Aug 2010 21:34:32 +0000

See my latest newsletter for my views on leading clients out of the wilderness.

But the $64 question:

do you track relationships from service CIs to other CIs? i.e. Can you determine the service impact of a change or incident?

because if you can, you're a fiver-percenter. If not, I don't think you have a CMDB. You have a bunch of SACM data but it isn't a CMDB.

Or if it is a CMDB then "CMDB" doesn't mean anything any more.

Of Exactitude in Science (and ITIL)

Visitor — Wed, 11 Aug 2010 20:49:44 +0000

...In that Empire, the craft of Cartography attained such Perfection that the Map of a Single province covered the space of an entire City, and the Map of the Empire itself an entire Province. In the course of Time, these Extensive maps were found somehow wanting, and so the College of Cartographers evolved a Map of the Empire that was of the same Scale as the Empire and that coincided with it point for point. Less attentive to the Study of Cartography, succeeding Generations came to judge a map of such Magnitude cumbersome, and, not without Irreverence, they abandoned it to the Rigours of sun and Rain. In the western Deserts, tattered Fragments of the Map are still to be found, Sheltering an occasional Beast or beggar; in the whole Nation, no other relic is left of the Discipline of Geography.

From Travels of Praiseworthy Men (1658) by J. A. Suarez Miranda

The piece was written by Jorge Luis Borges and Adolfo Bioy Casares. English translation quoted from J. L. Borges, A Universal History of Infamy, Penguin Books, London, 1975.

Birght lights and big city

Matthew Hooper — Wed, 11 Aug 2010 20:31:31 +0000

"When I'm stuck in a day That's gray, And lonely, I just stick out my chin And Grin,
And Say, Oh The sun'll come out Tomorrow"

I'm not saying our CMDB's are everything we want them to be. I'm just saying they are everything we need them to be, today. Our monitoring infrastructure had 100,000's of lines of code to handle static relationships. Now, everything is more dynamic. Next, we are working on templatizing (it's a word to us) the demployments through our CMDB data schemes.

We are almost 100% open-source. (Except our patch management tool) All of this is reducing our workload, improving our ability to be nimble and responsive, and allowing us to leverage data across multiple groups through multiple shifts.

It's not about "Boys and their Toys". It's about improving services and mitigating risks. IT leaders role is to keep the balance and set direction so the team improves and matures, not roles backwards.

As for doing QA or DRP's - hey if you are going to just plug and play with your business asset's your certainly not worred about protecting and preserving the value of your IT assets. Until you hit a major failure and get canned for being reckless. But I guess there is always consulting, or maybe becoming an author...

" So ya gotta hang on 'Til tomorrow Come what may Tomorrow! Tomorrow! I love ya Tomorrow! You're always A day A way!"

5% Certificate

skeptic — Mon, 09 Aug 2010 21:26:43 +0000

Matt, I think we should have a 5% Certificate for those like your organisation who made it. Yes you will get value from the book.

"mapping Business communities to interfaces to application tiers, to infrastructure" "QA has them for testing priority and DR has them for priority restore" Oooh I wanna work where you work. Actually no I don't: there is a much much bigger constituency who regard what you just said in the same way i do - as a medieval peasant would have regarded descriptions of London: a wondrous place that I'd love to see one day. I'd be happy if all my clients had DR plans and QA in any form, let alone ones that mention services.

As another analogy, I feel like a social worker dealing with kids in a slum tenement who reads about a Manhattan counselor straightening out rich kids suffering from Excess Toys Syndrome.

Sorry but my work is here with my clients.

CMDB vs. Stuff

Matthew Hooper — Mon, 09 Aug 2010 20:16:44 +0000

Some of us are not immature in our ITSM operations.

Before "CMDB" became the True Religion of club fashion choice at ITSM conferences, many of us were already mapping Business communities to interfaces to application tiers, to infrastructure. We called it System Mapping. I first utilized 3-ring binders in a documented sequence of Systems\Apps\Servers\Network layers. These were frequently updated and kept in a library at the first entry point of the Centralized data center. Then after Y2k, we decentralized and puff went the value, up went the risk, and down went our service levels. It became quickly apparent to me that without relationship data and accurate records we were just trying to keep "Stuff" running. (See Section 4.3 of Service Taming Introduction to Real ITSM for proper definition of "Stuff").

Our CMS is so critical to our operation today that it is more crucial than our Service Desk or our Event Management system. Why? How? Because the Service Desk and Event Management system feed off of it for automation and utilize it as the single source of truth.

I think people who bash CMDB's do it justifiably, because most implementations I have seen start with the Asset discovery and work up. I have blogged and spoken for years that it should start from the vital business functions and build down. VBF"s are already documented - QA has them for testing priority and DR has them for priority restore. Plus, VBF's are what the users are complaining about at the Service Desk, so you have already documented for you which VBF's to start from and now all you have to do is associate critical application touch points.

Skep, Carlos and Glen owe you a commission. I'm now compelled to go buy this book.

Configuration - one service request at a time

ianclayton — Mon, 09 Aug 2010 15:37:03 +0000

Skep, Dave

I'm a CMDB skeptic for the mostpart - well from an uber CMDB perspective. In past lives I was very technical, working on black projects to design and develop automated operation software to turn out data center lights. Then came the clap-on, clap-off wonder and (joke). Looking back, its clear to me we work in federated configuration environments. The network and applications have their version of a CMDB they use to control their 'State'. What is missing today in most organizations is the equivalent of the US Constitution, crafted by the States, to assign specific responsibilities to a Federal role for a ruddy good reason - customer outcomes and satisfaction.

Most CMDB efforts are what I term inside-out, lacking a laser beam focus on those two c-words and the third - the customer. My approach has been, and remains, to go there - think outside-in, and walk in the shoes of a service request as it journeys across the organization. Along the way, collect vital information needed to document what atomic level elements of the (service) infrastructure as are needed. Frankly, sometimes all that is needed is a Google style query/search of the State's information.

As for the ITIL definition of a CMDB - it is meant to be a 'logical' representation. Unfortunately its a shiny object for some as I mentioned, the end goal, in the dream it magically results in a blueprint of the service infrastructure beneath a service. The plain truth is, most IT professionals do not know how to define a service from a customer perspective, and lack the marketing 101 skills to begin that process. So thats why I start with a customer interaction - a service encounter - the service request container.

I'll stop here as I may be stealing my own thunder from my next book Outside-In Service Management, but needless to say, its my opinion, somewhat sharing Skep's, that a CMDB as defined in ITIL and in the general consulting/vendor community - that a CMDB cannot be done, not so much because of the discovery and reconciliation challenges, or even the muddying of the waters by Cloud computing, but because most IT centric folks do not know how to define the mandatory level of configuration items - the services.

Equating Config Mgmt with CMDB

skeptic — Sat, 07 Aug 2010 02:24:00 +0000

David, I totally agree. In almost every process of ITIL, the books describe the process. Only in a couple of them do the books plunge into a technical solution, and no more so than Config Mgmt.

In some environments you can do good Config Management with a box of file cards. If we focused on the process (in the horribly broad sense of "process" used by ITIL) like we should, we could make great improvements in efficiency and effectiveness in many organisations without thinking about underlying technology. I call it "on-demand CMDB" or "a CMDB named Sue".

Then in some orgs we could make even more improvements with better tools.

And in some of those cases, those better tools might include a CMDB (there ARE other config tools: asset mgmt; analytical query and reporting tools...) the complexity of a CMDB would be worthwhile for the benefits it yielded. But not many. And in only some of those cases is it the BEST use of the available funds. About 5%-10% of large sites, apparently.

Most of the time when vendors and their customers and their parasitic analysts wax lyrical about the benefits of CMDB, they are actually talking about much simpler (and cheaper) asset management.

When you say "some effort to make Config. reference material available" some of that comes from better process and some from better tools but often quite basic tools.

But we're wasting our breath. People want to buy an instant answer off the shelf, and none more so than all those business and IT people who think buying software fixes problems. It doesn't. And it particularly doesn't fix problems when the software is complex to implement, populate and maintain, and is even more over-hyped and over-sold than the average software (which is really saying something!)

The vendors know customers want instant tech fixes, which is why they have no incentive to do the right thing and sell complex solutions that actually fix problems - they can make a fortune peddling boxes of disks on the drop-and-run principle. The SaaS vendors are no better - the only difference is how they charge for the instant fix that doesn't.

There's No Place In This World For ITIL Fundamentalism

David Ratcliffe — Fri, 06 Aug 2010 13:07:37 +0000

Skep, that's quite a review (lots of direct quotes) for someone who didn't get to the last page!

When I first began teaching ITIL Foundations - way back in 1996 - I used to explain the concept of Config. Mgt. and always say "But, of course, this is describing an ideal world - it's not possible yet. But once the tool vendors wake up to ITIL it will be." So much for that prediction, maybe that's why no one let's me train anymore.

I think one way to look at the opportunity for Config. might be to immediately discount the idea of an all singing, all dancing CMS/CMDB and instead remember the building blocks. The various inventory lists that (should) exist in any organization and see how we can re-purpose them for the benefit of some key activities in ITSM. Remember, we used to say that Config. Mgt. was a process that took inventories and added relationships between CIs and relationships to services. What you could strive for is something which doesn't have to end up as a fully "mature" CMDB/CMS as described in the ITIL books (which, as we know, is always a dangerous goal to set when not acknowledging the business benefit) but instead some set of references to help in support and Change Management and elsewhere. NOT a comprehensive list of every CI in the infrastructure, but some useful lists that can be used when we're dealing with high impact work. One of the interesting discussions in the old Foundations course was about the scope (width) and depth (detail) for the CMDB. That's what I'm talking about here, documenting the bits that provide the most value - and not being too sophisticated in the process.

So, for just one example, if there's any work (upgrade) to be done on any part of the infrastructure and the impact of it going wrong would be "high" - we at least have a quick reference to see which services would be affected thereby providing something of a "sanity check" first.

Another quick example, if the support folks are struggling to close an Incident then a reference to be able to help them see which components could be the cause (i.e. which key components relate to which services) could speed up the resolution.

So maybe some effort to make Config. reference material available can be justified, just as long as we don't spend a relative fortune on a new tool, or hire a Consultant to spend 6 months re-defining & documenting an "improved" process.

I think ITIL would have been well served in the early days if the scope of what was called Config. Mgt. was limited to this much more simplistic "this is what can be done now" approach. However, it would have been a very short book (even by the standards of ITIL V1 - typically 120-160 page books, remember?)

Maybe what I'm saying is MUCH too simplistic for some, but I believe this is exactly how we should be referring to ITIL. Not implementing what the books say chapter & verse, but taking the concepts and applying them in ways which show a business benefit that can be justified for the effort we put in.

Reading lots of commentary on the Inter-Web lately I just see way too much cynicism about ITIL and short, sharp, smart-ass shots. People criticizing ITIL for what it's not. And criticizing it because they take everything as a single, literal, definitive (whatever the right word is here) code of practice that can only be applied according to the word of the great ITIL god. There's no place in this world for ITIL fundamentalism. That ain't me. Sorry, I'm drifting off into another rant altogether here. Getting back to CMS/CMDB, maybe it's time for "Config. for Dummies". But, like I said, it would be a fairly short book.

Maybe "The CMDB Imperative" serves a useful purpose, though. More of a vision for the future rather than "try this now". We always need people to point the way. Prompting discussion and identifying opportunities for innovation. But now I'm dreaming!

I'm definitely interested in the "Anti-Gravity Levitation Device for Dummies" though.