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.

It was inspired by a rather nasty line in a novel my one of my favorite writers, Milan Kundera, translated from the Czech—“Nothing is more useless than trying to explain a new idea to idiots.” Feeling this was humorously appropriate to many ongoing dialogs endured by people trying to change the way things are to the way things ought to be– I was going to council patience — in something of a self help mode directed in part of course at myself.

My first step was to look at ITIL’s notion of “configuration management “and the many (so many!) roles associated with it  as both of guidance and encouragement and an absurdist form of purgatory.  It was triggered by a vendor briefing with a set of powerful options targeted at the so-called “configuration manager.”   I mentioned that while I had spoken to many people with that title- -who often shouldered a heroic form of evangelism across their organizations—they typically came from other skill sets with very defined, tangible interests – e.g. architects from Infrastructure and Architecture Services, or in some cases more executive roles with strong cross-domain and communication skills.

When I opened ITIL’s “Service Transition” to revisit role definitions, however, I was stopped in my tracks.  I was reminded once again of why there is such a love/hate relationship with ITIL—and why it is, in its own words, such an excellent “departure point,” and so often such a poor endgame.

ITIL’s “Service Transition” meticulously lists and spells out service asset manager, configuration manager, configuration analyst, configuration administration/librarian, CMS/tools administration and change manager– as just some discrete roles (implying separate individuals) not to mention other discrete roles such as performance and risk evaluation manager and service test manager ad infinitum.

Reading through the list of these responsibilities is, on the one hand, an excellent way to codify process requirements and break out steps in terms of managing change.  On the other hand, when viewed as separate protagonists in a Hollywood cast of thousands, these “roles” could easily create such a massive bureaucracy that nothing could ever get done.  (One of the telling verbs in, for instance, the Configuration Manager’s role is “agrees”— meaning presumably that he or she better not disagree or else there could be hell to pay.)

Needless to say, even in large companies, these roles tend to be collapsed into generative functions with architectural skills, coordination functions with good communications and process skills, and administrative functions—which only makes sense.  And in many smaller enterprises, even these can be collapsed into one tired, overworked superstar—almost all of whom teach me something new every time I speak with them.

But aside from the massiveness of this ghostly bureaucracy- there is something fundamentally wrong with the language and concepts in ITIL when it comes to “configuration management” in my opinion.  And that is – it lives at a level of haunting abstraction without consistently reflecting the fact that there are hard and fast skill sets, often with unique domain expertise requirements— needed to make any of this meaningful.   The processes of configuration, release and change management means nothing without strong architectural skills and a tangible awareness of application or systems, or network design points.

And this gets to ITIL’s term “configuration management” and the notion that it’s a discrete discipline in itself.   In my experience, it isn’t.  Rather, it is a disciplined “mindset” shared across a team of individuals who realize the need to understand, capture, model and optimize physical and logical interdependencies in support of desirable service outcomes.  The CMDB and CMS emerge when leadership is given to this “mindset”—once again usually by someone with strong architectural and communication skills armed with administrative support (e.g. database skills) and executive backing.

So what about mental health in facing all the very human and political obstacles surrounding the above?

ITIL can be part of the cure—if taken as a reference – or part of the problem in my opinion—if taken too literally.   One has to be glad it’s there because there is tremendous insight captured in its peculiar and sometimes foreign language.  But it won’t replace, for instance, Milan Kundera or other outside-the-box thinkers who keep a sense of humor and a deep understanding of human futility in the forefront of how they write and think.

Which makes me wonder what ITIL must be like in its original Czech.

One of the worst culprits is of course the term “CMDB” which I like to compare to ‘The Holy Roman Empire” – which as H.G. Wells pointed out was neither “holy” nor “Roman” nor an “Empire.”  Well, the CMDB is not about anyone but ITIL’s definition of “configuration management” and in the end, it isn’t, or shouldn’t be, understood as a physical database, either.  If I could rename it, I would call it the “Reconciled Contextual Management System”   (RCMS)… and I noticed that ITIL v3 moved a step in this direction with its CMS.   In other words, it’s a system for reconciling different sources of information to support multiple constituencies in executing on virtually all IT-related processes.

“Run book Automation” is another—somewhat perplexing term, especially as it gets applied to a unifying system for automation linking various technologies from active configuration (or release) management, to workflow, to workload automation, to service request automation  – in a cohesive manner.  This is way beyond the roots of run book, which is why EMA likes to call it “IT Process Automation”—in itself albeit a bit vague.

“Dashboards” or “Executive Dashboards” or “Service Management Dashboards,”  or “Dashboard Analytics” as a “term set” is another source of potential confusion.  We all had dashboards back in the Middle Ages with pictures of unicorns (well maybe not those) – so what’s new?  The new notion here is something closely tied to an advanced data gathering and analytic system that provides powerful, constituency-relevant information.   But the term “dashboard” does little to truly convey all that.

There are plenty of other terms with conflicted meanings – but I picked these three for a reason.

They are all points of integration.

And ideally, they are all part of the same system – maybe, say, akin to the Service Knowledge Management System (SKMS) in ITIL v3.

The confusion comes in large part from history, but it also comes from the way products are brought to market.  People generally want to buy “things” and vendors like to oblige.  But none of these three capabilities are really things to buy so much as architectural foundations for enabling new and better ways of working.

Analysts often make this “thing” problem worse by seeking to define hard and fast boundaries around discrete markets which they can “own” as well, from a sort of IP perspective. The result is a lot of linear thinking around a non-linear problem… or perhaps more graphically, like trying to put an ocean into a wooden frame optimized for a sandbox.

All three points of integration have human, process and technology implications.   And even viewed in this last vein, they really aren’t products so much as architectural enablers.

We as an industry haven’t done a good job giving this transition away from product and towards architecture much freshness from a naming perspective – often with sub optimal, (comic and tragic) results in real deployments.  Cloud is changing this a little—but watch the fancy footwork as everyone has a magic box, figuratively or literally, to help their customers in their journey to the cloud.

Since points of integration are the central focus for my practice area, I witness this confusion on a daily basis.  I don’t have a magic wand, but I’m always looking.  And as for naming – I’m open to suggestions.