When Thinking CMS remember “Location, Location, Location”

The other day I presented to a customer that had purchased HP Discovery and Dependency Mapping software.  This customer was interested in understanding HP’s direction relative to the concept of a Configuration Management System (CMS).  My discussion with this customer focused on how HP was addressing the data needs of IT operational domains ranging from application performance and availability management, to configuration and change management to IT process automation for server and network elements.  From a product perspective HP’s focus in this area has been and remains providing a platform that delivers configuration item data, service context and federated data that can be related to those two items to consuming solutions across IT.


Our conversation eventually and rather inevitably turned to what was the best strategy to achieve such a grand vision.  The answer is surprisingly simple at one level yet remarkably difficult to do in practice.  Like the old adage, location, location, location used to talk about buying real estate, the answer to building a comprehensive CMS that works as promised and stands the test of time requires a laser focus on use cases, use cases, use cases.   


I’ll return to this idea after a brief detour to look at the origin of today’s CMS Initiatives and how many of those early ancestors went wrong.


 “Origins of Today’s CMS Initiatives”


Modern CMS initiatives have two main lineages.  The first and best known are CMDB efforts that were launched in the wake of ITIL v2.  Many if not most of these early efforts failed (or at least fell far short of expectations).  The primary reason was a lack of a crisp focus on what problems were going to be solved and in what order.  Companies sought to create a “master” database with all configurations representing all infrastructures across the whole of the enterprise.  While the CMDB technologies used in these early efforts were immature and had some  technical limitations, most of these efforts didn’t fail because of technology.  They failed due to a lack of clarity around what the end game was.


The second major ancestor of today’s CMS efforts is dependency mapping.  Many of the early adopters of dependency mapping embraced this technology for reasons having little to do with how these capabilities are primarily used today; to support ongoing IT operations.  Instead, most of the early adopters of this technology were interested in dependency mapping as a means of supporting some form of application infrastructure reengineering.


Why?  Well during periods of rapid business expansion the IT infrastructure at many companies had grown substantially and no one had a handle on what existed and how it worked together to deliver IT services.  As a result many companies found themselves unable to effectively take on new IT initiatives focused on reducing the infrastructure footprint, reign in runaway server and network admin costs, or effectively take advantage of new virtualization capabilities.  These organizations lacked a clear understanding of what was the starting point.  As a result many of these organizations embraced dependency mapping as a means to generating this understanding. 


For these companies using this information for ongoing management to support application performance and availability, change management, or IT process automation was not the focus.  As a result little emphasis was placed on consuming IT processes and the integrations with the applications that support these processes.  Like early failed CMDB efforts many companies stumbled when they first tried to apply dependency mapping to the needs of ongoing IT operations.  Like early CMDB efforts the reason these initiatives failed (or at least did not deliver as much value as expected) was that they lacked focus.  


Many companies when first employing dependency mapping would attempt to discover everything before having clear use cases of what data was needed to support what IT processes.   Since there were no clear consumers for the data many of these efforts either lacked or failed to sustain sponsorship and consequently withered on the vine.   In my next post I’ll take a look at how these two independent branches have come together to be the foundation of the current crop of enterprise CMS initiatives and how these initiatives face the same challenge that plagued their technology antecedents.

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