Do You Have a "Data Center"?

If your IT environment is big enough to call it a "Data Center", I think you're big enough to need a CMDB.


 


I decided to write a follow-up to my post from last week which discussed the controversy around who needs a CMDB.  The gist of one argument was around what size IT environment needs how much and what kind of configuration management processes and tools.


 


There are many opinions on this.  And they're all of course based on lots of experience and customers.  But sadly, not a lot of actual scientific research (Here is an article on some older but actual scientific research).  So a disconnect remains.  Here are some of the opinions:



  • Only enterprise -sized IT needs a CMDB.  Everybody else can do it in their heads.

  • Config management is a side job of all the other ITSM products.   It's a slice of process and integration between every service transition.  You don't really need any code.

  • ITIL got it wrong.  "Config management" is really a function of service management and it's friends.  The help desk has a database and it gets the job done.   The asset manager does discovery.  Not much more.

  • Change Control is the biggest part of configuration management, so it's a one-trick pony.  Nothing else delivers any ROI.

  • Only certain use cases require more formal configuration management.  Most don't.  An easement of sorts of the Change Control camp.

  • Configuration management is a valid discipline, but it can be done with far simpler and cheaper tools like spreadsheets.  Desktop-based or chair-based solutions are all most people need.

  • Even a small IT organization has a large volume of configuration changes.  Here is an article from someone who understands.

  • The "Pink Floyd" approach:  IT does configuration management by pouring distrust upon anything done, thereby exposing every weakness, no matter how carefully hidden by the IT staff.  The CMDB is built on fear.  Popular with government.  Expensive, but ruthlessly effective.  This one isn't an "opinion" per se, but it's definitely a confirmed approach.  With love to all my federal  friends of course!


 


While no one solution fits all, "no solution" fits no one.    Pretty much everyone needs and is doing configuration management, but not everyone calls it that or knows that's what they're doing.   So whether or not you know it,  whatever you call it, you're doing a good bit of configuration management if your IT environment is big enough to call it a "Data Center".


 


Is this a good example of configuration management?


 


Consumer:  "Who's on PVALX762W?"


Provider: "Email."


 


If you have a "data center", eventually, this doesn't work.  The simplistic question above is realistic; however, in practice the answer can range from a simple answer to one with a few thousand components.  Even for a data center with maybe 100 servers, of which there are many thousands - it is impossible to simultaneously 1) grow and change normally 2)  maintain SLAs and 3) do without a programmatic approach to configuration management.  ROI only comes after investment, and ROI can't be estimated very well until you have experience, which is difficult to obtain before investment.


 


So, spreadsheets, part-time products, process-only solutions, and that leading contender "no technology" cut it less and less as we understand what config management is really doing for  IT.  A CMDB doesn't have to be a Big Fabulous Deal.  It can help a three-closet "data center" as well.


 


Tell me if I've touched any nerves, begged any questions, or have posited any other logical phallacies.  Let's have some of those controversial opinions.  Please talk to us.  Thanks!


 

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.
Search
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 ...
Featured


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.