of IT Services
Big Picture 2018
VALUE – the significance of a difference obtained in a given context
SERVICE – the outputs of a given ongoing operation, as made available
on demand under given terms
MANAGEMENT – the intentional control of variability in the potential
activity of a system, party or entity.
Services: Practices and Paradigms in the Big Picture
Despite superficial appearances, things have mostly not changed in the business
management of IT since the late ’90s.
The entire constellation of paradigms, models, and “best” practices in business
management of I.T. is simply the current state of how our attention to the big picture is
distributed and, at those locations, focused.
Lean is not the big picture. DevOps is not the big picture. ITSM is not the big picture. Agile
is not the big picture. Each of those (and others) exists for a distinctive reason that
becomes far more apparent when we ask the question, “what happens if we just remove
<whatever type of attention> from the picture?”
As the importance of a certain type of attention crystallizes at some point in the picture, it
may come to represent a principle that has value in a general sense rather than only in a
special or local case. It may become a proof-of-concept for potentially broader applicability
to the big picture. Concepts such as lean, agile, service orientation, modularity, and more
are now quickly “scaled up” to enterprise scope.
And with that proliferation of urgent and newer approaches, it is now routinely asked, “is
ITSM becoming obsolete?” Translated: is the problem that ITSM solves now the wrong
problem or the wrong way to solve it?
Service management futures
True, ITSM itself, despite the steady march of ITIL updates, has not gone through a change
comparable to a switch from keeping time with swiss gears & torque springs to Quartz & Solar … so
it may seem too conservative to keep up with the times.
But meanwhile, the reason new acronyms and paradigms sprout and then diverge, overlap or
compete with each other and with ITSM is because of this: management is multi-dimensional, but
most people either don’t learn management across multiple dimensions, or they aren’t held
responsible for it across multiple dimensions.
Our big picture, which has not changed since the 1990s, continues to identify (a.) managing
engineering as a strategic source of infrastructure; (b.) managing infrastructure as a platform for
service provision; and (c.) managing service as a product for business operations. While the logic of
hierarchical dependencies is explicit in that wording, it is nonetheless true that each of the three
changes somewhat independently of the other two, because it can. Over time, the aggregation and
alignment of changes looks like “evolution” – but the essential systemic structure of the
management model that includes them is (see following) the same as before.
Regardless of newer special perspectives or reference documentation, the issue is still to distinguish
what is a service, why it needs to be managed, and what it is about a service that gets manipulated
to satisfy that “why”.
ITSM’s own re-engineering probably is not about changing how to track time, but it probably is
about finding the quartz – the radical transformer – and using it appropriately to satisfy the why.
Any high-level “big” picture is at least a container and at best a map. It’s purpose is to include things
that must be included, within a form that facilitates finding and retrieving the content.
Using the big picture commonly ranges from identifying where one’s current positions most likely
are, to where one’s positions can be.
But big pictures are purposeful in themselves as they represent a perspective. The perspective is
generated from a point of view. We call this picture the “big” picture because the point of view is
from a high-enough level to include a broad scope within its perspective.
Our big picture explicitly names what it is looking for from its point of view. Using the picture also
includes further bringing relevant things into the picture.
In that way we understand that the picture is an exploration, but that it’s intent is to explain rather
than to define. And we understand that it is more concerned about what must be included than it is
about what else may not be so far.
At the business management level, ITSM transformation (or for that matter, its survival) is not really
about changing to some different purpose of management; rather, it is about managing with
different things, for the same purposes as before: delivery, access and use. The “quartz” is in the