Customer-centricity drives service management guidance because obtained value is why customers request and keep things. But as one result, the evolution of the guidance itself, such as with ITIL, struggles with justifications of what to include or exclude. In this piece, we take a look at ending that uncertainty.

1. Beyond Customer
Centricity
Back to Basics with Service Management

2. Services are resources intended for a user to conduct the user’s own intent.
Managing a resource is done, of course, for the benefit of a user.
IT Service is one type of service, and therefore the management of IT Service is a type
of resource management.
It follows, then, that IT Service Management (ITSM) has been evolving under the
perspective and priority of customer centricity. That attention is based on what the
customer recognizes as “value”.
However, the fact is, one service, when used by different customers, can yield
significantly different perceived value from one customer to the next.
And, the more complex the customer is, the more “value” is interpreted as eventual
impact on opportunity, instead of as actual current effectiveness on intent.
INTRO OVERVIEW

3. In reaction to that, resources are deemed to have failed if the current experience of
their usage is a perceived threat to opportunity.
That viewpoint is nearly always the basis of decisions on how to deal with behaviors of
a service.
It is not an “incorrect” perspective to have for business concerns.
But its natural predisposition is to allow mostly a combination of optimism (before the
fact) and aggressive but reactive risk containment (after the fact) -- an influence on
management practice standards that explains actual adoption of practice to date.
Despite important changes over the years in how ITIL organizes “best practices”
guidance for ITSM, the processes most often adopted have consistently been, by a
wide margin, about managing incidents, problems and changes – that is, about what’s
wrong, what might be wrong, and what could go wrong. The remainder of ITIL’s
management processes – roughly ¾ of the set – remain on a plateau of far lower
adoption rates.
INTRO OVERVIEW (Con’d.)

4. Again, services are resources for a user to conduct the user’s own intent. Managing a
resource is done for the benefit of a user. But what gets done by management?
The business management of service utilization comprises the acquisition and further
disposition of services as resources retained versus recognized value. Resource
providers are acutely aware of that. But resource management is not merely about
“relative” value to the user.
Resources are inherently valuable to the extent that we know how and when they will
make a difference that we want them to make. The prime objective of managing any
resource is to make it productive when it is applied. The point of services is that they
are offered with a predefined benefit.
ITSM therefore must continue to evolve by retaining focus, per that objective, on how
any IT service can have value at each stage of its lifecycle from conception to
realization, as compared continually to current business needs. The probability of that
value is rooted in the production of the service itself, making that production the
central issue to define and articulate as the subject matter of managing the service.
INTRO OVERVIEW (Con’d.)

5. Business Alignment

6. Resource Value
Management
Focus
Concern
Business
Manager
Utilization impact
versus plan
Probability of
impact
Obtain and
employ
Service
Manager
Predefined result
Assurance of
designed
capability
Produce and
provide
Value Matrix of Service as a Resource
©2018 Malcolm Ryder / Archestra Research

7. AS NEEDED AS REQUIREDAS IS
WHAT MATTERS
The desired impact, fitness-to-
purpose, and sustainability of
what is chosen to use; with
timeliness vs. priorities that
may change.
The terms on which the
selection and use are
practically possible and
acceptable, for the expected
affected parties.
The current state reality of
utilities, facilities and
systems: what gets used, how
it is available, and what keeps
it working.
PROBLEM
Unrecognized, chronic, or unattended lack of alignment between As Is, As Needed and As
Required. In theory, through pre-fabrication, services simplify and assure the business user of
getting “aligned” capability. In fact, usually for customization or adaptation goals, businesses try to
control aspects of service, in ways that are counteractive or insufficient for retaining alignment. As
a correction, much of what currently appears to be new solutions, innovations or revolutions in I.T.
practices are pursuing the business adjustment to the need for prioritizing coherent production.

8. AS NEEDED
AS REQUIREDAS IS
Design
Service Strategy: Responsibilities for Business Alignment
©2018 Malcolm Ryder / Archestra Research

9. AS NEEDED
AS REQUIREDAS IS
Design
ACCOUNTABILITY TO BUSINESS CAPABILITY
Continuity and Reliability in
current circumstances, from:
• Methods
• Policies
• Constraints
Value, risks and impacts
rendered through:
• Features
• Tolerances
• Specifications
• Objectives
• Models
• Limits
Relevance and
Applicability, via: ©2018 Malcolm Ryder / Archestra Research

10. Service Definition

11. OPERATIONAL ELEMENTS OF SERVICE
TECHNOLOGY
as an operational element
ACTIVITY
as an operational element
ORGANIZATIONS
as an operational element
Generally recognized as
Automation
Generally recognized as
Process
Generally recognized as
Specialty Labor
Every “service” is an (a.) ongoing operation having (b.) recognized outputs that are (c.) available on demand
under known and agreed terms. An “operation” is a controlled active function that creates a measurable
intended result. For obtaining a ready-to-use service, several different types of elements are used individually or
in combinations to make up an operation.
Example of enabled service:
Computing ShippingTeaching
As seen here, I.T. is not the only type of element, and various types of service can be enabled. A service
operation can be entirely composed of I.T. , or can include some I.T., or include none.
Regardless, the same logic of construction applies to composing an operation from any mix of element types...

12. CONSTRUCTING SERVICE OPERATION
TECHNOLOGY
e.g. Automation
ACTIVITY
e.g. Process
ORGANIZATIONS
e.g. Specialty Labor
The same persistently distinct structural factors are found in the underlying operation of any chosen service.
For example, when designed, the operational integrity of any provided service always includes these factors:
• systematic procedures (e.g. tasks),
• a known platform for that execution (e.g. environment or facility),
• and predetermined components whose interactions compose capability (functions).
Those structural factors apply to any type of operational element(s) that gets used as a service, such as:
Unfortunately, as each structural factor (procedure, platform, component, etc.) is essentially a variable, most
businesses typically treat them (before selection) as “user options” -- and not enough as existing
“dependencies” of the elements of operation.
In contrast, because the variations of a service’s behavior are predisposed by its underlying operation’s
construction, management of a service must logically relate to how the service is produced from those
dependencies.

13. As part of business strategy, businesses have been coached to manage for “delivery” of service,
but delivery is simply (no more no less) a status of a business expectation about fulfillment of a
request or contract. This makes sense in the perspective of being “customer centric”; but the
proper focus of service management, which must align the As Is to the As Needed, is production.
Obviously, use of the service must start with a clear and defensible argument for service
adoption, which includes the way that service utilization fits into the larger context of supporting
business performance. But this adoption is a responsibility of business management, regardless
of the particular service.
Service management is responsible for the support and awareness of how the given service will
benefit the business in real time. After all, even a highly successful service may be discontinued if
the business performance or business strategy changes. The primary responsibility of service
management does not change if the business changes.
“Service management” must recognize, understand, and guide:
• how production instantiates …
• the variable factors of …
• the operational construction of the defined service.
PRODUCTION-CENTRIC MANAGEMENT

14. Hierarchy of variable factors in the construction of the service operation
Demand Interface
Operational Outputs
Process of Operation
System of Process
Infrastructure of System
Deployment of Infrastructure
Component of Deployment
Development of Component
Sourcing of Development
Each factor is independently
variable, with its details
deciding what form of it is in
use, when, where and how.
Whatever those results are,
the given factor is then an
underpinning of the one
above it, being both an
enabler and a constraint.
Even when individual factors
go through changes of their
details, factors do not merge
or replace each other, and the
logic of the hierarchy does not
change.
Because the factors will
influence each other, those
influences must be visible
and intentional in order to
create sustainable integrity
in the operation provided as
an on-demand service.
An increasing emphasis on
producing relevant,
sustainable and compatible
factors in meaningful
timeframes accounts for why
Lean, DevOps, Agile, and
most other newer “build”
practices are so important
and notably foundational,
not just “integrations”.
©2018 Malcolm Ryder / Archestra Research

15. The representation of IT Service production is included in what follows. This representation
emphasizes its accountability to the logically distinct factors of operational construction that apply
to any service (whether I.T. service or not).
A hierarchy of factors expresses dependencies in the underlying operation of a provided service.
In the hierarchy, each factor persists as a distinct factor even if its immediate details go through
modifications. There is tension between why modifications occur and what results are acceptable.
SERVICE PRODUCTION
Management
& Governance
Production
& Performance
Variable
Service Dependencies
Demand Interface
Operational Outputs
Catalog Support
On any level in the hierarchy, the key factors have corresponding factors in management and in
production. Operational construction sets the POV used by management on production.
To represent correspondences of management and production at a given level, we have horizontally
positioned their respective factors approximate to the operational construction factors at that level.

16. Management
& Governance
Production
& Performance
Nine Variable
Service Dependencies
Demand Interface
Operational Outputs
Process of Operation
System of Process
Infrastructure of System
Deployment of Infrastructure
Component of Deployment
Development of Component
Sourcing of Development
Catalog
Capability
Capacity
Availability
Implementation
Quality
Resource
Maintenance
Support
Architecture
Change
Release
Configuration
Asset
Project
Security
©2018 Malcolm Ryder / Archestra Research

17. Management itself is a distinct business function, responsible for bringing a higher probability of
desired correspondence between probable cause and actual effect.
The more that “cause” is variable, the more management needs to be able to determine and
affect the “internal” logic that applies to operations.
The overall practice model covered above is that Production should be Design-centered, and that
Management should be Production-centered.
This model accounts for the logical evolution of the business (User’s) understanding of how
services as resources should be enablers of business capability and agility.
ITSM’s continuing evolution as practice is not about “increasing the value” of service to the
customer. Instead it is about increasing the assurance of the service’s predefined offer of effect,
which in turn makes the service easier for the business to recognize, assess, select, and deploy
according to plans and needs.
FINAL OVERVIEW

18. Archestra notebooks compile and organize decades of in-the-field empirical findings. The notes offer explanations of why things
are included, excluded, or can happen in certain ways or to certain effects. The descriptions are determined mainly from the
perspective of strategy and architecture. They comment on, and navigate between, the motives and potentials that predetermine
the decisions and shapes of activity as discussed in the notes. As ongoing research, all notebooks are subject to change.
©2018 Malcolm Ryder / Archestra Research
©2018 Malcolm Ryder / Archestra Research
www.archestra.com
mryder@archestra.com