• 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
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.
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.
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.
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
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.
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
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
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. –
• 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
• 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.
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
The apparent hierarchy in that
situation reflects a typical
stratification of responsibilities for
management seen in organizations.
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.
Multiple models that are related to a shared goal
may independently change. Synchronizing them
means making sustainable dynamic connections
between the elements across models.
rational, not technical
Transit Authority Svcs.
Highway Dept. Svcs.
Commercially Strong Points-of-Sale
Typical Traffic Patterns
Public Transportation Routes
Network of Roads
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.
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.
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.
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.
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
• 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