On the one hand, many in the industry have begun to dismiss the CMDB as well past its prime, at least in terms of industry hype and attention. For this rather significant population, the CMDB has evolved into a complex and demanding data store with tangible but difficult-to-justify benefits, with questionable relationships to cloud computing and other more dynamic technologies and trends.
On the other hand, there have been some significant improvements over the last three to four years.
Most notably:
* Improvements in deployment, administration and ease-of-use are real and significant -- although there’s still a long way to go.
* Discovery solutions, including application dependency mapping capabilities, are becoming “run-time” aware in support of cloud, VMotion and performance management requirements.
* CMDBs are being used more and more effectively not just as a single state – view of “what’s true,” but as a platform for analysis and decision support. In some cases with support for “future” or planned states as well as past states through integrations with capacity analytics.
* The evolution of “Service Models” are extending the reach of the CMDB to participate in a truly Operational system of value– something akin to ITIL’s notion of a CMS, or SKMS.
Unfortunately, the combined acronym CMDB/CMS does little more than raise a question. What is it we’re really talking about? A physical data store? A logical model? Or an entire “system” of solutions federated to support a more contextual approach to service management. And while EMA has always argued (even before ITIL introduced the notion of the CMS) that this “federated system” was really the core idea—the word “system” itself is an ambivalent one.
The truth is, however, that the industry really is at a turning point in this CMDB/CMS question mark, and that cloud computing is actually helping to drive the requirements for a contextually oriented service management system forward. However to achieve the full value of what I will call for now the “intelligent service model” a number of things still remain to be done.
• The industry as a whole must more aggressively decouple the logical and extensible service model itself from its physical database implementation.
• The service model should also play a role as a kind of linking or pointer system based on trusted source and CI attributes for multi-brand management investments. This is most visible today in the service performance or APM arena, where many multiple monitoring solutions from different companies need to be brought together as resources in what some vendors are calling a PMDB.
• As a corollary the model must also be dynamic enough to support either Real-Time or Run-Time requirements
• As may be obvious, the “intelligent service model” is also closely linked to Application Discovery and Dependency Mapping solutions which are central in keeping the model current and relevant.
• Finally, for this “intelligent service model” to succeed, its administration must become more facile, lightweight and easily extended than is generally possible today. Freeing it from some of the more daunting challenges of data normalization required for analysis and reporting across a single data store—should be a help. And relatively new implementations of Web Services, Web 2.0, and mashups, as well as advances in analytics, discovery, and scalability via cloud computing are all contributing to some forward progress.
Cloud: Friend or Foe?
Many in the industry tend to see the CMDB in the rear view mirror -- in terms of past failures and early stage technology offerings, and cloud as a future direction to liberate them from the past (and sadly still present) agonies of many CMDB/CMS deployments.
However, EMA data from December 2011, IT organizations with CMDBs deployed in part to support cloud-related initiatives were categorically more mature and effective in assimilating cloud technologies—both internal and external -- in support of the delivery of critical business services. Indeed little could be more accommodating to the assimilation of cloud than an “intelligent service model” that could capture and articulate external and internal, logical and physical interdependencies. Or a model that can—through its libraries of reusable application and infrastructure components and automation routines —enable the blueprinting, and automated provisioning so critical to cloud.
Antecedents
I would be lying if I claimed that all this has been a result of EMA research, analysis and consulting on CMDBs since 2005. While this data has often been encouraging and supportive of the “intelligent service model” vision -- sometimes surprisingly so -- the idea actually has other roots. Roots quite outside of ITIL.
The historical antecedents, and indeed the term “intelligent service model” itself, come from work done in the late 90s with an SNMP-based service management platform and its largely European partners. “Intelligent modeling” evolved then as a kind of logical/physical topology with advanced object modeling to associate business impacts and outcomes with critical services on the one hand, and physical interdependencies across the application/infrastructure, on the other hand. Successful implementations were most visible in large financial services organizations and telecommunications providers.
As such I admit that this approach is perhaps most easily grasped not by traditional data center thinking which has always been more componentized and fragmented, but by the most progressive leaders in the “network war room” where physical, logical and business interdependencies needed to be brought together with some level of cohesion. It is a bloodstream approach not a dissection of muscle tissue.
And it might be ironic, or perhaps even poetic justice, if the center of gravity in the service management industry could once again return to the “Service War Room” (“Operations Bridge?”) where perhaps the two most critical points of reference become the CMDB (or federated CMDBs) with application dependency mapping, on the one hand, and User Experience Analytics -- to evaluate not only service performance, but all the dimensions of delivered services as they impact business outcomes, on the other.
Related Links:
