Service Models are just like products: giving the wrong kind to the right person gets you nowhere fast.

1. Modeling a
Manageable Service
An Archestra notebook.
© 2013 Malcolm Ryder / archestra

2. Preface
• A “model” can be quite sketchy, or hyper-detailed, or anything in between.
The variations exist because of the different kinds of users who need the
design guidance that a model provides.
• Once a model exists, any consensus that it is reliable will contribute to the
general desire to make it available to more users. But in circulation, a
model always has the risk of being used by an audience it was not prepared
for, possibly confusing or misleading as a result.
• Making models safe for interpretation requires predicting the audience.
Conversely, the type of audience constrains how the model should
communicate. Service managers are a certain type of audience. Service
users are a different type of audience.
• Models are a basic tool of architecture. The following discussion is from an
architect’s perspective.

3. Why Model?
A model provides an intended design of whatever it represents. However, that
purpose does not dictate the level of detail that the model includes. This means
that we might always find things we know about that are omitted from a model.
Regardless, the model always has importance because it prescribes and
recommends. Things that contradict the prescription and recommendation are
intended to be excluded.
A model of a service is an important instrument for building a service or for
restoring one to its intended design. Therefore, a “manager’s” practical use of a
model is something that has reasonable limits.
In some cases, a given type of thing can be recognized and understood only
through a certain kind of description. For this reason, different kinds of models
exist to prescribe and recommend in different ways.

4. What Model?
Using the right kind of model is critical to managing correctly with it. But for any
one given service, there may be multiple different relevant models.
In all cases, it is important to understand that modeling the environment of a
service is not the same thing as modeling the service itself. Additionally, the
instantiation of a service (static) and the activity within a service (dynamic) are
related but not synonymous. Likewise, their respective models are not synonymous
but instead should be rationally aligned.
Managers who want to “trace” the alignment or misalignment very often want a
single model of the traceability. This inspires creating a hybrid of different models.
Hybrids should always be advertised as such.

5. The Organization of a Service
One of the ways that a “service” can be defined is as follows:
An implementation of enabling systems and processes, that allows their group configuration to
operate in a manner that “serves as” a capability needed by a user.
Then, when we consider that a “user” might be a person, a device, or some combination of persons
and devices, it becomes evident that the “user” of a service might sometimes be… another service.
For this reason, the fundamental understanding of “a service” accounts for its intention to either
provide capability or consume capability. The emphasis on the dynamics outweighs all other
perspectives on modeling the “organization” (structure) of the service.
Without this understanding, it is pointless to use the word “service” as the name for something.
Most descriptions of the service structure need to describe what is present that is doing the
providing and consuming within the defined service. Items are included in the description because
they do one or both of those things.
The scale and range of business management demands that services and their items are identifiable
at levels of abstraction that readily allow association to management responsibility. The necessary
level differs according to who is the responsible management party.

6. Modeling Management
The next key consideration about a service is how it becomes usable. We presume that its
usage is available because it is managed.
But the organization of the service may have multiple elements and variability within the
scope of its given purpose. This means that there may be multiple aspects to manage, and
in turn that the overall management itself is a co-operation of a variety of management
efforts.
Consequently, organizing the management is something that may require a model. A
management model for a service would guide the effort to assure that, through cooperative management, the key aspects of the service viability are accountable and will
remain so continuously.
It can be argued, from the user’s perspective, that without a management model, there is
little point to creating a structural model of the organization of the service, since reliance
on the service would be speculative.

7. The Main Problem with Models
A customer-oriented model will want to identify the particular aspects of the service that are
manageable for making the service viable and reliable.
• From the point of view of the service customer (buyer, user, consumer), the structural model of
the service exists specifically to identify what is being addressed according to the management
model.
But the effort to create service models has earned a notorious reputation for being non-standard,
inconsistent, and ephemeral. These problems mainly derive from confusion about how and why
depicted elements of the service are being defined and managed.
• Management confusion directly reflects an insufficient understanding of the material at hand.
The poor understanding is very often fueled by vocabularies that are misused or misinterpreted in
trying to create models.
• The vocabularies should attempt to identify the means, motives and opportunities for elements
of the service to appear and interact according to specified intentions.
• To help make the vocabulary sufficient for identifications and intentions, it is first necessary to
bring conceptual precision in definitions. Management models normally employ levels of
abstraction.

8. Models communicate abstractly
• An abstraction layer (or abstraction level, or a layer of abstraction) is a way of hiding the
implementation details of a particular set of functionality… The simplification provided by
a good abstraction layer allows for easy reuse by distilling a useful concept or metaphor
so that situations where it may be accurately applied can be quickly recognized. –
Wikipedia
• Different types of management use different abstractions.
• A model of a manageable service will communicate elements of the service that align to
the abstractions addressed by managers.
• For a service, the abstractions reflect the ways that requirements drive the design of the
service.
• The four essential requirements are that a service element should be as is, as
prescribed, as able, and as if. These qualifications provide the semantics that generate
the abstractions used in management.

9. Service Elements
The dynamics of a service – involving providers and consumers – feature the concept that roles are
interacting and that, as elements or parts of the service, various defined items are intentionally
executing the roles. All elements in a service begin with a conceptual definition of their distinctive
significance in the service. (The instantiation of elements in a service is a related but different issue.)
Element managed
as an…
Entity
Construction
© 2013 Malcolm Ryder / archestra
Type of Element Significance of Element’s
presence is because it is …
Virtual
As If
Real
As Is
Logical
As Prescribed
Physical
As Able
A massive amount of confusion
begins with mischaracterizing
the basic elements used to make
up a service.
The correct distinction of the
types of the elements is critical
because it predetermines how
they should be accounted for.

10. Accountability of Service Elements
(Form)
PHYSICAL
(as able)
VIRTUAL
(as if)
PERFORMS
OPERATES
REAL
(as is)
PROVIDES
EXISTS
© 2013 Malcolm Ryder / archestra
(Purpose)
LOGICAL
(as prescribed)
The core of the management
effort is the accountability of the
service elements. Through the
semantics of the forms and
purpose of the elements, we
discover that there are four
essential types of accountability
for parts in the service:
existence, provision, operation,
and performance. These four
are the abstractions in the
management model.

11. Service Structure
(as prescribed)
(as if)
(as is)
PERFORMS
PROVIDES
(as able)
OPERATES
EXISTS
As managers, we know that the four
accountabilities are related to each
other rationally. Something exists
in order to provide a behavior
usable in an operation intended to
perform per a user’s purpose.
This presents some significant
management logic: if we don’t get
the performance we need, it could
be that the underlying operation is
not adequately provided for by an
existing component.
The apparent hierarchy in that
situation reflects a typical
stratification of responsibilities for
management seen in organizations.

12. An Element in various Forms
VIRTUAL
(as if)
REAL
(as is)
PHYSICAL
(as able)
PORTRAIT
IMAGE
(performs)
(operates)
PICTURE
PRINT
(provides)
(exists)
© 2013 Malcolm Ryder / archestra
LOGICAL
(as prescribed)
Typically, artists and scientists are
familiar with the key distinctions in
accountability, and how it relates to
forms and what we expect them to do.
This is not coincidental: both artists and
scientists analyze and make things for a
living. They define different elements
with different kinds of accountability.
For example, we might find a paper with
marks on it (print). We might further
intend that the print should show
something identifiable (picture). The
object that we call “a picture” can also
stand in for the presence (image) of that
identifiable “something”, and we may
also employ the image as a specific way
of projecting the qualities that concern
us (portrait) about that thing.

13. A service part may have
a physical or logical
construction; with its
construction, the part
behaves as a virtual or
real entity. In a service,
the management of
construction matters
primarily for supporting
the management of
defined entities.
Accountabilities
Construction
Entity
Managed element’s role in Applicable
service, regardless of form management rules
Performance
as if & as prescribed
Method & impact
Operation
as if & as able
Function & method
Provision
as is & as prescribed
Configuration &
function
Existence
as is & as able
Asset & configuration
© 2013 Malcolm Ryder / archestra
Accountability
Management strata are abstractions
that have key conceptual distinctions.
But the “items” that fall under
management in each layer may appear
in a form (package) that is applicable in
more than one management layer.
For example, in the world of real
experience, a book can be used as a
doorstop, a box can be used as a seat, a
laptop can be used as a print server, and
a sound can be used as a key. A
software function acts as a supervisor,
and a clerk can be a monitor.
Meanwhile, a so-called “virtual”
machine is said to proxy a “physical”
one, although “virtual” is not actually
about form but about purpose.
Confusion about form and purpose is a
major cause of failed modeling.

14. Hierarchy of Abstraction / Layers of
Structure
The four distinctive management concerns
line up quite logically in a hierarchy
showing how elements together enable
the final effect desired by the user.
NOTE: A single element may include
accountability at every level of the
hierarchy. However, each level can have
elements that are defined and instantiated
only on that level and lower ones.
© 2013 Malcolm Ryder / archestra
The hierarchy of “dependency” often
proposed in infrastructure parallels the
service “enablement” hierarchy, for the
same underlying reasons.

15. Service Engineering
Why hierarchies?
Many attempts to model services think and diagram in terms of what is “causing”
effectiveness, as in causing the functions that are required as effects.
In the design of an enablement hierarchy, the attitude that most often predominates in the
management responsibility is engineering. In that attitude, “effectiveness” always has a
underpinning foundation, and the ability to make and manage underpinnings solves most of
the risks to effectiveness. Meanwhile, functions/effects vary in their level of specificity.
This leads to an effort to “roll up” lower-level functions into higher-level ones that are
required – or, to identify high-level functions that are requested and decompose them into
reliable lower-level constituent functions (dependencies). These models then go on to
illustrate the infrastructure items that instantiate the “build-up” of the functionalities.
Service customers share an interest in what is used to enable a service. But if they know the
service is managed, then they don’t need to know. The user’s perspective is usually more
like architecture than like engineering – the design of effects rather than of implementation.
This difference affects what kind of hierarchy diagrams make sense to users.

16. Modeling Managed Enablement
Using models, managers of a service can ask “How does it work”, and therefore they can ask “How does it NOT
work”. Knowing HOW it can not work helps to point out WHY in some instances it is not working for users.
Meanwhile, specializations in management tend to generate differing models.
SERVICE
Delivery Model
CAPABILITY
Deployment Model
Implementation Model
Configuration Model
Each type of management accountability can independently cover
service elements in its distinctively appropriate way. For any given type
of accountability, a model intends to guide the building of the service or
the restoration of the service to the intended design.
SYSTEM
DEVICE
+
+
+
CAPABILITY
SYSTEM
DEVICE
The structure of “enablement” that is
designed in Operations parallels the
management accountabilities hierarchy, for
the same underlying reasons and goal.
© 2013 Malcolm Ryder / archestra

17. Multiple models that are related to a shared goal
may independently change. Synchronizing them
means making sustainable dynamic connections
between the elements across models.
Synchronized Models:
rational, not technical
Business Svcs.
Police Svcs.
Transit Authority Svcs.
Highway Dept. Svcs.
Commercially Strong Points-of-Sale
Model A
Typical Traffic Patterns
Model B
Public Transportation Routes
Model C
Network of Roads
Model D
Rationally showing traceability requires appropriate levels of abstraction to be used. For example,
the above shows a hierarchy of services using other services – like what a business increasingly sees.

18. Model-based Management
With a service, the essence of the structure is dynamic; the modeling is about prescribing what is
doing the behaving and what influences the behaviors have.
The logic of the model is a standing set of rules governing defined roles that are goal-seeking.
Within the rules, manageable items acquire and release roles as they move about in time.
Combinations of managed items create formations that have group-behavior and group-generated
influence on other items and formations. Manageable items can be logical or physical constructions.
The constructions instantiate elements of the service.
With a service, each of the four key types of accountability – performance, operation, provision and
existence – brings rules for managing the service element in its role. From these rules and roles,
four different models of the service are derived.
In each case, a “baseline” model is a prescriptive design. Changes to the states represented in the
baseline would be of concern whenever they “break the rules”. Changes to the structures in the
baseline would be of concern if they do not satisfy the responsibility of the element’s role.
Management focuses on the accountability of states and structures, based on the prescription and
recommendation of models.

19. Modeling the Dynamics
Given the complexity of an IT environment, along with the frequency at which it is re-configured,
there is an increasingly obvious lesson about managing it for persistent services:
• making maps of the environment does not make sense unless it is done very frequently;
• and making movies of the behaviors in it is the only way to know whether the current state is
acceptable in the course of time.
By analogy, if you slow down the “movie” enough, you can look at more discrete occurrences and
patterns. It begins to resemble the tracking of a chess game. The game continually changes state,
but all changes are regulated, and positions have certain meanings at the moment. The entire
framework of managing the game is based on roles and rules.
The “model” for a game is not based on a snapshot of object deployments; it is based on a standing
set of rules governing logically defined roles that are goal-seeking. Within the rules, game pieces
acquire and release roles as they move about in time. Combinations of pieces create formations
that have group-behavior and group-generated influence on other pieces and formations.
Likewise, with a service, the essence of the structure is dynamic; and the modeling is about what is
doing the behaving and what influences the behaviors have.

20. Model, not Map
A “baseline” model of prescribed and recommended states and structures is also a plan; but it is a
blueprint, not a map.
Management should use the blueprint to plan forward. Usually, “forward” will mean intentionally
establishing something new, or restoring something to a mandated prior state.
Models should be helpful for indicating why things might be found in a map. But mapping should be
driven by exploration and discovery – an entirely separate effort. And, continual remapping should
be a supported activity.
Entity definitions in service models offer certain ways to classify discoveries for the purpose of
management. So, discovery findings should always be made available in a form appropriate for
comparisons to the models. This may mean that discoveries must be translated or transformed
prior to making comparisons. (For example, they might be categorized or correlated.)
When the results of remapping and comparisons reveal violations of rules and roles in the related
model, that finding should trigger reviews by managers. Issues accounted for in one model may or
may not require attention to the structures, states or issues in other models.

21. Keynotes
Overall, the effort to model a service needs to:
• Show what is manageable about the service structure, as well as what is in
the structure and why it is there
• Avoid substituting engineering for architecture
• Maintain awareness that models come in different types, and each
different type of model has a proper use
• Define “roles” to be present and managed as “the behavior of service
elements”
• Acknowledge and respect the difference between form and purpose
• Plan synchronizations of purpose that build the final effect
• Understand that maps are not substitutes for models