Who Needs a CMDB, Anyway?

 I am disturbed.

 Particularly about the amount of hype that surrounds the discipline and implementing technologies of configuration management.  There is much more hype here than there should be.   Shouldn't it be an unexciting, mature, ubiquitous process  baked in to IT already?  Apparently not, if the volume and tone of blogs like the IT Skeptic are any indicator.  Great stuff there.


Who needs a CMDB?  Anybody who will pay for one?  The Fortune 500?  Anyone with more than (pick a number) CIs?  Someone with a use case?  Somebody with a  big  honkin' reconciliation engine?  One could imagine  choosing any of these answers depending on one's background, ergo the hype.  


If you are a vendor or consultant, you may ask yourself "Is this is a rhetorical question?"  It's not.  Some feel  CMDBs generally have not provided the expected ROI and tend to discount their value, relegating them to toys for the rich or as unproven gadgets, insinuating poor choice of budget investment.  The good news:  people care deeply about finding the truth, on both sides.


What we call configuration management today in past practice has traditionally been implemented in disparate technologies intended to do something else, but did a piece of something .  Auto-discovery, asset/inventory/service management, application mapping.  These apps all do/did some configuration management-like things.  With emphasis placed on whatever the product that you were  familiar with did.  It follows that most people's opinions stem from  formative experiences with technology, scale and scalability, the kind of business demand present, and industry-specific  drivers such as  security or  regulations and standards.


This converging-but-still-disparate landscape has created a kind of configuration management tower of Babel:  how can we build anything if we don't speak the same language, agree on what a CMDB should be and do and for whom?


Let's not forget a primary CMDB contender, "no technology".  Configuration Management in sufficiently small shops is done by people, in people's heads.   It's very controversial what the limits of size and complexity are that require a configuration management tool.  There are  as many variables and forms for such an equation as there are human characteristics related to the competency.


However, while people (vs. a tool) can and do perform configuration management,  there is almost no shop whose business has not suffered to some degree at the hands of human error.   The corollary to this is that you won't see value in a CMDB until you've felt the wrong kind of heat.  If you've ever experienced costly downtime because of an outage caused by miscommunications in change management, then it may be a little easier to accept that you might have saved your business a bit of pain if you'd had something to help your change management left hand know what the right was doing.


For example:  Configuration management has always been done by Bill The Alpha Geek, and all the configuration data for the entire shop exists in Bill's head.  No serious outages have ever been correlated to Bill not being there one day, or having not known a particular fact, or having not had a good enough memory to never need to write anything down or put it in a computer.  Bill is not going to be a big fan of CMDB.


Now let's consider another persona, Bob, the Operations Director and Bill's Manager.  It's a medium-sized shop,  well under the fortune 1000, that has experienced rapid growth.   The current application infrastructure resembles a very complex, finely-tuned bowl of spaghetti, understood by only a few people in the company.  Historically Bob has depended on Bill for all the answers:   We need to upgrade our ERP app, what servers are part of ERP?  Bill knows.  What other apps and services does ERP depend on?  Ask Bill.  If I unplug the CIO's desktop, will ERP continue running?  Check with Bill.  If our second-hand Cisco 2600 finally craps out, will our ERP still be ok?  Riiiight. 


So if you're Bill, Bob is skipping without a rope.  And if you're Bob, Bill is empire-building.


But today, another server was added, so now there are 101 servers, pushing Bill over the edge.  There is now a non-zero chance of Bill forgetting something.  It's like the old pickup sticks game with a couple thousand sticks.


And you're telling me this shop can do it's configuration management with people?  Maybe with MENSA people or Marilyn Vos Savant or somebody.   But sooner or later, Bill's going to miss something and your online retail web site is going to go down, or maybe you can't collect money or manufacture your product for a day.  IT happens.


But isn't there a simpler solution than one of those hypey, expensive CMDBs?


Herein lies the distinction based on those formative experiences I mentioned earlier:   You can't appreciate the need for a CMDB unless you have truly experienced the onslaught of bad changes and angry application owners that result from not managing your configuration data properly.  Yes, you can do some spreadsheet kung fu.  But Configuration management is about more than just record-keeping.  It's about a programmatic approach, it's about comprehensive, quality data, always available, and secured.


The CMDB isn't extraordinarily sophisticated technology.  But does a few very powerful, fundamental things,  for everyone, all the time, consistently.  Best thing next to Bill, when he's awake and not on vacation.    And if CMDB saves you a day's worth of downtime over, say, a year, then there's probably some nice crunchy ROI in there.


What do you think?  Drop a comment and let us know!  To be continued...


Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Showing results for 
Search instead for 
Do you mean 
About the Author
Jody Roberts is a researcher, author, and customer advocate in the Product Foundation Services (PFS) group in HP Software. Jody has worked ...

Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.