Goodbye old friend. I won’t miss my old CMDB.
Many in the ITSM community as well as the IT community at large have embraced the concept of the CMDB only to have their hopes and dreams shattered as they tried to implement one in their worlds. There are hundreds of presentations and papers available that explain why they failed: Lack of process, scope creep, lack of business buy in, etc… are very common causes of failure… at least in these papers.
I however would like to point the finger at a different failure source – The vendors.
I know that this isn’t a popular view as these kind ladies and gentlemen have graciously tried to solve your CMDB problems by getting you to spend many thousands of dollars (sometimes millions of dollars) on software and consultants to implement their Utopian visions of IT Service Management bliss in your environments. They have painted pictures of a perfect world where if you buy their software, downtime will be reduced to near zero, your customers’ productivity rates will rise to unbelievable levels, your IT costs will evaporate and you, the IT guy or gal will be showered with absolute goodness from the business leaders who now declare in their quarterly meetings that “IT saved the day for us”; “Because of IT, we were able to not just meet but exceed every financial and regulatory goal that we had”
After these massive failures, many vendors (even some of the same ones) have tried to simply your CMDB lives… They’ve analyzed project data, they’ve formed focus groups and they have reached out to you, the customer to help come up with a better way. In many cases, this better way has been to simplify the CMDB, make it easy by adding in expensive auto-magical-discovery tools that always get it right. They’ve re-designed their databases to remove just about every shred of promised functionality and turn the CMDB into the very spreadsheets that you as the IT person already have too many of…albeit wrapped around a fancy web 2.0 interface.
Is this solving the problem or is this just an opportunity to start another sales cycle?
ITSM people are a very passionate bunch. They believe in the promise that a well run IT shop can not just help a company keep the lights on, IT can help move that company forward. Good IT can help shorten sales cycles, reduce development, manufacturing and logistics costs, and <gasp> make the average employee a little happier and a little more productive. These passionate IT folks are right. They can change the world but only if they embrace a little bit of change themselves or more to the point, force their vendors to change.
Forcing your vendors to change isn’t easy. Software development and support costs a fair amount of money. Marketing and sales cost a lot of money. It doesn’t matter if you’re selling software, hardware or perfume, radically changing your product costs a lot of money. Not just the development and engineering folks… there is a substantial cost in changing your message. How do you go to your customers who in many cases have spent millions with you and tell them that the things that they purchased last year weren’t really that good and as such, we redesigned it to actually work. The update is free to you however, we need to sell you a two year consulting project in order to move to this revolutionary new version. This is the conundrum of being in the software business.
I’ve been lucky enough to start a new job recently. I was kind of/sort of looking to change roles and had thought about a few companies that were established players in the ITSM market but the thought of learning, selling and more importantly, having to believe in a product set that didn’t really do what the marketing guys said it would do didn’t really sound that appealing to me. I have to really believe in something in order to ask someone to spend money on it. Not just a few bucks either, in a lot of cases we’re talking about several hundred thousand dollar investments that people were going to bet their reputations on in order to justify buying. I couldn’t do it.
I got a blast from the past phone call from a guy that I had worked with several years ago that I really respected. He had just taken a job at this new startup and brought up my name in a meeting as someone that might be a good fit for the company. I checked out some collateral and did a little market research and liked what I saw enough to want a follow on meeting. As it turned out, I knew the majority of the guys involved and more importantly, respected them.
We setup a dinner date and I continued doing my research. I showed up with a few questions and was promised a demo of the not yet released product. We caught up over dinner and talked about our families (we have kids that about the same ages), work history since the last time we were together and the normal type of stuff. Now it was demo time.
The guys walked me through the product at a local Starbucks. We went through all of the features and ways that folks would interact with the product and I must say, I was excited. I thought back to my days of installing servers, doing 48 hour DR exercises and trying to figure out how to try to “do more with less” and I thought wow, if I had this eight years ago I probably would have stayed in IT operations. It was that cool.
Here was a group of guys that had the same mistrust of vendors that I had, saw what was going on and thought that there had to be a better way. More importantly, they created a better way. Building a product from scratch, they had the opportunity to see what was working, what wasn’t working as well as taking a “how should it work’ approach and made something cool.
They took the ITIL V2/3 concept of Knowledge Management (which includes the CMDB) and built it. It’s not just a CMDB that has a tie into a knowledge base (stringing two existing products together), it’s built from the ground up around the concept of documenting, building and more importantly, sharing knowledge. When I saw the product I thought, here is a company that get’s it. They understand how people work and what people need to do their jobs. They understand what information is needed to make informed decisions concerning the business of IT.
Long live the CMDB! Sorry, I meant CMI, Sorry, I meant Knowledge Management.