TOGAF concepts and principles

Featuring building blocks and services

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 15/02/2018 12:42

ArchiMate®, The Open Group®, TOGAF®, UNIX®, are registered trademarks, and Boundaryless Information Flow™ and IT4IT™,  are trademarks of The Open Group.

 

Synchronising the core vocabulary within and between standards is a challenge.

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

This is one of several papers that update and extend analysis done for the British Computer Society (for their professional certificates in enterprise and solution architecture).

Contents

TOGAF’s general concepts and principles. 1

Structures and behaviors in system description. 3

Joining up the TOGAF dots. 5

How TOGAF and ArchiMate define “service”. 9

How TOGAF defines “building block”. 11

Some TOGAF principles. 13

Things that hinder understanding and harmonization of ArchiMate with TOGAF. 15

Even more on behaviors and structures. 17

Footnote: a few curious facts. 18

 

TOGAF’s general concepts and principles

The Open Group promotes the idea of standards (executable standards) based on API specifications.

An API specifies a software system or component thereof by a declarative specification of the discrete behaviors/operations it can perform.

This concept is not limited to software; it applies to all human and computer activity systems.

 

TOGAF is not itself an API, but it does conform to the principle of specifying systems by interfaces.

It is a methodology for designing, planning and governing changes to human and computer activity systems.

It calls components “building blocks” (there are logical and physical versions in each architecture domain/layer).

It calls interfaces “boundaries”, and calls operations “services”.

 

An architecture is a set of building blocks depicted in an architectural model, and a specification of how those building blocks are connected to meet the overall requirements of the business.”

“A building block’s boundary and specification should be loosely coupled to its implementation."

“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” (TOGAF 9.1)

 

So, TOGAF is based on the principle of specifying a system or component thereof by a declarative specification of the discrete behaviors/services it can perform.

Its Architecture Requirements Specification includes the Business Services and IS Services of the target system(s).

And its Technical Reference Model is a high-level identification the Platform Services provided by the whole technology domain/layer to the business application domain/layer.

 

More detail

The same concepts are known by different names in other standards, such as UML and ArchiMate.

TOGAF terms

concepts

UML  terms

ArchiMate  terms

Building block

A logical or physical component of a business system,

such a business function, role, application or technology.

Component

Internal Active

Structure Element

Boundary

The input/output interface of a building block, definable as a service portfolio.

Interface or Service

Interface

Service

A discrete event or request-triggered behavior.

Operation

Service

 

TOGAF standard is thoroughly service-oriented, it defines architecture domains and building blocks by services they offer.

Service are first only named (perhaps in clusters) and later detailed incrementally as the ADM proceeds.

TOGAF entities

Business

Applications

Technology

Generic concepts

Services

Business Services

(as in a SLA)

IS/Application Services

(as in a UI or API)

Platform Technology Services

(as in a TRM)

Required behaviors

Architecture

Building Blocks

Functions & Roles

Logical Application Components

Logical Technology Components

Logical structures

Solution Building Blocks

Organisation Units & Actors

Physical Application Components

Physical Technology Components

Physical structures

 

A logical application or technology component is abstracted from its realization by one or more physical components.

A role is a specification abstracted from its realization by one or more actors.

A business function is a specification abstracted from its realization by one or more organization units.

 

The classic approach to analysis and design is to reverse engineer from the baseline, then forward engineer to the target.

TOGAF encourages enterprise architects to abstract logical components from physical components, and abstract external views (services) from internal views (components).

Then, in forward engineering: "It should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.”

 

In short, abstraction of specification from implementation is central to TOGAF's concept of enterprise architecture.

It runs through TOGAF’s ADM, meta model, enterprise continuum and enterprise repository, as the table below indicates.

ADM Deliverable

Services & Building Blocks

Enterprise Continuum

Enterprise Repository

Architecture Req’ments Specification

Business & IS/App Service Contracts

Requirements & Context

Requirements Repository

Architecture Definition Document

Architecture Building Blocks

Architecture Continuum

Architecture Repository

Architecture Road Map

Solution Building Blocks

Solutions Continuum

Solutions Repository

Architecture Change Requests

 

Deployed Solutions

 

Of course, the contents of three repositories must be cross-referenced in one coherent Enterprise Repository.

But TOGAF expects enterprise architects to maintain only the logical architecture.

"While the architecture specifications may not change, the solutions or their operational context may change."

"Ensure any changes implemented in this phase [H] are captured and documented in the Architecture Repository"

The implication is not that solutions are documented in the Architecture Repository!

It is that solution architects maintain what is documented in the Solutions Repository, and cross-references are drawn as required.

Structures and behaviors in system description

Enterprise architects are concerned with describable and testable business systems.

A system is described as a collection of interrelated and repeatable activities (aka behaviors) performed by actors (aka active structures).

The table below illustrates the structure/behavior distinction; terms highlighted in blue are used in TOGAF and in this paper.

 

Structures and stocks in space

components related in

hierarchies and networks

Behaviors and flows in time

events and activities

in sequences

Actor

Building block

Capability

Dancer

Entity

Function

Holding

Matter

Organisation unit

Player

Product

Role

Stock

Trader

Structure

Variable and Value

Activity

Behavior

Conduct

Dance

Event

Flow

Happening

Motion

Operation

Performance

Process

Rule

Stream

Transaction

Service

Value Stream

 

Every designed system can be described in terms of behaviors perforrmed by structures to meet some aims.

This table generalises from how these concepts appear in standard frameworks like TOGAF and NAF, and modelling languages like ArchiMate and UML.

 

Business system concepts

General definitions

Aims (why)

motivations for behavior

Goal or Objective

a target to be achieved, a motivation or reason to perform behaviors.

Behaviors (how and when)

things that happen over time and change the state of a system or its environment

Service

a discrete event/request-triggered behavior that produces a result of value to a consumer, describable in a contract that encapsulates internal processes

Process

a sequence of activities that leads to the production of a desired result (a state change, product or output flow).

Logical structures

groups of behaviors that are assignable to active structures

Function

a logical system component, describable externally by services provided and internally by activities assignable to one or more organisation units.

Role

a logical system component, describable externally by services provided and internally by activities assignable to one or more actors.

Active structures (who)

things that act - perform behaviors

Organisation unit

a named business division, which can be given the responsibility of realising one or more logical functions.

Actor

a named person or machine, which can be given the responsibility of realising one or more logical roles.

Passive structures (what)

things that are acted on

Physical entity

a concrete entity type that a business creates and/or uses in the course of performing behaviors.

Data entity

a record type - created and used in the course of performing behaviors - that describes the attributes of an entity or event

Location (where)

a place in space where a structure can be found.

 

Aside: the table above separates people from organisations and roles, in ArchiMate both people and organisation units are called actors, in UML roles are called actors.

And note the curiosity that whereas every human actor is a unique individual, every software actor is a replicable individual.

Joining up the TOGAF dots

EA grew in the 1980s as a reaction against silo Solution Architecture, uncoordinated business processes and data, difficulty of change etc.

EA remains concerned with what it is cross-organisational and strategic.

That is one reason why TOGAF places so much emphasis on abstraction from the detail of individual solutions.

 

TOGAF 1 to 7 was an IT architecture framework – concerned primarily with the platform technology portfolio.

TOGAF 8 was more clearly an EA framework - more about business roles, processes and the business application portfolio.

TOGAF 9 decoupled the ADM from EA – allowing it to be used an SA or Capability Increment level only.

 

Still, the concerns of EA remain cross-organisational and strategic, and involve communication with executive managers.

EA has to address cross-organizational and strategic optimization, standardization and integration of business processes that create and use business data.

And it involves managing a portfolio of scores, hundreds, even thousands, of business systems and changes to them.

 

One has to recognise that using TOGAF at different levels is different.

At the bottom level, what TOGAF (oddly) calls "Capability Architecture” is much about what may be represented in diagrams.

At the top level, what TOGAF calls "Enterprise Strategic Architecture" is more about portfolio analysis and management.

Enterprise architects communicate with executive level managers using pie charts and other simple graphical devices.

Some of this activity may well be completed in the Preliminary Phase (or even above the ADM).

TOGAF lists about 40 artefacts for architecture definition, which can be divided into two groups.

 

Enterprise Strategic Architecture artefacts

These are primarily for use in analysis and direction setting at a strategy or portfolio level.

Used for gap analysis, cluster analysis, impact analysis and traceability analysis.

These artefacts are mostly catalogs and matrices.

Organization and function decomposition diagrams can be seen as hierarchical catalogs.

 

Solution or Capability Increment artefacts

These are primarily for use during an ADM cycle at the solution or capability increment level.

These artefacts are mostly diagrams.

Of course, some artefacts may be used at both levels, and strategic ones must be updated.

Nevertheless, dividing the artefacts between the levels helps people to make better sense of TOGAF.

It could be argued some artefacts (right aligned in the table) are products of phases E to G rather than B to D.

 

Enterprise Strategic Architecture artefacts

Solution or Capability Increment artefacts

Motivation

Driver Goal/Objective Catalog

Goal/Objective/Service Diagram

Business

Organization Decomposition Diagram

Node Connectivity Diagram (physical or logical)

Functional Decomposition Diagram

Function/Org Matrix

Role Catalog

Business Function/Service Catalog

Process/Event/Control/Product Catalog

Process Flow Diagram

Business Scenario

Actor/Role Matrix

Organization/Actor Diagram

Applications

 

Application Portfolio Catalog

Application/Function Matrix

Role/Application Matrix

Application Communications Diagram

Process Application Realization Diagram

Application Use Case Diagram

Application User Location Diagram

Software Engineering Diagram

Software Distribution Diagram

Data

Conceptual Data Diagram

Data Entity/Function Matrix

Application/Data Matrix

Data Entity/Data Component Catalog

Data Dissemination Diagram

Business Service/Info Diagram

Logical Data Diagram

Data Security Diagram

Data Lifecycle Diagram

Data Migration Diagram

Technology

Technology Standards Catalog

Technology Portfolio Catalog

Technology Services Catalog (TRM)

Technology/Application Matrix

Environments and Locations Diagram

Processing Diagram

Networked Computing/Hardware Diagram

Communications Engineering Diagram

Platform Decomposition Diagram

 

For artefact definitions and examples, read the associated slide show 1a.

On logical specification of systems

Enterprise architects are concerned with describable and testable business activity systems.

An activity system is describable as a collection of:

·         interrelated activities (behaviors)

·         performed by role-playing actors (active structures)

·         on artefacts that are inputs, outputs or persistent system state (passive structures)

·         to meet the aims of the system.

 

System theory gives architects tools for specifying systems that are logical and independent of computing.

 

Viewpoint

Logical description format

Useful for documenting

Behavior

External view

Service contract

Business, IS/App and Platform Services

Internal control logic

Process flow diagram

Processes

Active structure

External view

Service portfolio or interface

Functions, Roles and Logical Components

Internal connectivity

Node connectivity diagram

Communication between active structures

Passive structure

Memory / data store

Entity-attribute-relationship model

Data Entities and Logical Data Components

Message / data flow

Regular expression structure

Data flow structures

TOGAF’s  abstraction of architectures from solutions

The classic approach to analysis and design is to reverse engineer from the baseline, forward engineer to the target.

 TOGAF encourages enterprise architects to abstract logical components from physical components, and abstract external views (services) from internal views (components).

 

This table uses these distinctions to classify core concepts in TOGAF; the colours distinguish architecture domains.

Motivations

and constraints

Passive structures

Behaviors

Logical structures

Physical structures

Things that are acted on

Things that happen

Specifications of thing that act

Things that act

Drivers

Goals/Objectives

Business Data Entities

Business Services

Processes

Functions

Roles

Organization Units

Actors

Logical Data Entities

IS/App Services

Logical Application Components

Physical Application Components

 

Platform Services

Logical Technology Components

Physical Technology Components

 

Logical: “An implementation-independent [portable, vendor-neutral] definition of the architecture."

Physical: “A description of a real-world entity” that is still “considerably abstracted from implementation“.

 

Enterprise architects work at a higher level abstraction than solution and technical architects.

TOGAF promotes abstraction from physically identifiable system components to logical specifications of them.

It separates logical “architecture buildings blocks” from physical “solution building blocks.”

This separation runs all the way through TOGAF, including the structures of its enterprise continuum and enterprise repository.

 

Enterprise Continuum

Enterprise Repository

Level of specification

 

1 Enterprise Strategic Architecture & Business Planning

gives rise to 2

Requirements & Context

Requirements Repository

2 Architecture Requirements & Service Contracts

which are clustered and assigned to 3

Architecture Continuum

Architecture Repository

3 Architecture Building Blocks

implementation-independent logical component specifications, "realised by” 4

Solutions Continuum

Solutions Repository

4 Solution Building Blocks

nominate/describe physical components to be hired, bought or built. 

And still "considerably abstracted from implementation" and truly realised by 5

Deployed Solutions

5 Deployed Solutions

passive configuration structures

active (run-time) structures and behaviors

 

TOGAF presumes enterprise architects work at levels 1, 2 and 3, well above the artefacts deployed at level 5.

A specification level must be traceable to the one above and below, whether it is in same data store or not.

You can tag each building block’s position in other dimensions, say, from generic-to-specific (Foundation to Organization).

 

Bear in mind the highly iterative and flexible nature of the ADM process.

 

Note 1: Architecture work outside of an ADM cycle

Strategic level catalogs and matrices may be documented and maintained before and outside of an ADM cycle.

TOGAF suggests using functional decomposition for heat mapping and scoping changes planned via an ADM cycle.

 

Note 2: Early selection of Solution Building Blocks

Suppose phase A starts with a request to implement a particular application or technology in one organization unit?

That implies starting phase E early and reverse engineering higher levels of documentation

Populate the solutions repository with the solution building block.

Abstract the requirements and architecture to be as logical (implementation-independent, portable, vendor-neutral) as possible

(That is what architects maintain in phase H: “architecture change management”.)

How TOGAF and ArchiMate define “service”

“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 in correspondence.

 

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 "A service is a logical representation of a repeatable business activity that has a specified outcome”, which is supported by examples.

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

Examples in ArchiMate include: Policy Creation, Claim Registration, and Claim Payment.

 

The table below quotes definitions of service in two Open Group 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.

 

A service is first named, then lightly described, and eventually defined in a service contract, which makes no reference to the internal workings of any building block that provides it (or other building blocks it depends on).

Typically a service contract includes:

·         signature (name, input and output)

·         functional rules (pre and post conditions)

·         non-functional requirements/qualities.

 

Common errors include:

·         Naming a component or interface as a service

·         Defining a group of services as one service

·         Turning a noun into a gerund (to say a hairdresser provides a hairdressing service, or a message broker provides a messaging service is to say nothing).

 

Service specification through the ADM

The ADM is a method for service-oriented architecture development.

·         In phases B and C, Business and IS Service Contracts are recorded in the Architecture Requirements Specification. 

·         In phase C, the III-RM provides a service-oriented design pattern for the applications architecture domain/layer. 

·         In phase D, the TRM catalogues the foundation Platform Services provided by the technology architecture domain/layer.

 

These three phases populate the Architecture Continuum and Architecture Repository with Architecture Building Blocks defined by the services they offer.

 

References to services in TOGAF

The service/process-oriented specification principle is evident throughout the TOGAF standard, including:

Chapter 8: Business architecture: 8.4.1

Chapter 11: Application(s) architecture: 11.4.1.2

Chapter 12: Technology architecture: 12.4.1.2  and 12.4.1

Chapter 22: SOA

Chapter 26: Business scenarios and business goals

Chapter 34: Meta Model

Chapter 37: Building Blocks

Chapter 43: The Technical Reference Model

How TOGAF defines “building block”

TOGAF's building block chapter mirrors the section in the UML standard on the more universal "component" concept.

 

Quotes from TOGAF’s definition of Building Block (Chapter 37)

Quotes from UML 2.4.1 / 8.3.1. definition of Component

An architecture is a set of building blocks depicted in an architectural model, and a specification of how those building blocks are connected to meet the overall requirements of the business.

 

A building block is a package of functionality defined to meet the business needs across an organization.

 

A component represents a modular part of a system that encapsulates its contents.

A component is a self-contained unit that encapsulates the state and behavior of [internal elements].

Systems are built up from collections of building blocks,

so most building blocks have to interoperate with other building blocks.

A system’s functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring them together.

(UML stereotypes include «subsystem» to model large-scale components.)

it is important that the interfaces to a building block are published and reasonably stable.

A component defines its behavior in terms of provided and required interfaces

Ideally a building block is re-usable and replaceable

A component is a substitutable unit that can be replaced ... by a component that offers equivalent functionality.

and well specified.

A component specifies a formal contract of the services that it provides to its clients and those that it requires from other components in the system.

 

A system can be extended by adding new component types that add new functionality.                                      

A building block has a defined boundary and is generally recognizable as ‘‘a thing’’ by domain experts.

A component has an external or “black-box” view by means of its publicly visible properties and operations.

A building block may be assembled from other building blocks;

may be a subassembly of other building blocks.

A component also has an internal or “white-box” view [that] shows how the external behavior is realized internally.

A building block may interoperate with other, inter-dependent, building blocks.

The wiring between components in a system can be structurally defined by using dependencies.

It should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.

A building block’s boundary and specification should be loosely coupled to its implementation.

UML stereotypes [applied to component include] «specification» and «realization»

where one specification may have multiple realizations.

The major work… consists of identifying the architecture building blocks required to meet the business goals and objectives. The selected set of architecture building blocks is then refined in an iterative process

A component is modeled throughout the development life cycle and successively refined into deployment and run-time.

to arrive at a set of solution building blocks which can either be bought off-the-shelf or custom developed.

A component may be manifest by one or more artifacts, and in turn, that artifact may be deployed to its execution environment.

 

A deployment specification may define values that parameterize the component’s execution.

 

 “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.”

 

However, 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 through the ADM

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

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

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

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

 

References to building blocks in TOGAF

The notion of an enterprise as a system of interacting building blocks is most obviously evident in:          

·         Chapter 1: Introduction: Executive summary

o   An architecture framework … a method for designing … the enterprise in terms of… building blocks, and… how the building blocks fit together.

·         Chapter 2 Core concepts:

o   Building block: “a component of… capability that can be combined with other building blocks to deliver architectures and solutions.”

o   Architecture: ‘The fundamental organization of a system, embodied in its components, their relationships to each other…”

o   Architecture: “The structure of components, their inter-relationships…”

·         Chapter 6: Preliminary phase

o   “Enterprise architecture … regards the enterprise as a system or system of systems.”

·         Chapter 37: Building Blocks

o   An architecture is a set of building blocks depicted in an architectural model, and a specification of how those building blocks are connected to meet the overall requirements of the business.”

o   Building blocks are encapsulated units of functionality (functions, organisation units, roles, actors, application and technology components).

 

The separation of logical specifications from physical solutions is evident in Open Group standards from the Unix OS standard onwards.

It is evident in the TOGAF standard, including:

·         TOGAF preface

o   "The Open Group is a vendor-neutral and technology-neutral consortium."

·         Chapter 1: Introduction

o   “Starting from this sound foundation the members of The Open Group Architecture Forum have developed successive versions of TOGAF”

o   The “sound foundation” is the TAFIM principle of logical, service-oriented specification of a system or subsystem.

·         Chapter 2: Core concepts: This clearly separates logical architecture from physical solution.

o   Architecture Building Blocks “describe required capability”

o   Solution Building Blocks are “components… used to implement the required capability”

·         Chapter 39: The Enterprise Continuum: This clearly separates logical architecture from physical solution.

·         Chapter 41: The Architecture Repository: This clearly separates logical architecture from physical solution.

Some TOGAF principles

The principles below are not declared as such in the standard text.

Nevertheless, their appearance and reappearance helps to give TOGAF coherence and consistency.

 

1: Enterprise as a system of interacting building blocks

“EA regards the enterprise as a system, or systems of systems”

“Systems are built up from … building blocks [that] interoperate with other building blocks.”

The major work… consists of identifying the architecture building blocks required to meet the business goals and objectives.”

Below, you can read building block as function, role, organisation unit or component.

 

2: Architecture building blocks abstract from implementation

 “The architect… must remain at a level of abstraction necessary to ensure that they do not get in the way of practical implementation.”

“Logical application component: an encapsulation of application functionality that is independent of a particular implementation.”

“Physical elements  may still be considerably abstracted from solution architecture, design, or implementation views.”

Solution building blocks are hired, bought or built to realise architecture building blocks, and so perform the required behaviors.

 

3: The primacy of behavior in building block specification

This means the internal structure of a building block is secondary to its behaviors.

A building block provides services that deliver results of value to other building blocks and/or external entities.

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

 

4: Freedom to abstract and to refine

To enable this, most system description elements (not just functions and processes) can be hierarchically nested.

So, systems descriptions can be composed and decomposed to suit the breadth of the system, and level of detail required.

Also, elements can generalised and specialised, according to the standardisation and/or diversification required.

And so, every concept used in system description can be composed and/or decomposed; and be generalised and/or specialised.

 

5: Rationalisation by reverse/forward engineering

This means: reverse engineer from physical structure to logical structure and current behavior.

Then forward engineer from required behavior to logical structure to physical structure.

This principle, though the whole basis of TOGAF v1 to 7, is ss clear in v9.

 

6: The generic meta model

A general pattern, evident in the meta model, is reflected in many parts of TOGAF.

Required behaviors <are assigned to> logical building blocks <are realised by> physical building blocks.

 

EA involves analysing and describing the human and computer activity systems in a business.

The UML standard sets out two premises that underpin the modelling of all such business systems.

1.      all behavior in a modeled system is ultimately caused by actions executed by so-called active objects.” (cf. building blocks in TOGAF).

2.      behavioral semantics only deal with event-driven, or discrete, behaviors.” (cf. services in TOGAF).

These two premises appear in TOGAF in the form of services and building blocks, discussed below.

Things that hinder understanding and harmonization of ArchiMate with TOGAF

Remember, TOGAF encourages enterprise architects to separate logical specifications from physical realizations.

It distinguishes external views (services) from internal active structures (components).

It distinguishes logical structures and components from physical structures and components.

 

The points below seem academic at first, but they impede understanding and harmonization of the standards.

 

The logical/physical structure distinction

Human actors <are hired to perform the activities required of defined> roles.

Organizations units <are expected to perform activities that are clustered into> business functions.

Software objects <are instantiated to perform the activities that define a> class.

Roles, functions and class are not themselves active structures.

They are logical structures that specify activities performed by “physical” actors, organization units and objects.

 

ArchiMate has no general logical component concept.

Organization units and human actors have the same active structure symbol

Their logical equivalents – functions and roles – have different symbols - one structural and one behavioral.

 

The structure/behavior distinction

All active structures may be defined by the activities they perform.

TOGAF building blocks are structural components.

UML classifies classes, objects, and components as structural

ArchiMate classifies roles, actors and application components as structural.

But ArchiMate classifies business functions as behavioral, which creates the following confusion.

 

The function/process distinction

In business architecture, the function/process distinction is a structure/behavior distinction.

TOGAF’s business function is a node in a decomposition structure, a logical component, a logical organization unit.

ArchiMate’s business function is probably the same (it was last time I checked).

Contrarily, ArchiMate users symbolise processes inside application as functions.

This undermines the classic function/process distinction on which the TOGAF meta model depends.

 

Discreteness of event-triggered processes and services

In modelling human and computer activity systems, all behaviors are event-driven.

ArchiMate’s meta model explicitly associates events with processes.

Services are also event-driven behaviors.

In ArchiMate, a component offers an interface featuring several discrete services (rather the one service).

In TOGAF, a component is defined by a portfolio of discrete services.

 

Component-bound interfaces

ArchiMate says a component is “composed of” one or more interfaces.

This means, conversely, that an interface is part of one and only one component.

This prevents interfaces being decoupled from components.

True, one service can appear in many interfaces, and so be realised by more than one component

But one interface cannot offer services realised by more than one component (as a WSDL interface can do).

 

Aligning ArchiMate’s generic meta model with TOGAF

It is not enough to compare terms in the two different vocabularies one by one.

Because the axioms on which the two standards are based are a little different.

We have to step back to consider the general principles that underpin the standards.

 

ArchiMate’s general principles

This simple table shows how ArchiMate classifies system description elements in two-dimensions.

 

Behavior

Structure

External view

Services

Interfaces

Internal view

Processes

Active Structures

 

ArchiMate adapted to fit TOGAF

 

Behavior

Structure

External view

Services

Interfaces

Internal view

Processes

Logical Structures

aggregate properties (e.g. abilities and behaviors)

that physical structures are expected to realise

Physical Active Structures

are nominated to realise those properties

(e.g. perform those behaviors.)

 

TOGAF version of the same

 

Behavior

Structure

Generic meta model

External view

Services

Interface / Boundary / Service portfolio

Required behaviors

Internal view

Processes

Logical Architecture Building Blocks

Logical structures

Physical Solution Building Blocks

Physical structures

 

This table shows how TOGAF applies the generic meta model in each architecture domain.

 

Required behaviors

Logical structures

Physical structures

Business

Business Services

Functions

Organization Units

Roles

Actors

Information Systems

IS Services

Logical Application & Data Components

Physical Application & Data Components

Technology

Platform Services

Logical Technology & Components

Physical Technology Components

 

This structure of this table is reflected in the structure of the TOGAF meta model abstracted from its artefacts.

Even more on behaviors and structures

Service: a discrete event or request-triggered 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.

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”

 

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

 

Structural elements can be related in node connectivity diagrams, communication diagrams or value network diagrams.

Structural elements and behavior elements can be related in value stream diagrams, use case diagrams, sequence diagrams and other process models.

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

 

The ArchiMate standard 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.)

 

A principle of The Open Group is that clients should invoke services from building blocks via “open” interfaces.

The service-oriented nature of TOGAF has been a little obscured in version 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.

 

Encapsulation of components 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.”

Footnote: a few curious facts

Nothing in the universe is a system until it is named and described as such.
When you look for them, describable systems can be found everywhere, interrelated, nested and overlapping.

 

The dynamics of biological systems are continuous.

By contrast, the dynamics of the business processes we model are discrete, the start and stop, start and stop etc.

We are modelling discrete event driven systems (DEDS).

However, the time interval between events may be small enough to simulate continuous dynamics.

 

We never model individual human actors, we model only the roles they play.

What they do between performing discrete event-driven activities is outside the scope of our system.

 

What UML calls “active objects” are not really active.

Each is a passive structure, composed of state variable values and executable instructions.

The instructions (copied from a class definition) describe how to manipulate the variables.

The truly active structures are the computers that read and perform the instructions held by the objects.

But we never model the computers themselves; instead, we treat the objects as doing the work.

 

x  y  z.

 

All free-to-read materials on the http://avancier,web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.