Building blocks and services - introduction

One of about 300 papers at http://avancier.website  Copyright Graham Berrisford. Last updated  25/02/2017 17:05

 

Synchronising the core vocabulary within and between standards (TOGAF, ArchiMate and IT4IT) is a challenge.

Moreover, it is difficult to extend these standards with new material that uses a different language, and provides no mapping to the current language.

But the task is not hopeless; as this paper shows.

 

This is the first of two related papers.

1.      Building blocks and services – introduction – based on analysis done in 2009 for the British Computer Society

2.      Building blocks and services - detail  - adds TOGAF methodology and examples to the introductory paper.

Contents

Preface. 1

Building blocks in a nutshell 2

Behavioral views of a system.. 4

More about the structural view of a system.. 6

Aligning TOG standards. 7

Value streams, chains and networks. 8

More detail on building blocks and services. 9

 

Preface

 “The method proposed by systems theory is to model… multiple interacting components by abstracting from certain details of structure and component.” (Laszlo and Krippner)

 

TOGAF's generalisations are vital to the overall coherence and consistency of its content framework.

The content framework is built around three general principles:

1.      An enterprise is composed of interoperating building blocks (components, functions, organisation units, roles, actors, nodes).

2.      An enterprise architecture is an abstract (conceptual, logical) description of building blocks, their interactions and behaviors.

3.      The generic meta model is: required behaviors <are assigned to> logical structures <are realised> physical structures.

 

Core terms can be defined in a way that is general to TOGAF and ArchiMate.

Other terms often give different names to the same general concepts, often at different levels of abstraction, formality or granularity.

 

Behavior elements names

Structure element names

External view

Service, Service Contract

Interface, Boundary, Service Portfolio

Internal view

Process, Value Stream, Scenario

Building Block, Component, Function, Organisation Unit, Role, Actor, Node

 

Structural elements (persist between behaviors)

·         Interface: a collection of services requestable by a client; one way to specify a building block, component or other structural node.

·         Building block: an active structure, a performer of required activities, which interoperates with other building blocks.

·         Component: a building block defined by the one or more services it offers to clients.

·         Function: a logical component that clusters cohesive behaviors by some cohesion criterion other than sequence; a subdivision an organisation’s capability (cf. a capability).

A node connectivity, communication or value network diagram can relate structure elements of any kind by the exchange of flows or services.

 

Behavioral elements (run from start to end over time)

·         Service: a discretely requestable behavior that encapsulates one or more processes; it is triggered by an event or service request and produces a result of value; and is definable declaratively in a contract.

·         Process: a behavior composed of steps in a sequence; it is triggered by an event or service request and leads to an interim or final result.

A value stream, process, activity or sequence diagram can relate process steps to structure elements.

Building blocks in a nutshell

TOGAF’s system theory appears in the idea that an architecture is defined at an abstract level as a collection of interoperating building blocks.

It defines a building block as an encapsulated component of functionality or capability – in accord with component-based design principles.

TOGAF building block

A component - in general terms

“is generally recognizable as "a thing" by domain experts”

A component is a structural element rather than behavioral.

“may be assembled from other building blocks; may be a subassembly of other building blocks”

It is recursively composable and decomposable.

is a package of functionality defined to meet the business needs across an organization.”

It clusters* cohesive behaviors performable by an actor or component instance,

It clusters* cohesive services requested of it and/or processes performed by it.

“has a defined boundary”

It is encapsulatable behind an interface specification.

may interoperate with other, inter-dependent, building blocks.”

It is related to other components by requesting or delivering services.

“Ideally, is re-usable and replaceable, and well specified.”

It should offer generally useful services via an interface that is free of implementation detail.

considers implementation and usage, and evolves to exploit technology and standards.

It can be specified with particular technology-specific components in mind, or reverse-engineered from them.

 

* In general system theory (and TOGAF) terms:

Abstract/logical building blocks (functions, roles, and logical components) cluster behavior types that concrete building blocks can be nominated to perform.

Concrete/physical building blocks (organisation units, actors and physical components) are nominated to realise or perform instances of behavior types.

 

TOGAF expresses the importance of encapsulating building blocks.

“Systems are built up from collections of building blocks, so most building blocks have to interoperate with other building blocks.”

“It is important that the interfaces to a building block are published and reasonably stable.”

 

TOGAF tends to use the terms boundary and service portfolio instead of interface.

It encapsulates structural building blocks by defining the services they are required to perform.

“For each building block, build up a service description portfolio as a set of non-conflicting services.”

“A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports, etc.)”

 

Building block specification progresses through the ADM.

1.      Phase A: “At an early stage, a building block can simply consist of a name or an outline description."

2.      Phases B, C & D: “A building block’s boundary and specification should be loosely coupled to its implementation”

3.      Phases E, F & G: “It should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.”

4.      Phase H: “In many cases the architecture [ABBs] continues to fit, but the solutions [SBBs] underlying them may not, and some changes are required.”

 

Note that architecture building blocks (ABBs) abstract from solution building blocks (SBBs).

“The method proposed by systems theory is to model complex entities (multiple interacting components) by abstracting from certain details of structure and component.” (Laszlo and Krippner)

 

Positioning building blocks in a three-dimensional classification of system elements

A dynamic or behavioral view of a system shows a service or process that runs from start to end over time.

A static or structural view shows a structure of building blocks irrespective of time.

TOGAF specifies an internal building block by defining its external boundary, service portfolio or interface.

TOGAF abstracts logical or vendor-neutral architecture building blocks from physical solution building blocks.

 

TOGAF’s core meta model/architecture entities can be classified using these ideas as in the table below.

Viewpoint

Behaviors

Structures

Level of abstraction

External

Business Services

IS Services

Platform Services

Service Portfolios, Boundaries

Required behaviors

Internal

Business Processes

Business Functions, Roles

Logical Application Components

Logical Technology Components

Logical / Architecture

Building Blocks

Organisation Units, Actors

Physical Application Components

Physical Technology Components

Physical / Solution

Building Blocks

Behavioral views of a system

Service: a discretely requestable behavior that encapsulates one or more processes; it is triggered by an event or service request and produces a result of value; and is definable declaratively in a contract.

Process: a behavior composed of steps in a sequence; (cf. scenario and value stream); it is triggered by an event or service request and leads to an interim or final result.

A process, activity or sequence diagram can relate process steps to structure elements.

Services

“The importance… of specifying the desired behavior of a system before designing the structure that has to provide it, was the reason to include this concept in ArchiMate.” Mark Lankhorst.

TOGAF examples include: Check customer credit, Provide weather data, and Consolidate drilling reports.

ArchiMate examples include: Policy Creation, Claim Registration, and Claim Payment.

 

The table quotes definitions of service in the TOGAF and ArchiMate standards, and generalises from them.

A service as defined in TOGAF 9.1

A service in ArchiMate 3.0

A service - in general terms

“an element of behavior that provides specific functionality

a unit of behavior

a discretely requestable behavior (short or long) that

in response to requests from actors or other services.”

“useful to its users”

is triggered by an event/input received from a service requester/consumer.

“A logical representation of a repeatable business activity,

realized by.. functions.. performed”

encapsulates repeatable internal processes,

has a specified outcome,

“associated with a value”

produces a result of value to a service requester/consumer, and is

is self-contained, is a ‘‘black box’’ to its consumers.”

accessed through one or more… interfaces.”

presented to service requester/consumers in one or more interfaces.

 

Service contracts

The term service appears 1,037 times in TOGAF; and (as in rest of the industry) the term is used inconsistently.

However, the definition in chapter 22 says services are repeatable behaviors with specified outcomes.

"A service is a logical representation of a repeatable business activity that has a specified outcome”

It is “self-contained - may be composed of other services - is a ‘‘black box’’ to consumers of the service.”

The meta model chapter says a contract covers:

·         Behavior characteristics: functional behavior supported

·         Names of consumer and provider services.

·         Quality characteristics: non-functional requirements

 

In general, a service contract should include:

·         signature (name, input and output)

·         functional rules (pre and post conditions)

·         non-functional requirements.

 

Common errors include:

·         Naming a component or interface as a service (don’t call it a web service or micro service, call it a web app or micro application component).

·         Defining a group of services as one service (better call it a function, or assign it for access to an interface).

·         Turning a noun into a gerund (don’t say a hairdresser provides a hairdressing service, or a message broker provides a messaging service).

 

Read this paper for more on business services, application services, and platform technology services, and examples thereof.

Processes/scenarios

Processes are step by step behaviors, performed by building blocks, that end in producing a measurable result, delivering a value or meeting a goal.

TOGAF says: “All processes should describe the flow of execution."

And: "A business scenario describes: A business process... the people and computing components (called ‘‘actors’’) who execute the scenario, the desired outcome of proper execution”

More about the structural view of a system

Interface: a collection of services requestable by a client; one way to specify a building block, component or other structural node.

Building block: an active structure, a performer of required activities, which interoperates with other building blocks.

Component: a building block defined by the one or more services it offers to clients.

Function: a logical component that clusters cohesive behaviors by some cohesion criterion other than sequence; a subdivision an organisation’s capability (cf. a capability).

A node connectivity, communication or value network diagram can relate structure elements of any kind by the exchange of flows or services.

 

Encapsulation behind interfaces is general principle of all business system design, not just software design.

In this Harvard Business Review piece <https://hbr.org/2011/12/first-lets-fire-all-the-managers> Gary Hamel talks about Morning Star.

“Every year, the 23 business units negotiate customer-supplier agreements [interface specifications] with one another.

And each employee negotiates a Colleague Letter of Understanding [an interface specification] with associates most affected by his or her work.

“As a colleague, I agree to provide this report to you, or load these containers into a truck, or operate a piece of equipment in a certain fashion.” [i.e. I agree to provide this collection of services]

This [interface specification] covers as many as 30 activity areas and spells out all the relevant performance metrics.”

 

ArchiMate says an interface is a point of access where services are made available.

TOGAF tends to use the terms “interface”, “boundary” and “service portfolio” interchangeably.

(Aside: TOGAF’s “interface catalog” would be better called an information/data flow catalog.)

 

It is a principle of The Open Group that clients should invoke services via “open” interfaces.

The rationale of TOGAF 1 to 8 has been obscured in TOGAF 9, but it still says:

“For each building block, build up a service description portfolio as a set of non-conflicting services.

 

The term building block is sometimes replaced by “component” or some other term.

“A key goal of architecture development is for service modules to be capable of replacement by other modules providing the same service functionality via the same service API.”

Those “service modules” are building blocks that each provide multiple discrete services via an interface.

 

Read this longer paper for more on building blocks, capability maps , functional decomposition diagrams.

Aligning TOG standards

To align the vocabularies of different standards we cannot take their terms one by one; we have to step back.

Some terms are generalisation or specialisations of other terms

There are flaws/niggles in the generic meta models of TOGAF and ArchiMate - and they don't match perfectly.

The deeper generalisations are those of general system theory.

We have to distinguish where different terms are being used to distinguish:

·         different system theory concepts (notably structures/components and behaviors/services)

·         different levels of granularity in one concept (as in functional decomposition or process decomposition)

·         different specialisations of one generic concept in different architecture layers (e.g. human and computer).

 

TOGAF

The TOGAF meta model can be tabulated thus:

 

 

Required behaviors

are assigned to

Logical structures/building blocks

are realised by

Physical structures/building blocks

Business

Business Services

Functions

Organisation Units

Roles

Actors

Information Systems

IS Services

Logical Application Components

Physical Application Components

Technology

Platform Services

Logical Technology Components

Physical Technology Components

 

Implicit in TOGAF are the equations: function = logical business component, and organisation unit = physical business component.

The abstract/logical building blocks cluster behavior types that concrete building blocks can be nominated to perform.

The concrete/physical building blocks are nominated to realise or perform instances of those behavior types.

 

ArchiMate

The core of the explicit generic meta model can be tabulated thus

 

Behavior elements names

Structure element names

External view

Service

Interface

Internal view

Process

Role, Actor, Component, Node

 

ArchiMate does not distinguish logical structures from physical structures

Still, the meta model can be tabulated for comparison with TOGAF thus.

 

Required behaviors

Logical structures

Physical structures

Business

Business Services

Functions

Actors

Roles

Application

Application Services

Application Interfaces & Functions

Application Components

Technology

Platform Services

Technology Interfaces & Functions

Nodes

 

For more on alignment of ArchiMate with TOGAF, read TOGAF-ArchiMate alignment.

 

Data?

Data entities/objects could be mapped to many the system elements, notably:

·         Services can consume and produce I/O Data Entities/Objects.

·         Processes can create and use stored Data Entities/Objects.

Value streams, chains and networks

Value streams as behaviors

A value stream is: “an end-to-end collection of activities that create a result for a ‘customer’ who may be the ultimate customer or an internal ‘end user’ of the value stream” Martin (1995).

A value stream implies a multi-step process, and usually involves more than one participant, role or building block.

Value stream analysis involves measuring process steps, and optimising the process in the light of those measurements.

This might be done in the course of what TOGAF calls business scenario analysis.

Value chain diagrams as a function/capability structures

TOGAF’s business function hierarchy is a logical organization structure built over the top of bottom-level “elementary” business activities.

Porter’s famous value chain diagram shows a first level functional decomposition – with a hint of an end-to-end value stream

Value chain: “a [disaggregation of] a firm into its strategically relevant activities in order to understand the behavior of costs and the existing potential sources of (competitive) differentiation” Porter (1985).

TOGAF says: A Value Chain diagram provides a high-level orientation view of an enter prise and how it interacts with the outside world.

In contrast to the more formal Functional Decomposition diagram developed within Phase B (Business Architecture), the Value Chain diagram focuses on presentational impact.

Value networks as structures

TOGAF speaks of a node connectivity diagram.

A node connectivity diagram show nodes as structural building blocks that relate to each other by exchanging flows or services.

The nodes can be business functions, organisation units or roles.

Any network of interoperating building blocks, each providing services to others, may also be called a value network.

More detail on building blocks and services

This is the first of two related papers:

1.      Building blocks and services – introduction – based on analysis done in 2009 for the British Computer Society

2.      Building blocks and services - detail  - adds methodology and examples to the introductory paper.

 

For more on alignment of ArchiMate with TOGAF, read TOGAF-ArchiMate alignment.