A review of The CMDB Imperative
I didn't read The CMDB Imperative (that's the second time I started a review with that idea). I didn't read it because (a) you've got to be pretty keen on CMDBs to stick with the dry content (although the authors do as good as anyone could to make it palatable) and (b) because I fundamentally disagree with it, which dragged me down after a while. I got to about page 180 and then...
Nobody reads books any more. Not really READS them. Read Zen and the Art of Motorcycle Maintenance - one of the best books of the 20th Century. Most readers don't understand it - many don't finish it. It's HARD to read. I got it on the third attempt: I read about five pages a day on a beach in Thailand. I stopped, went back, re-read stuff, refused to go on if I was stuck, pondered, spent hours gazing out to sea mulling on it. Nowadays most folk read books like they read a magazine in the dentist's waiting room: mind elsewhere, flipping pages, dipping here and there. I can tell when they talk to me about my books :D Or they read like me: steadily from the start but never finishing. I must have a dozen books with page markers in them, and countless more with the page marker withdrawn and the book back on the shelf. No bandwidth, and no focus.
I wanted to properly read The CMDB Imperative but time, bandwidth and the dry nature of the content all defeated me. I got to about page 180 then I skipped, scanned and dipped. I've probably missed key points and misunderstood others. But I'm a 21st Century Digital Boy: superficial is good enough, impression trumps quality, and nobody checks anyway. It's not like you'll read this review any harder than I read the book. Bet you don't get past the YouTube... (go on! it's excellent!)
This is an impressive book: it is a comprehensive coverage of the topic... except for the dead elephant: CMDB can't be done. Regular readers will know that is my confrontational way of saying CMDB generally isn't a good business idea (see? Doesn't have quite the same cachet). The book coyly refers to the fact that vendors can't yet automate discovery of the key relationships to Service and other conceptual CIs (p35), then cheerfully forgets this fact and proceeds to talk about federation (over-selling the long-awaited DMTF standard just as everyone else does). Discovery doesn't do half of what you need and federation doesn't exist yet - but you'd be hard pressed to tell from this book.
The book's subtitle is "How to realize the dream and avoid the nightmares". The use of the word dream is appropriate: CMDB is a tech-geek's fantasy-fix to a people-and-process problem. This book no more delivers the dream than any other book promising such.
CMDB is apparently dead anyway. The world flung itself at that idea and already - even as the book was writ - it was becoming clear what a waste of time and money that was. Instead of considering whether this points to something fundamental, the authors neatly sidestep by embracing the ITIL V3 concept of CMS. CMDB didn't work but CMS will. One day. Once all the technology is there. Right.
On page 61 the book pushes the fundamental misapprehension about CMDB: "The reason you need [a CMDB] is because it is the only way that you will be able to truly understand the IT components that can impact a business service". Either over 90% of the world's organisations don't "truly understand the IT components that can impact a business service" since they don't currently have a CMDB, or that's bollocks.
They've been drinking the vendor Kool Aid. Take for example page 46: "Don't expect to totally shed reconciliation before 2012". Well, yes that's true, but 2022 would be truer.
The book does offer a counter view to vendor B.S. such as page 35: "Unfortunately the CMDB and CMDS vendors do not offer complete solutions that automate the discovery of services" and yet on page 54 "Automation is the key to simplifying ongoing CMDB/CMS maintenance [through] discovery tools".
Page 189 says "No vendor is yet able to deliver the CMS you need." Pretty clear. On page 152 "the technologies to support an enterprise-class CMS are still being worked on". On page 195 "In an ideal world the various tools involved in the CMS would plug together seamlessly. This world will be reality but not for many years". I was selling CMDB a decade ago: logical service views, auto-discovery, discovered relationships. Why are we still waiting? Because federation across multiple vendors is impossible without a far more advanced standard than the half-baked CMDBf which does nothing to address semantics or reconciliation, or a big programming effort by customers (page 192 "Most products do not work well together... so there won't likely be a clean and easy programming assignment that you can document and hand over to a programmer"). And CMDB can't be implemented cost effectively. There isn't really a market.
CMDB/CMS is a nirvana-technology, a vaporware that vendors wave in front of prospects in order to entice them into their more prosaic operations management and asset and service desk tools.
So the book does admit this stuff. But it is done casually, off-hand and down-played. If you can't buy a CMDB now, I'd have thought that issue was worthy of a chapter in its own right. This book is like How to Build an Anti-Gravity Levitation Platform. "If you built an Anti-Gravity Levitation Platform it would look like this... oh but you can't just yet because the technology isn't there. But it will be real soon, so let's look at the issues of safety railings..."
At the end I'm left with the impression of a learned book that covers all the available knowledge about CMDB, but nevertheless is biased towards the analyst's typical role of cheerleading a new innovation in the hope of drumming up a vendors' and analysts' market. It oversells the practicality, usefulness and most of all the ROI and VOI of CMDB. Worse than that, it plays down or ignores absolutely fundamental CMDB issues that everyone should be warned about, and it does nothing to make clear that CMDB is only a sensible proposition for a small number of extremely advanced and cashed-up IT organisations.
I found the book inspiring: I'm inspired to re-write my book The IT Skeptic Looks at CMDB as ITIL Without CMDB and take their book head on. Here's hoping I get the time and bandwidth and focus to do that - all the things I didn't have when I read The CMDB Imperative.
For those actually doing CMDB this book is an excellent resource. For those wondering about or considering CMDB it is dangerously one-sided. Read The IT Skeptic Looks at CMDB as well and average the two.
Made in New Zealand 
Comments
Of Exactitude in Science (and ITIL)
...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.
Nice excerpt. Thanks for
Nice excerpt. Thanks for sharing.
I wonder what Miranda would have thought of Google Maps.
wow
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.
CMDB in the real world
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
5% Club
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
There's No Place In This World For ITIL Fundamentalism
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.
Equating Config Mgmt with CMDB
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.
Configuration - one service request at a time
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.
CMDB vs. Stuff
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.
5% Certificate
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.
Birght lights and big city
"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!"
the $64 question
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.