Business Service Configurations

Business Service Configurations

How Business Sees Meaning In Configurations

Archestra notebooks compile and organize decades of in-the-field empirical findings, to offer explanations of why things happened or can happen in certain ways or to certain effects. The descriptions

are determined mainly from the perspective of strategy and architecture, to comment on and navigate between the motives and potentials that predetermine the decisions and shapes of activity as

discussed in the notes. All notebooks are subject to change.

©2016 Malcolm Ryder / Archestra Research

The Point of Diminishing Returns

A business increasingly has to get things done using things it didn’t make, provided from external sources it does not control.

At the same time it usually has a culture of risk prevention that is enforced in what it makes itself, for its own use or use by customers and partners.

For management of risks in operations, the business needs information that explains whysomething behaves in the business the way that it does.

But that is not the same as the information that explains how something works.

When something does not work, the need is to know if the why is because of the how.

If the link between the how and the why cannot be openly clarified, then who cares about how much detailed data there is on either side?

What’s necessary is someplace dependable to get that clarification, on demand.

The more variable the data is on each side, the more obvious it is that the clarification must come from rapid analysis of timely, reliable discoveries.

The Who Cares TestSuccessfully leveraging “prospects” despite current challenges is the business of business.

In business tactics, the leverage involves a balancing act: the probability of losing an opportunity or a customer, weighed against the difficulty of gaining new opportunities and customers.

Any imbalance necessitates a trade-off – a calculated risk. In any given business, that calculation can be a strong point or a serious weak point in capability.

Discovering valuable new opportunities and customers (development) requires more intensive and difficult analyses than does assuring continuity (support).

But for business, continuity essentially has meaning as “continual effectiveness from preparedness”, not as “don’t change anything”.

Preparedness should always mean being able to do different things at different times, as necessary.

The new normal for business is that there is continuous environmental change exerting influences that create imbalances and the subsequent need for re-evaluating trade-offs.

That puts pressure on whether the business’s current preparedness actually does include the ability to do different things at different times as necessary.

Current preparedness fails if it cracks under pressure. It is necessary to understand how the pressure threatens continuity, and how to organize management of the threats.

customers

competition

innovation

complexity

volume

velocity

variety

diversity

volatility

DEVELOPMENTof value

RISKof relevance

Systemsfrom integration

OPPORTUNITY

CHANGE

PROVISION Servicesfrom orchestration

SUPPORTof continuity

Optionsfrom transparency

Performancefrom pursuit

Recognitionthrough rules

Demand effects

Supply effects

Business TopicBusiness Prospect Business Challenge

Offersfrom provision


Engineering outcomesService Management is, of course, about managing services. But the point of management per se is independent of what it is managing.

Management is always concerned that:

• The right thing is resulting

• in a reliable way

• with predictable effects

• that are not counter-productive

• and that immediately have adequate value

Increasingly, tasks that provide assurance of the above outcomes are tasks that can be automated.

Automation makes the production of desired outcomes significantly more readily achievable as intended. Automation essentially turns the producing into persistent engineering.

Engineering is expected to “pre-configure” both a service for business and the underpinnings of the service. If services as originally engineered were then impervious to damage and/or did not need to change, then further managing their configuration would not be necessary. But damage and change are both facts of life.

Due to the impacts of damage and change on finance and performance, management of the configurations of services is not optional.

Services help management, but a service itself must be managed.

What is a ConfigurationIn IT, a “service” has typically been a logical view of a “configuration” of components, important for supply to the business.

A component is meaningful as a static item; components are sub-units of system structures.

Components are managed through systems management, and there are component topologies to describe their managed arrangement.

But, a “configuration” of a service is not just a structure of components; it is an arrangement of elements.

An element is meaningful as a dynamic item: an element is a required aspect of a cause of action. It is a logical view, important to demand by the business.

Action elements are implemented through forms that may be virtual (emulated) or real (physical).

The implementation of the forms amounts to the configuration of the service.

What is a Configuration ItemA “CI” (configuration item) is not simply a component that has specified attributes.

An “item” of a service configuration is a logical view of an element (a cause of action) of a service in operation as prescribed.

That logical view is identified as a form used to implement an element.

A configuration item is, therefore, a form used to implement an element of a service.

The form called a “CI” has a prescribed behavior as an element of an action or event that constitutes a function.

The behavior may have dependencies on particular components made available as resources, but the prescribed behavior is the focus of managing the service configuration.

In other words, an identified CI is a resourced instance (an identified “actor”) of a role.

The essential CMDBAn identified CI is a resourced instance (an identified “actor”) of a role.

The form called a “CI” is accountable as an element that has its prescribed behavior engineered in a function.

What makes the entity behavior “engineered” is intentionality.

The intentionality is a combination of definitions identifying what is (to be) appropriate , with evidence indicating that the realization of the behavior (as is) correctly corresponds.

The definition and evidence data necessary to accurately account for the form in terms of the intentionality are usually expected to be contained for management in a configurations management database (CMDB).

The CMDB also includes identifiers of the interaction of the forms in terms of intentionality.

The Anti-agile CMDBUp to now, a conventional Configuration Management Data Base (CMDB) has cataloged and mapped managed components according to the dependent interactions that describe the mechanics of production systems. It has called those components “CIs”.

In effect, it attempts to instrument quality assurance of system implementations that make up a production environment.

Both as a purpose and as a result of that, the most prevalent use of a conventional CMDB is to provide a blueprint allowing reverse-engineering and support of what it tries to descriptively document. That amounts to supporting the systems usage by business.

But for current businesses, flexibility at high speed is the order of the day. Conventionally, a system’s mechanics are not known to have flexibility without high levels of complexity.

In those mechanics, stabilizing complexity for the purpose of gaining reliability (preparedness) usually involves high-energy optimization and/or high resistance to change.

That increases the risk of “stability” becoming rigidity or brittleness, reducing its relevance to different future conditions than already existed.

A conventional CMDB, focusing on components, is thereby always at risk of becoming either unmanageable or obsolete, unless the level of investment in its maintenance can be sustained at any necessary intensity.

CMDB for Business MeaningsOn the business side, the influences of competition, of technology innovation, and of cost-efficiency are now each strongly escalated and together endlessly re-combined.

That has overwhelmed many traditional assumptions about how business production environments work and evolve.

Most evolution is now user-demand driven, with remarkably low barriers against rapid and dramatic changes at many architectural levels of production.

Consequently, the conventional CMDB is more unlikely to keep up with the velocity, volume and variety of changes – except through extraordinary amounts of labor.

Its fundamental weakness for business use lies in the difficulty of maintaining complete and accurate data despite the continually increasing dynamic (not mechanical) complexity of what it tries to describe.

For business purposes, a corrected CMDB focus would be on service implementations rather than on systems implementations.

Self-Healing Systems vs. ManagementEveryone knows that automation is the principle solution to labor burdens.

Automation essentially brings execution power at high speed. More automation means that, through any combination of prediction and response that it offers, significant production can occur closer and closer to real-time demand.

In I.T., automation now must be understood as a phenomenon of intelligence driving instructions that in turn are driving machine-based procedures.

That definition clearly involves analyses, communications, and commands – all matters that are dramatically amplified and optimized by advanced information systems and information management technologies available today.

I.T. automation brings both recovery (maintenance) and re-engineering (change) of the production systems to much higher levels of effectiveness versus complexity, diversity or volatility of operational circumstances, without manual intervention.

Even more significant, I.T. (intelligence-based) automation increasingly means that the vast majority of adjustments may be made without requiring the notification and response of people.

Management AutomationTo operations, a major implication of the automation of management is that there is an unprecedented availability of real-time transparency of all current effects and states.

Operations in a maintained engineered environment then automatically uses that intelligence to guide immediate follow-up re-engineering at whatever intensity is appropriate.

For managing continuity, that automation ultimately means promoting, adjusting and correcting behaviors of service elements in real time, continuously.

For managing services, the automation dramatically reduces the required level of real-time human attention to risks in the viability of systems underlying service elements.

That automation allows shifting management’s attention mainly to addressing the business’s interpretation of service behaviors.

Value RecognitionThe implications of intelligent automation are big and already very real.

Automation can detect, analyze and respond to vast amounts of data, both local and remote, with otherwise unattainable speed and consistency.

Programming in automation removes the need for continual human interventions in existing detection, analysis and response – and accommodates decentralization of the data.

The data processing in automation drives automated interpretations of current conditions.

Advancing along the lines of A.I., machine learning, Big Data, IoT, and digital (virtual) architectures, configuration management will evolve to resemble the operation of quantitative analyses driving trading behaviors on Wall Street.

Behaviors are evaluated for their meaning with regard to gains, stabilities, and losses (i.e., value) in the market.

Central IntelligenceIn the stock market, the enormous amount of intelligence is not held in some container as a static reference.

Instead, it is continually streaming input.

The “central database” of significant information exists mainly as a channel with a crediblepoint of contact, for federated real-time reporting (feeds of data) about entities that are recognized through qualification by rules.

Recognition rules process detected entity attributes (called fundamentals).

Those attributes logically correlate with when demand leads to gains, stabilities, and losses in the market through transactions.

And they correlate with how arrangements of the events and behaviors underpin the transactions.

The actual real-time correlations may or may not conform to prescriptions or expectations.

Business Model LogicFor business managers, the example of the stock market management processing is clearly important.

In an environment where change continuously occurs aggressively and intentionally, the market management model is a more logical approach than conventional component-based factory management of IT services requiring control of a master inventory.

That is, the environment of business capability is described and interpreted mainly as a selective market of opportunities for “provision” (offer) of benefits, not mainly as a proprietary factory of machines for “production” (inventory) of systems.

Services are responsible for organizing the elements that make offers viable, feasible, and available.

To support pursuing and exploiting business-relevant opportunities:

• the business expects the benefits manager to practice Portfolio management.

• the business expects the service provider to practice Performance management.

• the business expects the systems manufacturer to practice Product management.

Business Management perspectiveThe business brings its demand-orientated perspective to management.

It interprets current conditions in terms of their impacts on its portfolio.

The portfolio is a registry of items (including assets, capabilities, and positions) having a specific type of value.

Current events and opportunities represent potential impacts on value.

Desirable impacts are explicitly pursued with services that are directed behaviors.

The services offer behaviors of recognized roles (entities and actors) in the environment.

The roles are “change agents” that themselves rely on supporting resources.

The business can tolerate a high volume of changes occurring at the resource level without having to do anything about it – as long as it can still directly manage the current states at the service level.

“Configurations” of Business CapabilityFor pursuing opportunities on demand, the business is offered prescribed capabilities to use.

The capabilities are based on co-operative functioning of prescribed entities.

Under management, services offer prescribed behaviors of recognized roles in the environment.

The roles rely on prescribed resourcing.

• Systems instantiate the entities and actors that resource the roles.

• Components constitute prescribed modules of systems.

To enable managed business capability:

An operations director deals with functional (entity) relation.

A service provider deals with behavioral (role) orchestration.

A systems manufacturer deals with structural (resource) integration.

A component supplier deals with unit (part) assembly.

Four Types of prescribed

Configurations

customers

competition

innovation

complexity

volume

velocity

variety

diversity

volatility

DEVELOPMENTof value

RISKof relevance

Systemsfrom integration

OPPORTUNITY

CHANGE

PROVISION Servicesfrom orchestration

SUPPORTof continuity

Optionsfrom transparency

Performancefrom pursuit

Recognitionthrough rules

Demand effects

Supply effects

Business TopicBusiness Prospect Business Challenge

Offersfrom provision


Configuration Informationfor Business

A “CI” is a resourced instance (an identified “actor”) of a role.

A configuration is a purposeful arrangement of the instances for a capability.

Engineering desired effects withprefabrication and orchestrationInnovative technology automation has created a new range of infrastructure patterns by offering more of what appears to be “prefabricated” functionality.

Prefabrication suggests to the business user that there is little-to-no need for “micro-managing” the item engaged as the source of the functionality.

In this view, the quality and integrity of the item’s “internals” are the responsibility of the item producer, not the item user. The producer, not the user, is held accountable for a reliable assurance that the item’s functionality will be available as advertised.

The overall approach is to assemble modules of capability, where a module has “no user-serviceable parts inside” but can work with other modules in a user-required way called a “deliverable”.

A defined deliverable comes with a designated scope, time and cost – all of which apply to a module of capability providing enabling behaviors. But with modularity, assurance of capability shifts from a basis of producers building things with user-owned assets to a basis of providers enabling things with user-defined behaviors.

Assembling behavior modules for their co-operation means that they must be coordinated. The coordination is aimed at all modules supporting the same designated function requested by demand. Orchestrating the behaviors is a sophisticated mode of coordination that addresses the diversity and variability of requirements imposed by demand on the modules. The resulting coordination is called a configuration.

Defining Capability Modules: ActorsFunctions exist at all scales and scopes of responsibility.

To execute a function, operators within the boundary of the function performactions in a specified role within a production.

Operators can be solo, integrated, chained, bundled, or sequenced in order to have them generate production progress through a coordination of their responsibilities.

A defined operator, when included by a function, is an actor.

Actors exist at all scales and complexities of form, as necessary to retain singular accountability for a defined influence recognized as an effect.

The effective influence is the value of the actor to the function.

Small/simple

large/simple

Medium/complex

Medium/simple

large/complexMedium/complex

Producing Actors (functional operators)

Actors in a role are created through a combination of:Character definition (conception)Training and support (development)Casting and Rehearsal (testing)Direction (monitoring, evaluation and adjustment)

As a result, we can say that the behavior supplied by the role has been engineered, where all aspects from the “expectation” to the “reality” are being managed to have a particular outcome.

Successfully creating needed actors generates the availability of production capability, through role performance.

One actor can perform several roles.One role can be performed by several actors.One actor can interact distinctively with several other actors.

Capability is the existing potential for an intended performance, which is expressed in operation.

The on-demand delivery of effects to known users is the target function of production.

DESIGN

Manage per Effect (describe)

INSPECT FEEDBACKCONSTRUCT

DEVELOP

“To Be” Information

Manage per Intention (prescribe)

(Iteration) (Validation)

“CONFIGURED“ Appropriate Authorized ValuablePrescribed Productive

TEST

“As Is” Implementation

Correct

“ENGINEERED“

“DEFINED“

“CONCEIVED“


POLICY

RULES

SCRIPT

FUNCTION

SPECIFICATION

MODEL

Actor behavior is engineered for Demand by defining the expectations applied as constraints by the consumer of the behavior

DEVELOP


Manage per Intention

Actor behavior is engineered for Supply by defining the type and the conditions that allow its use and cooperation

An “agent of capability” is an entity with an intended and appropriate behavior, which makes it an ACTOR.

AppropriateA range of standard types of information will constitute a definition complete enough for reliable management.


POLICY

RULES

SCRIPT

FUNCTION

SPECIFICATION

MODEL

BEHAVIORENGINEERED FOR DEMAND

Situation

Constraint

Capability

Execution

Resource

Form

TESTDEVELOP



ENGINEERING

“CONFIGURED“

BEHAVIOR ENGINEERED FOR SUPPLY

CorrectAppropriate

The instantiation of an ACTOR realizes the conceived and intended entity as an item that is, according to its logical definition, detectable and supportable in an implementation.


DESIGN

Priority

Tolerance

Role

Demonstration

Properties

Relations

(Iteration)

Prescribed

Manage for “To Be” Effect

An ACTOR managed according to plan will be effective as prescribed.

Actor behavior is developed for Demand by defining the expectations applied as constraints by the user of the behavior

Actor behavior is developed for Supply by defining the type and conditions that allow its use and cooperation

A range of standard types of information will constitute a definition complete enough for reliable management.



“CONFIGURED“


DESIGN CONSTRUCT

Event

Deployment

Process

Assignment

Instance

System

Priority

Tolerance

Role

Demonstration

Properties

Relations

(Iteration)

AuthorizedPrescribed

OFFER

The “Offered” version of the Actor is positioned to behave in an authorized way or else will be redirected, restrained, revised or removed. The authorized behavior is exhibited and observable in defined circumstances.


INSPECT

Context

Assignment

Compliance

Usage

Dependency

Persistence

(Validation)

Productive

An ACTOR managed according to plan will be effective for productivity.

Actor behavior is tested for Demand by defining the proposed conditions relevant to the party requesting the behavior

Actor behavior is tested for Supply by defining the type and characteristics that justify its responsibility to the utilization.

Manage for “As Is” Effect

A range of standard types of information will constitute a definition complete enough for reliable management.


INSPECT FEEDBACK

Context

Assignment

Compliance

Usage

Dependency

Persistence

State

Risk

Performance

Impact

Availability

Continuity

(Validation)

ValuableProductive

ASSESS


“CONFIGURED“


The “Assessed” instance of the Actor is measured to determine if and how its actual behavior is valuable.


DESIGN

AUTOMATE from “To Be” through “As Is”

INSPECT FEEDBACKCONSTRUCT

Event

Deployment

Process

Assignment

Instance

System

Context

Assignment

Compliance

Usage

Dependency

Persistence

State

Risk

Performance

Impact

Availability

Continuity

Priority

Tolerance

Role

Demonstration

Properties

Relations

From “To Be” Information

To “As Is” Implementation

CONFIGURE


“Configuration” is a meaningful term primarily in that it expresses concern for whether the desired effect of utilizing a source of capability (an actor) is logically supported by the actual state of the source. Management is applied to proactively ensure (engineer) the support, bridging the intended “to be” and the actual “as is”.

All of the iteration and validation work involves defining and monitoring the occasions in which the designated actor should be evident. Although there are many things involved, each of them can now be defined and monitored more rapidly and completely with automation, which also now means continuously.

Authorized ValuablePrescribed Productive


POLICY

RULES

SCRIPT

FUNCTION

SPECIFICATION

MODEL

DESIGN INSPECT


Situation

Constraint

Capability

Execution

Resource

Form

FEEDBACKCONSTRUCT

Event

Deployment

Process

Assignment

Instance

System

Context

Assignment

Compliance

Usage

Dependency

Persistence

State

Risk

Performance

Impact

Availability

Continuity

Priority

Tolerance

Role

Demonstration

Properties

Relations

TESTDEVELOP



ENGINEERED


“CONFIGURED“


CorrectAppropriate Authorized ValuablePrescribed Productive

OFFERED “To Be” ASSESSED “As Is”

How a Business sees meaning in Configurations


©2016 Malcolm Ryder / Archestra [email protected]

Technology

Business Service Configurations