TOGAF concepts and principles

Featuring building blocks and services

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 28/03/2018 17:06

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

 

Mistakenly presuming the same words mean the same thing is the very devil when it comes understanding different standards.

To use TOGAF with ArchiMate or UML, we have to understand and expose the different meanings they attach to terms.

Hiding those differences leaves people either confused or else mistakenly certain of their own personal interpretation.

Comparing the terms and concepts is challenge, but the task is not hopeless, as this paper shows.

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

Contents

TOGAF as a system change framework. 2

TOGAF’s two implicit principles. 2

Structure and behavior in UML 2.5 and TOGAF 9.1. 4

Generic meta models in ArchiMate 3.0.1 and TOGAF 9.1. 5

TOGAF artefacts. 8

Business scenarios, value streams and use cases. 10

Service contracts. 11

The business architecture domain/layer 12

The applications architecture domain/layer 15

The technology architecture domain/layer 19

A few mappings. 19

TOGAF for enterprise architecture and for solution architecture. 21

Some TOGAF principles. 24

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

How TOGAF and ArchiMate define “service”. 27

How TOGAF defines “building block”. 28

More on Services and  Building Blocks in TOGAF. 30

Concluding definitions of behaviors and structures. 31

Footnote: a few curious facts. 34

 

TOGAF as a system change framework

“The Open Group is a global consortium that enables the achievement of business objectives through technology standards.”

People sometimes expect The Open Group’s Architecture Framework (TOGAF) to be something it is not.

It is not a technology standard; it is a methodology - a management framework for changing business systems.

It is a management framework for people wanting to design, plan and govern changes to business systems – under change control.

 

TOGAF does not provide much guidance on architecting systems – it mostly assumes people know that already.

However, this paper explores what it does say about how to describe a system.

 

TOGAF says of enterprise architecture:

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

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

 

A system description typifies some structures and behaviors that characterize an observed or envisaged business,

It is composed of abstract types that generalize characteristics of individual structures and behaviors.

E.g. A role characterizes actors (or active structures) who perform behaviors, which create and use data objects.

A behavior characterizes performances of activities or communication acts by actors playing roles.

A data type characterizes data objects (or passive structures) used to store or communicate information.

 

A system description abstracts from the details of the reality, from a viewpoint, for a purpose.

(It abstracts so far that one reality may be described from different viewpoints as different systems.)

TOGAF’s implicit principles

TOGAF encourages logical technology-independent specification of business systems.

Understanding its logical architecture definition principles helps to people to read it in a coherent and consistent way.

It says of enterprise architecture:

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

An architecture is a set of building blocks depicted in an architectural model.”

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

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

 

Principle 1: The architecture of a system is a set of interoperating building blocks

When we look inside a system, we see smaller subsystems or building blocks that are interacting.

In TOGAF, an architecture is an abstract system description.

The architecture describes a collection of building blocks that interact in the regular activities of the system.

Building blocks are subsystems of any kind, including human actors and computers actors (called active structures in ArchiMate).

 

Principle 2: A building block may be coarse-grained or fine-grained

Typically, there is a composition hierarchy in which the topmost building block represents the boundary of the whole system.

The bottom level or atomic building blocks are ones that are not further decomposed in the documented architecture.

(What seems to be an atomic building block may be decomposed in a more detailed design into other building blocks.)

 

Principle 3: Building blocks <provide> services

When we look at a system or building block from the outside, we see only its boundary, what goes in and comes out.

The Open Group’s “executable standard” principle is to abstract from what is inside any structural component by defining the services it offers.

A service is “a logical representation of a repeatable activity that has a specified outcome”.

 

So, in TOGAF, building blocks interact by providing and consuming services which convey flows of information, occasionally materials also.

A building block can request a service from another a building block, or push a service to it.

Whenever a building block requests or provides a service, it conveys information/data and triggers the target building block to perform a behavior.

 

A service may be long or short.

The scope depends on the service requester’s requirements and the scope of the resources available to the service provider building block.

What seems to be an atomic service, provided by one building block, may require that building block to request services from other building blocks.

 

Principle 4: Building blocks can be specified at a logical level

In TOGAF, logical means “An implementation-independent [portable, vendor-neutral] definition."

And physical means “A description of a real-world entity” that is still “considerably abstracted from implementation“.

The approach to architecture definition in TOGAF involves specifying three kinds of element.

 

Service contracts

Architecture requirements are specified in the form of contracts for business and application/IS services.

Architecture building blocks (ABBs)

Logical components are defined by the services or flows they provide to each other and to external entities.

And sometimes also the data entities that they maintain.

Solution building blocks (SBBs)

Physical components are hired, bought or built to realise ABBs, and so deliver the required services or flows.

 

Principle 5: Services <are assigned to> Architecture Building Blocks, which are <realized by> Solution Building Blocks

The implicit generic meta model is: required services <are assigned to> logical ABBs <are realized by> physical SBBs.

The table below shows how TOGAF specialises that generic metal model in three architecture domain/layers.

 

 

Required behaviors

assigned to logical structures

realised by physical structures

 

Things that happen

Specifications of things that act (ABBs)

Things that act (SBBs)

Business

Business Services

Functions

Organization Units

Roles

Actors

IS/Applications

Application/IS Services

Logical Application Components

Physical Application Components

Technology

Platform Services

Logical Technology Components

Physical Technology Components

 

TOGAF phases A to D focus on required behaviors and logical ABBs.

However, it is normal to identify some physical SBBs at the same time.

It has been suggested the building blocks that are finally emloyed or deployed to do work are called Operational Building Blocks (OBBs).

Structure and behavior  views in UML 2.5 and TOGAF 9.1

TOGAF borrows some concepts and diagrams from UML that are commonly used in describing human and computer activity systems.

 

UML concept or diagram

TOGAF concept or diagram

Structural

views

Component

Building block (subsystem)

Class diagram

Class diagram (TOGAF means data model)

Behavioral

views

Operation

Service contract (inc. pre and post conditions, and quality measures)

Activity diagram

Process flow diagram (Process <sequences> Activities <assigned to> Roles)

Interaction diagram

Process application realization diagram (Process <uses> IS Services <provided by> Applications

Use case diagram

Use case diagram (Application <provides> IS Services <used by> Roles)

 

Structural views define things that can be employed or deployed.

TOGAF defines a building block as a package of functionality (an active structure).

It suggests using a class diagram to represent a data model (a passive structure).

 

Behavioral views define behaviors that change the state of things over time.

They address event-driven behaviors and communication between structural objects.

In UML, the basic atoms of behavior are called actions.

Actions can be sequenced in higher-level processes (state machines, activities, interactions).

In modelling software processes, actions are comparable to the executable instructions in a programming language.

In defining business roles and processes, the granularity of atomic business actions is in the gift of the modeller, and may be called an elementary business process or atomic activity.

Generic meta models in ArchiMate 3.0.1 and TOGAF 9.1

TOGAF is a sprawling, broad and diffuse management framework, which has grown in a piecemeal way.

It is about the logical architectural specification of systems at an enterprise portfolio management and/or solution architect level.

ArchiMate is relatively self-contained, defines concepts and symbols to represent them.

It is normally used at level closer to physical implementation, and so a more natural fit to specification at the solution and/or software architect levels.

However, the two standards can be aligned reasonably well, provided we are allowed bend the ArchiMate generic meta model.

TOGAF’s generic meta model

Generally speaking, a structure is a thing locatable or addressable in space (e.g. Venus, Mars...).

Below, a physical active structure is a system, subsystem, component or building block that is expected to perform behaviors.

It is an encapsulation of behaviors and other resources, which realises services by performing activities in processes.

And a logical active structure is an abstract description of one or more physical active structures, which does not itself perform behaviors.

 

Generally speaking, a behavior is a thing that happens over time and changes the state of a structure (e.g. a planetary orbit).

Below, a service is a requestable behavior that is defined by its entry conditions and exit conditions or results of value.

And a process is a sequential or procedural flow of activities, which runs from a start to an end, again producing a result of value.

 

This table uses these terms to generalize how TOGAF describes systems.

 

TOGAF

Behaviors

Active structures

Generic meta model

External

Services

Required behaviors

Internal

Architecture building blocks

Logical active structures

Solution building blocks

Physical active structures

 

TOGAF presents the external view of a system or building block in terms of services it provides.

Services are “logical representations” of “repeatable activities” or requestable behaviors.

TOGAF presents the internal view of a system (or a coarse-grained building block) as a collection of interoperating building blocks.

Building blocks are active structures or “packages of functionality” - and logical representations of them.

The table below shows how these general concepts are specialised in each of the three architecture domains/layers.

 

TOGAF

Behaviors

Active structures

Generic meta model

Business

 

 

 

External

Business Services

Required behaviors

Internal

Business processes

Roles, Functions

Logical active structures

Actors, Organizations

Physical active structures

Applications

 

 

 

External

App/IS Services

Required behaviors

Internal

Logical application components

Logical active structures

Physical application components

Physical active structures

Technologies

 

 

 

External

Platform Services

Required behaviors

Internal

Logical technology components

Logical active structures

Physical technology components

Physical active structures

 

Note that some roles and processes outside the business may also be modelled.

ArchiMate’s generic meta model – mapped to TOGAF’s

The table below shows how ArchiMate’s general concepts are specialised in each of the three architecture domains/layers.

 

ArchiMate

Behaviors

Active structures

Business

 

External

Business Services

Business Interfaces

Internal

Business Functions

Business Processes

Business Roles

Business Actors

Applications

 

External

Application Services

Application Interfaces

Internal

Application Functions

Application Processes

Application Components

Technology

 

External

Technology Services

Technology Interfaces

Internal

Technology Functions

Technology Processes

Nodes

(Devices & System Software)

 

In EA, it is important to distinguish business functions from business processes.

A business process is a sequence of activities arranged in a logical flow over time, which both UML and ArchiMate call a behavior.

A business function or role is a logically cohesive group of activities – to be assigned to and performed by organizations or actors.

 

In TOGAF, functions and roles are seen as logical building blocks, or logical structures that package some activities.

Each is an abstract description of one or more physical building blocks - organization units or actors.

Each may be defined in terms of goals, services or products delivered, behaviors performed, skills and resources required.

 

The table below bends ArchiMate’s generic meta model by repositioning functions to better fit the TOGAF meta model.

This conforms to the structure/behavior distinction drawn in UML, but differs from that in ArchiMate, which uses the same terms differently.

 

Behaviors

Active structures

ArchiMate

TOGAF

ArchiMate

TOGAF Building Blocks

Business

 

 

External

Business Services

Business Services

Business Interfaces

Internal

Business Processes

Processes

Business Roles, Business Functions

Roles, Functions (logical)

Business Actors

Actors, Organizations (physical)

Applications

 

 

External

Application Services

Application/IS Services

Application Interfaces

Internal

Application Processes

 

Application Functions

Logical application components

Application Components

Physical application components

Technology

 

 

External

Technology Services

Platform Technology Services

Technology Interfaces

Internal

Technology Processes

 

Technology Functions

Logical technology components

Nodes (Devices & System Software)

Physical technology components

 

Note that TOGAF’s core concepts do not include a term that clearly corresponds to ArchiMate’s “interface”.

TOGAF uses the term interface for a logical data flow exchanged between building blocks, and for the group of services provided by a building block.

ArchiMate’s interface is more usually interpreted as a physical channel via which data flows or services may be obtained.

TOGAF artefacts

Some TOGAF artefacts are catalogs and matrices that record architecture building blocks and services for portfolio management.

Some are diagrams that are more useful at a solution/capability increment level.

This table maps core relations to artifacts that show them.

 

Relations

Artifacts

Level

Business

Business

Functions <assigned to> Business Services

Business Function/Service Catalog

1

Functions <serve or depend on> Functions

Business Interaction Matrix

Node Connectivity Diagram (in text)

1

1

Organization units <realize> Functions

Actors <realize> Roles

Business Interaction Matrix

Actor/Role Matrix

1

1,2

Business to Applications

Business to Applications

Functions <use> Logical Application Components

Roles <use> Logical Application Components

Application/Function Matrix

Role/Application Matrix

1

1

Roles <use> IS/App Services

Application Use Case Diagram

2

Applications

Applications

Logical Application Components <assigned to> IS/App Services

Application Portfolio Catalog

1

Logical Application Components <serve or depend on> Logical Application Components

Application Interaction Matrix

Application Communication Diagram

1

1,2

Physical Application Components <realize> Logical Application Components

Application Portfolio Catalog

!

Applications to Technology

Applications to Technology

 

Logical Application Components <use> Logical Technology Components

Application/Technology Matrix

Platform Decomposition Diagram

1

2

Technology

Technology

 

Logical Technology Components <assigned to> Platform Services

Technology Portfolio Catalog

1

Logical Technology Components <serve or depend on> Logical Technology Components

Platform Decomposition Diagram

2

Physical Technology Components <realize> Logical Technology Components

Technology Portfolio Catalog

1

 

TOGAF artefacts for architecture definition can be divided into two groups.

 

Level 1: 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.

 

Level 2: 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 are products of phases E to G rather than B to D.

Business scenarios, value streams and use cases

Business scenarios, value streams and use cases are all variations on the theme of business process analysis and design.

All are tried and tested ways to develop the specification of a goal-driven process, along with the roles and resources it needs.

And all business process specification is a variation on the theme of process specification in general system theory.

 

·         The general logic for specifying system state change is the Hoare triple: {Precondition} Process {Post condition}.

·         IF the precondition is true AND the process proceeds to completion THEN the post condition will be true.

 

This universal logic underpins all methods for analysis and declaration of what business processes do.

It is applied in documenting value streams, business scenarios, use cases, service contracts and other ways to model business system behaviors.

Defining the post condition of a business process is to define a requirement, result, goal or outcome of value to the business (be it on a micro or macro scale).

 

Below, the logic of business scenarios analysis and documentation is illustrated by adapting a TOGAF 8 example.

 

TOGAF process for business scenario definition

Example based on TOGAF 8

1.      Identify, document, and rank the problem driving the scenario

The need to capture orders faster, before customer changes mind.

2.      Identify the business and technical environment

The customer’s premises, the data centre

3.      Identify and document desired objectives

Capture 15% more orders per day (see post condition of process below)

4.      Identify the human actors (participants) and their place in the business model

Customer, sales person

5.      Identify computer actors (computing elements) and their place in the technology model

Lap top and several data centre applications listed below

6.      Identify and document roles, responsibilities, and measures of success

See role activities below.

 

TOGAF template for business scenario definition includes:

·         A business process

·         The business and technology environment

·         The people and computing components (called ‘‘actors’) who execute the scenario [“actors” should be “roles”]

·         The desired outcome of proper execution

 

The following example is adapted from one in TOGAF 8.

Precondition: Sales visit agreed and scheduled

Human roles

Computer roles

Scenario (or Value stream)

Customer

Sales person

Lap top

Data centre applications

1 Initiate sales process with the customer

Open door

Greet customer

2 Discuss customer requirements

Accept sales visit

Ask about requirements

3 Work with customer to create a product configuration

Explain requirements and discuss options

Get product descriptions, assemble configurations

Use case 1

Product configurator

4 Verify desired configuration can be delivered

Select option based on capabilities

Check configuration availability

Use case 2

Inventory

Confirm interest

Get delivery date

Use case 3

Scheduling

5 Determine price of requested configuration

Accept  date

Price the configuration

Use case 4

Pricing

6 Confirm customer desire to purchase

Accept  price

Recap and ask for confirmation

7 Place an order

Confirm purchase

Enter order details, get email reply

Print out email, request signature

Use case 5

OMS

8 Capture customer signature

Sign

Confirm signature

Use case 6

OMS

Post condition: Order captured

 

One should go on to attach non-functional qualities to the process, and perhaps to each step as well.

Service contracts

The whole process above may be abstracted into a Business Service Contract with preconditions, post conditions and measurable non-functional qualities.

Each use case in it may be abstracted into an Application/IS Service Contract with preconditions, post conditions and measurable non-functional qualities.

 

TOGAF 9.1 places Business and Application/IS Service Contracts in the Architecture Requirements Specification.

The TOGAF rationale is this: The Architecture Definition Document provides a qualitative view of the solution.”

“The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria.”

Of course the services, with their measurable NFR qualities, must mapped to building blocks in the repository, and likely in the Architecture Definition also.

 

The approach to architecture definition in TOGAF is highly iterative.

A service is first named, then lightly described, and eventually defined in a service contract (input and output flows, pre and post conditions, non-functional qualities).

A service contract makes no reference to the internal workings of any building block that provides it (or other building blocks it depends on).

 

TOGAF’s ADM can be seen as a method for service-oriented architecture development.

The Architecture Continuum and Architecture Repository are populated with ABBs defined by the services they offer.

In phases B and C, Business and IS Service Contracts are recorded, and included 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 all components in the technology architecture domain/layer.

The business architecture domain/layer

The concepts of business architecture reflect the concepts of general system theory.

This table defines them independently of ArchiMate and TOGAF.

 

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 organization units.

Role

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

Physical structures (who)

things that act - perform behaviors

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

 

This table compares TOGAF and ArchiMate versions of the general concepts.

 

General concept

ArchiMate and TOGAF compared

Physical business actor

A named business entity that can be given the responsibility of realising one or more logical functions or roles.

It encapsulates behaviors and resources.

It realises services by performing activities in processes.  

ArchiMate: “Business actor: A business entity that is capable of performing behavior.”

Business actors include both people and organization units (by contrast, in UML, roles are called actors).

Note that every ArchiMate actor is a unique individual (by contrast, every software actor is a replicable individual).

 

TOGAF’s Organization Unit and Actor are both Business actors in ArchiMate.  

Logical business actor

A specification of one or more physical business actors can do.

It does not actually do anything; it is an abstract specification.

ArchiMate: Business role: The responsibility for performing specific behavior.”

A role to which an actor can be assigned, or the part an actor plays in a particular process or event.

Business function: A collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization.” 

 

TOGAF’s Role concept resembles the ArchiMate one.

A Role may be defined by services offered and/or activities (process steps) performed.

The grouping is based on chosen cohesion criteria, typically abilities or resources.

It may be mapped to actors in an Actor / Role matrix. 

 

TOGAF’s Function concept resembles the ArchiMate one.

A Function may be defined by services offered and/or activities (process steps) performed.

The grouping is based on a chosen cohesion criteria, typically one or more business capabilities.

The functional decomposition may be closely aligned to an organization’s management structure – as in a “functional organization”.

Or else, functions may be mapped to organizations in a Function / Organization matrix.  

Business service

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

A contract specifies service entry and exit conditions.

Entry: the trigger, input events or flows, and preconditions.

Exit: the output events or flows, and post-conditions.

(The post-conditions define any state change.)

ArchiMate: Business service: An explicitly defined exposed business behavior.”

Of course all architecture elements are explicitly defined by virtue of including them in a model.

The main point is that a service is defined declaratively/externally rather than procedurally/internally. 

 

TOGAF’s service concept resembles the ArchiMate one.

The Open Group principle is to abstract from the internal behaviors of active structures by defining the services they offer.

TOGAF adheres as closely to that Open Group principle as it possible to do in an abstract architectural specification.

To begin with, architects work at an abstract level; they name business services, or groups of services.

They cluster cohesive services into logical functions and roles, independent of organization units and human actors that realise them.

They further specify the requirements of business actors as business services in the Architecture Requirement Specification.

Business interface 

This encapsulates one or more business actors

The logical part defines what services the interfaces offers, with functional invocation details.

The physical part defines how to find the services offered.  

ArchiMate: ArchiMate focuses on the physical part of an interface definition.

“Business interface: A point of access where a business service is made available to the environment.”

ArchiMate’s interface is actor-bound, meaning it is a part of 1 and only 1 actor.

What if one interface may act as a facade to several (and possibly changing) business actors?

Then it should be modelled as an actor in its own right, with its own interface. 

 

TOGAF phases B to D focus on the logical services to be offered via one or more interfaces.

TOGAF’s logical business functions and roles abstract from physical organization units and actors.

A business function is mapped to the business services it provides.

Those business services define how (service name, inputs and preconditions) to logically access the behaviors of an actor.

Physical access details may be added then, or in later phases. 

Business process, and interaction

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

ArchiMate: Business process: a sequence of business behaviors.

that achieves a specific outcome such as a defined set of products or business services.”

Also: “Business interaction: a unit of collective business behavior performed by (a collaboration of) two or more business roles.”

 

TOGAF’s process concept resembles the ArchiMate one.

TOGAF suggests specifying an interaction by drawing a process flow diagram with roles in swim lanes. 

Business event

The trigger of a service or process, or for some, may be the result.

ArchiMate: Business event: A business behavior element that denotes an organizational state change.

It may originate from and be resolved inside or outside the organization.”

A process, performed by some actor(s) describes the steps resulting in that change.

An event can be the result of one process and the trigger of another (similar to BPMN’s events).

 

A TOGAF business service contract may separate the specification of events and state changes.

A contract specifies includes the input and output events of a service.

The state change resulting from the service is defined by the post-conditions (perhaps outputs also).  

The applications architecture domain/layer

The concepts of applications architecture reflect the concepts of general system theory.

This table defines them independently of ArchiMate and TOGAF.

 

General system ideas

Application system ideas

Defined in terms of software activities

Aim

Application requirement

A testable target for the outcome(s) of application activities.

Behavior (use case)

Application service

A contract defining the request for and result/outcomes of required activities.

Application process

A behavior that sequences activities from start to result.

Logical components

Application interface/boundary

A group of services offered and performable by an application component.

Physical components

Application component

A deployable unit that realises an interface’s services by performing activities in processes.

 

This table compares TOFAF and ArchiMate versions of the general concepts.

 

General concept

ArchiMate and TOGAF comparison

Physical application component 

A named software entity that can be given the responsibility of realising one or more logical application components.

It encapsulates behaviors and often encapsulates data also.

It realises digital information services by performing processes.

It may be stateful or stateless

It may or may not refer to persistent data.

ArchiMate: “An application component encapsulates behavior and data.”

 

TOGAF’s application component concept resembles the ArchiMate one.

Logical application component 

A specification of one or more physical application components can do.

It does not actually do anything, it is an abstract specification.

 

TOGAF’s logical application component might be symbolised using ArchiMate’s function or interface symbol.

This section discusses the former.

 

ArchiMate: “An application function represents automated behavior that can be performed by an application component.”

An application function is seen as a subset of the behaviors performable by an application component.

One component may have several functions, and one function might be fulfilled by several components.

 

ArchiMate’s application function symbol might be used to symbolise a logical application component.

But the two concepts are not the same, since TOGAF’s concept corresponds to a whole application or even more than one.

 

TOGAF phases B to D cluster services using purely logical cohesion criteria into candidate/logical components.

Application architects cluster IS services into logical application components (not physical application components).

In phase E, logical components are mapped to physical ones.

But even vendor-specific physical application components are “considerably abstracted” from implementation.

What if you don’t find a physical component to match your logical component?

You can draw a Logical Component / Physical Component Matrix to show a more complex mapping.

Or else, you can re-scope your Logical Component to match your chosen Physical Component.

Application service

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

A contract specifies service entry and exit conditions.

Entry: the trigger, input events or flows, and preconditions.

Exit: the output events or flows, and post-conditions.

(The post-conditions define any state change.)

ArchiMate: “An application service represents an explicitly defined exposed application behavior.”

Of course all architecture elements are explicitly defined by virtue of including them in a model.

The main point is that a service is defined declaratively/externally rather than procedurally/internally.

 

TOGAF’s concept resembles the ArchiMate one.

The Open Group principle is to abstract from the internal behaviors of structural components by defining the services they offer.

TOGAF adheres as closely to that principle as it possible to do in an abstract architectural specification.

To begin with, architects work at an abstract level; they name services, or groups of services.

They cluster cohesive services into logical components, independent of physical component that realise them.

They further specify the requirements of business functions and applications as Application/IS service contracts.

Application interface 

This encapsulates one or more application components.

The logical part defines what services the interfaces offers, with functional invocation details.

The physical part defines how to find the services offered.   

ArchiMate focuses on the physical part of an interface.

“An application interface represents a point of access where application services are made available

to a user, another application component, or a node.”

“An application interface specifies how the functionality of a component can be accessed by other elements.”

ArchiMate’s interface is component-bound, meaning it is a part of 1 and only 1 component.

What if one interface may act as a facade to several (and possibly changing) components?

Then it should be modelled as a component in its own right, with its own interface.

 

TOGAF phases B to D focus on the logical services to be offered via one or more interfaces.

TOGAF’s logical application components (defined by the services they offer) abstract from physical application components.

An application component is mapped to a set of services in the Architecture Requirements Specification.

Those IS services define how (service name, inputs and preconditions) to logically access the behaviors of a component.

Physical access details may be added then or in later phases.

Application process

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

ArchiMate: “An application process represents a sequence of application behaviors that achieves a specific outcome.”  

 

TOGAF specifies all application and technology behaviors in terms of abstract service contracts.

It does not explicitly specify internal application processes.

Application event

The trigger of a service or process, or for some, may be the result.

ArchiMate: “An application event is an application behavior element that denotes a state change.”

An event specifies what has been changed in the world by a behavior.

A process, performed by some actor(s) describes the steps resulting in that change.

An event can be the result of one process and the trigger of another (similar to BPMN’s events).

 

A TOGAF service contract may separate the specification of events and state changes.

A contract specifies includes the input and output events of a service.

The state change resulting from the service is defined by the post-conditions (perhaps outputs also).  

The technology architecture domain/layer

The concepts of platform technology architecture reflect the concepts of general system theory.

This table defines them independently of ArchiMate and TOGAF.

 

General system ideas

Technology system ideas

Defined in terms of software activities

Aim

Technology requirement

A testable target for the outcome(s) of technology component activities.

Behavior (use case)

Technology service

A contract defining the request for and result/outcomes of required activities.

Technology process

A behavior that sequences activities from start to result.

Logical components

Technology interface

A group of services offered and performable by a technology component.

Physical components

Technology component

A deployable technology that realises an interface’s services by performing activities in processes.

 

TOGAF specifies the requirements of the platform technology components as platform services in the Technical Reference Model (TRM) .

The TRM specifies what TOGAF calls the Application Platform Interface.)

 

For the rest, the comparison between ArchiMate and TOGAF closely follows that documented above – for the applications architecture domain/layer.

A few mappings

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)

Application/IS 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

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

TOGAF for enterprise architecture and for solution architecture

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

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.

 

TOGAF 9 decoupled the ADM from EA – allowing it to be used a single Solution or Capability Increment level only.

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

 

Using TOGAF at the two different levels is different.

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

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

 

Above, TOGAF artefacts for architecture definition were divided into two groups.

·         Enterprise Strategic Architecture artefacts

·         Solution or Capability Increment artefacts

 

TOGAF’s  Enterprise Continuum

TOGAF’s enterprise continuum is a two-dimensional taxonomy for classifying BB descriptions and reference models.

There are four levels, which range from ideal/conceptual to real/operational.

 

Enterprise Continuum

Level of specification

Enterprise Repository

Requirements & Context

Architecture Requirements & Service Contracts

Requirements Repository

Architecture Continuum

Architecture Building Blocks (ABBs)

Architecture Repository

Solutions Continuum

Solution Building Blocks (SBBs)

Solutions Repository

Deployed Solutions

Operational Building Blocks? (OBBs?).

CMDB + Identity Management System?

 

TOGAF 9.1 says the bottom level is the live or operational system.

You might interpret it as the CMDB that describes IT assets + the identity management system that describes organization units and actors.

 

The enterprise continuum is primarily a device for abstracting logical specifications from relatively physical specifications

The middle two levels are divided into four sections, which range from generic/universal to specific/unique.

 

Enterprise Continuum

Foundation

Common system

Industry-specific

Organization-specific

Architecture Continuum

Universal standards and models

e.g. Unix, HTML, ODBC, TRM

Reference models and patterns

e.g. III-RM, messaging patterns

ABBs in above

Reference models and patterns

e.g. PCF, SCOR, eTOM, HL7

ABBs in above

Bespoke process flows,

data structures and ABBs

Solutions Continuum

SBBs that realise the above

SBBs that realise the above

SBBs that realise the above

SBBs that realise the above

 

There is no requirement to classify enterprise repository contents using the enterprise continuum.

It does help to encourage people to consider where (in the two dimensions) they are or should be thinking.

If you do store your BBs with classifying meta data, then you can find them using the two indexes of the enterprise continuum.

If an artifact or deliverable contains ABBs and SBBs, that composite product cannot be positioned in the Enterprise Continuum; which is fine.

 

What can be documented at a logical level?

General 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

 

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

 

Mapping Logical ABBs to SBBs

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

 

TOGAF defines architecture requirements in the form of Business and IS Services.

In phases B to D, architects cluster services using purely logical cohesion criteria into candidate/logical components (not physical components).

Business architects cluster business services and/or activities into logical business functions (not organization units).

Application architects cluster IS services into logical application components (not physical application components).

In phase E, logical components are mapped to physical ones.

 

Suppose phase A starts with a request to implement a particular application (say a particular CRM system)?

You might choose to define logical IS services with that target in mind.

In effect, you start phase E early and reverse engineer abstract documentation of physical components

You can start by populate the solutions repository with the solution building block.

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

That abstract specification is what architects maintain in phase H: “architecture change management”.

 

Multiple levels of abstraction

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

 

Architecture work outside of an ADM cycle

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

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.

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, organization 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 standardization 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: Rationalization 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 components <are realised by> Physical components.

 

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.

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

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

 

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 input/event or state change,

“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 may be

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

 

See below or more on Services and  Building Blocks in TOGAF.

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

 

See below for more on Services and Building Blocks in TOGAF.

More on Services and  Building Blocks in TOGAF

 

Service specification through the ADM

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

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

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

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

 

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:          

10.  Chapter 1: Introduction: Executive summary

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

12.  Chapter 2 Core concepts:

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

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

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

16.  Chapter 6: Preliminary phase

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

18.  Chapter 37: Building Blocks

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

20.  Building blocks are encapsulated units of functionality (functions, organization 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:

21.  TOGAF preface

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

23.  Chapter 1: Introduction

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

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

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

27.  Architecture Building Blocks “describe required capability”

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

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

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

Concluding definitions of 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.

31.  Component: a building block definable by one or more services it offers to clients.

32.  Function: a logical component that clusters cohesive behaviors by some cohesion criterion other than sequence; a subdivision an organization’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.”

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.

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.