Modeling a Manageable Service

Modeling a Manageable Service

An Archestra notebook.

© 2013 Malcolm Ryder / archestra

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.

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.

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.

The Organization of a ServiceOne 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.

Modeling ManagementThe 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 co-operative 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 ModelsA 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.

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.

Service Elements

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.

Element managed as an…

Type of Element Significance of Element’s presence is because it is …

EntityVirtual As If

Real As Is

ConstructionLogical As Prescribed

Physical As Able

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.)


Accountability of Service Elements

VIRTUAL(as if)

REAL(as is)

LOGICAL(as prescribed)

PHYSICAL(as able)

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.

EXISTS

OPERATES

PROVIDES

PERFORMS

(Form)

(Pur

pose

) © 2013 M

alcolm Ryder / archestra

Service Structure

(as if)

(as is)

(as prescribed) (as able)

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.

EXISTS

OPERATES

PROVIDES

PERFORMS

An Element in various Forms

VIRTUAL(as if)

REAL(as is)

LOGICAL(as prescribed)

PHYSICAL(as able)

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.

PRINT(exists)

IMAGE(operates)

PICTURE(provides)

PORTRAIT(performs) ©

2013 Malcolm

Ryder / archestra

Accountabilities 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.

Accountability Managed element’s role in service, regardless of form

Applicable management rules

Performance as if & as prescribed Method & impact

Operation as if & as able Function & method

Provision as is & as prescribedConfiguration & function

Existence as is & as able Asset & configuration

Construction

Entity

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.

© 2013 M

alcolm Ryder / archestra

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.

The hierarchy of “dependency” often proposed in infrastructure parallels the service “enablement” hierarchy, for the

same underlying reasons.

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.


Service EngineeringMany 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.

Why hierarchies?

Modeling Managed Enablement

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.

The structure of “enablement” that is designed in Operations parallels the

management accountabilities hierarchy, for the same underlying reasons and goal.

Configuration Model

Implementation Model

Deployment Model

Delivery ModelSERVICE

CAPABILITY

SYSTEM

DEVICE

CAPABILITY

SYSTEM

DEVICE

+

+

+

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.


Synchronized Models:rational, not technical

Public Transportation Routes

Typical Traffic Patterns

Commercially Strong Points-of-Sale

Network of Roads

Multiple models that are related to a shared goal may independently change. Synchronizing them means making sustainable dynamic connections

between the elements across models.

Model D

Model C

Model B

Model A

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.

Highway Dept. Svcs.

Transit Authority Svcs.

Police Svcs.

Business Svcs.

Model-based ManagementWith 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 DynamicsGiven 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 MapA “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.

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

Technology

Modeling a Manageable Service