Sometimes… OK most of the time … the terms and words we use for “things” in service management are in themselves landmines.
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.
Related Links:
