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.