Integrated Service Management: didn’t we already do that?

A quick search-engine tour of I.T.-related management methodologies for business is a good way to provoke the nausea you get when riding a carousel while drunk.

As you’re searching, things keep spinning by, and although you notice that some things keep showing up again and again, you’re not really sure where you are when you see them, and you’re pretty sure you shouldn’t jump off at them until the spinning stops, but a lot of the rest of it is a blur.

Some find relief by getting on smaller carousels with RPMs that bring back fewer recurring things but bring them back at higher frequency. There’s a Lean carousel, an Agile carousel, a DevOps carousel… an ITSM carousel… They seem much more definitive, but then you don’t know what you’re missing from the others.

ITSM (I.T. Service Management) tends to still be the biggest carousel but is increasingly suspect as its circumference means carrying loads farther from its center, resulting in some creaking and wobbling that makes people nervous. Additionally, it carries a lot of what looks like over-emphasis on construction, with way many different moving parts required. A mantra of process integration has held it in place for decades, and as the flag bearer for ersatz managers of I.T. it encourages the question “isn’t service management already integrated?”

But unlike other groovy methodologies, ITSM didn’t have a manifesto to keep it out of the grind-to-a-halt paralysis of implementation details. It’s most powerful unifying concept — the central database for managing “configurations” (CMDB) — is ultimately perhaps the cold fusion reactor of IT. Nonetheless, ITSM is still the most tightly-coupled sharepoint of what has traditionally been the business concern with the cost/benefit ratio of IT infrastructure.

Some view the persistence of ITSM as proof that on some essential level it has always addressed the “Why” of management objectives even as the “How” was evolving in Darwinian fashion across relentless changes in technology itself and, in particular, technology’s ability to manage itself. Since managing IT seems nearly impossible without tools for process automation, every tool advance came with the suggestion that the techniques for doing management might also need to change — or at least should change. (By analogy, met any programmers using Assembly recently? How about Low-code?) Net: “doing” ITSM must procedurally change or die.

Back to those manifestos: your trusty search engine no doubt excavates the guiding concepts that tell us why newer management methods have occasionally erupted instead of just emerging. Generally, they each react against some set of circumstances that has come to be more intolerable than worthwhile. Just type in “<your favorite method> manifesto” and see for yourself.

What that does not necessarily do is give you the sense that these differing approaches even want to be integrated with each other, much less how. But it is not really that hard to imagine linking them together; mainly you have to get out of the weeds and climb up at least to forest-canopy level, if not spread wings and lift off for the most rational “Aha!” view. (Did it! https://bit.ly/2KHEqwU)

But if ITSM is itself just one of the four approaches that might get linked, then what is the meaning of the new trend of calling their linkage integrated service management?

This is a question that lends itself to a variety of justified answers, and here’s one for example.

“ITSM” is a subset of “Service Management” writ large, which also includes Business Service Management and let’s assume one or two other things as well. This story suggests that Lean, Agile, and DevOps are also flavors or “expressions” of Service Management — and rather than just being different beachballs in the same car trunk they are much more like different atoms in the same molecule. For those of you who passed chemistry, you know where this leads: a periodic table of the management elements for something called Service. So, we just need to know what it is about Service that (a.) needs management and (b.) is so darned important that it actually corrals systems, software, data, people and demand within one fence, and furthermore dictates the structure of their interactions (relationships).

Here’s another example justification.

The 4-pack of Lean, Agile, DevOps and ITSM reflect distinctive dimensions of Service Management. If you’ve created and used frameworks, you know where this is going. Each of these four occupies a “space” within a shared domain called Service, and each has its own driver that causes it to take up the range of space that it does. Even if the framework is generically simple, with a Why (fast, cheap, pretty) versus a What (means, motive, opportunity) or a Who (producer, provider, user), we’d expect that some approaches would be more influential than others at any given points in space.

But should we be worried about co-existence of approaches? Do we assume that the approaches will get in each other’s way if they are not integrated? What about a collective benefit instead of integration? And with the pace of change in technology, making the lifespans of any tool seem briefer and briefer, why is managing Service such a dominant perspective on I.T., instead of managing Transformation?

From at least one point of view, Transformation is far too difficult without Services. The point of a service is to make required capabilities available at necessary levels on time and on demand. The necessity for Transformation capabilities is not exclusive to businesses of a certain size or market, but the availability of capabilities is another matter, highly sensitive to sourcing. Since availability through sourcing can so easily be pressed by timing, transformation may dictate multi-sourcing, and the business issue at hand immediately becomes one of scoping each source and coordinating them, whether they are internal or external to the organization.

That line of thought takes us here: it is not the services that need to be integrated. It is the management that needs to be integrated.

The actual significance of the phrase “integrated service management” is that it points directly at strategy for business value. All strategy is about where you’re going to be and why you’re going to be there, for the purpose of intentionally pursuing a goal. All value is defined by the significance of a given distinction in a given context. And all services are operations for which the outputs are available on demand according to known agreements.

Integrated Service Management is, necessarily, the Business Value Management of Services. But the last thing we need is yet another acronym; and managing services for business value is not a new thing.

Meanwhile, what needs to be grasped is how any of the elements of producing an I.T.-based service contributes to the value(s) of the service when the service is employed against a business need.

© 2018 malcolm ryder / archestra research