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
TOGAF’s
two implicit principles
Structure
and behavior in UML 2.5 and TOGAF 9.1.
Generic
meta models in ArchiMate 3.0.1 and TOGAF 9.1
Business
scenarios, value streams and use cases
The
business architecture domain/layer
The
applications architecture domain/layer
The
technology architecture domain/layer
TOGAF
for enterprise architecture and for solution architecture
Things
that hinder understanding and harmonization of ArchiMate with TOGAF
How
TOGAF and ArchiMate define “service”.
How
TOGAF defines “building block”
More
on Services and Building Blocks in
TOGAF
Concluding
definitions of behaviors and structures
“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 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).
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.
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.
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.
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.
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 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.
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 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 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 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.
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.
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 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.
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.
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).
“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.
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.
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.
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.”
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.
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.
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.