The confusing entanglement of
architecture dimensions
One of more than 200 papers at http://avancier.website Copyright
Graham Berrisford. Last updated 02/07/2016 15:41
This is one of several related papers, including:
1. The system
theory underpinning TOGAF and ArchiMate
2. Business
functions and processes in TOGAF
3. Building
blocks and services (also value streams and chains) in TOGAF
4.
Business function and capabilities in TOGAF
and VDML
5. The confusing entanglement of architecture
dimensions
6.
TOGAF and ArchiMate harmonisation.
References are to
TOGAF 9.1, ArchiMate 2.1, UML 2.4.1 and VDML 1.0.
Contents
The
relationships between components, interfaces and services
The
structure/behavior dimension (1)
The
external/internal dimension (2)
The
type/instance dimension (3)
The
logical/physical dimension (4)
Entanglement
of dimensions in practical methodologies
Footnote 1: On type and
instance
Footnote
2: The difference between “Proper Domain Models and "Concept Graphs”
Business system architects design human activity systems using models that conform to the usual presumptions about designed systems.
For example, the models describe systems in terms of structural and behavioral elements.
Behaviours run over time from start to end, or cyclically (one might add that structures occupy space).
This table draws a distinction between structural and behavioral views of a system (cf. UML p 694).
A dynamic
or behavioral
view of a
system |
Shows the behavior (of a role or interacting
roles) over time Shows actions, interactions or life histories of actors playing roles.
Describes behavior as a series of changes over time. |
A static
or structural
view of a
system |
Shows the structure of a system irrespective
of time. Shows relationships between roles. Does not detail behavior but may relate
named behaviors to roles. |
Systems are
commonly described in terms of roles,
events and behaviors
It sometimes helps to use a different label for
instances of those elements (in a run-time system) as this table indicates.
System
elements |
System description Model
types |
Operational system Real
world instances |
Structural elements |
Roles |
Actors |
Behavioral elements |
Events |
Occurrences |
Behaviors |
Performances |
Architecture frameworks and modelling languages are used to describe and design business systems.
These systems are specifiable at many levels of abstraction from high-level views down to the bottom level of atomic actions that individual actors can be asked to perform.
And they can be specified from different viewpoints, as this table illustrates.
Activity system |
Behavioral view |
Structural view |
External
view |
Events |
Interface |
Internal
view |
Actions |
Actors/Roles |
A system’s interface encapsulates actors (humans and mechanical components); these structural elements must be addressable.
External events or service requests prompt the internal actors to perform actions (operations or processes); these behavioral elements run over time.
The four-view table above is attractively simple, but open to interpretation and debate, and it can be confusing.
This paper discusses four dimensions of architecture
description; each can be confusing in its own right, and worse, they are
entangled with each other.
TOGAF divides the architecture of an enterprise into actors.
The actors are called building blocks (perhaps because they encompass human actors and technology components).
Each building block can perform one or more behaviors, on its own or in cooperation with other building blocks.
Building blocks come in several shapes and sizes: functions, roles, organization units, human actors and application/technology components.
Building blocks are defined in the manner of components that interoperate by requesting and providing services.
Each building block is definable by the service portfolio (an aggregate of discrete, singular, services) it offers to others.
A service is a repeatable activity that (if successful) ends in a desired outcome.
A service ends with a result/output/product of value to the service requester or receiver.
A service is a logical contract that encapsulates whatever process(es) are need to deliver the value required.
ArchiMate’s
definitions appear to say an interface offers one service.
“A
business interface exposes the functionality of a business service to other business roles”
“An
application interface exposes an
application service to the environment.”.
But read on, and you’ll find one interface can aggregate many services.
“A business interface may be assigned to one or more business services, which means
that these services are exposed by the interface.”
“An application
interface is the (logical) channel through which the services of a
component can be accessed.”
Further: “The same
application service may be exposed through different interfaces.” Ah,
N-to-N then!
TOGAF and ArchiMate
both define a service as a discrete unit of behavior
Both presume one
component can offer many services through an interface.
And many examples
out there do conform to those definitions.
Why not all? Perhaps because UML and others use the word service as a synonym for interface, and operation for service.
To edit paraphrase what UML says in sections 7.3.24 & 25.
“An interface is a kind of component type that represents a declaration of a set of coherent public features and obligations.
An interface specifies a contract; any instance of a component that realizes the interface must fulfill that contract.
Since interfaces are specifications, they are not instantiable, and are implemented by instance of instantiable component types.
Note that a given component may implement more than one interface and that an interface may be implemented by a number of different components.”
The set of interfaces implemented by the component are its provided interfaces and signify the set of services the component offers to its clients.
The component will have an implementation for each of operations defined by the interface.”
The term service is
now widely used to label anything and everything - an interface, a process, an
application component, a“system
software” node.
People draw a
message broker box associated 1-to-1 with a “messaging service” box, which is
to say nothing of architectural significance
They speak of
one address component offering one “address service”, when they really mean the
component offers a service portfolio..
They even speak of
components as services (e.g. speak of small applications as micro services).
In natural language,
people use same word for a singular behavior and an
aggregate structure of behaviors.
The term “process”
is used to mean a single procedure or a whole application (in Windows Task
Manager).
And the term
“service” is used mean one discrete operation, or a multi-service portfolio.
Natural language is
not controlled enough for people wanting to describe things unambiguously.
A professional modeller does not use the same word for many concepts, or several words for one concept.
And a professional modelling language discourages people from using graphical symbols a loosely as words.
System theory draws a distinction between structural and behavioral
views of a system (as does UML p 694).
A dynamic or behavioral view of a system
shows a behavior (of a role or interacting roles) over time; the actions and interactions
within a behavior run from start to end.
A static or structural view shows a system’s structure irrespective of time; it shows
relationships between roles, and may relate named behaviors
to roles.
Why do people
sometimes struggle with the structure/behavior
distinction?
Because behaviors have structures; and structures have behaviors.
A process is a structure of actions in a time sequence,
yet is called a behavior here.
A role defines behaviors actors can
be asked to perform, yet is called a structure here.
How people use words
in natural language is very loose.
Natural language can
obscure the controlled language our profession needs to define the dimensions
of architecture.
A controlled
vocabulary has to pin the meanings of terms (like structure and behavior) to even more general concepts.
Structures in space versus behaviors over time
In short: actors
occupy space; actions take time.
UML divides its
views of a system between structure and behavior diagrams.
UML structure
diagrams show element types (classes, roles, components) whose
instances are addressable, implying they occupy a position in space.
All actors, all
active components (and all passive structures/data elements) must be locatable
in space.
UML behavior diagrams show element types (use cases,
interactions, etc) whose instances run from start to end over time.
All actions
(performed by actors, acting on passive structures/data) are triggered by
events and run from start to end over time.
Structural and behavioral aggregation
An aggregate
structure takes up more space than any of the
smaller structures aggregated into the structure.
Given that a human
actor or software component occupies space, a coarser-grained aggregation of
actors or components needs more space.
An aggregate behavior lasts longer than any of the shorter behaviors aggregated into the behavior.
Given that a process
performance occupies time; a coarse-grained process must last longer than each
of its process steps.
But note, there are two kinds of behavior
aggregation – behavioral and structural.
Connecting process
steps in sequence creates a longer behavior element.
Grouping process
steps by some other cohesion criterion and assigning them to a role or
function creates a structure element.
Q) Are you just
pointing out that these terms are used in multiple ways?
A) More than that; I
am saying ArchiMate has a peculiar view of the structure/behavior
distinction.
The names of structures and behaviors
ArchiMate says: “These three aspects
– active structure, behavior, and passive structure – have been inspired by
natural language,
where a sentence has a subject (active
structure), a verb (behavior), and an object (passive structure).”
Natural language is
loose; nouns and verbs are imperfect indicators of a structure/behavior distinction.
And you can’t rely on
a thing’s name to tell you whether it is structural or behavioral.
The term “function”
is especially ambiguous.
Functionality = behavior in the broad sense. Functioning = active in the
run-time sense. So what is a “function”?
In natural language,
the function of a thing often means its purpose.
In UML, a function
is a behavior; runs over time from receiving input to
producing output, but without access to system state.
In TOGAF, a function
is a structure, a node in a logical functional/capability decomposition
structure; it does not run over time.
It can be defined as an aggregate of
related business actions (internal view) or portfolio of services offered
(external view).
The logic behind the system elements you find
in UML, ArchiMate and TOGAF
A start-to-end behavior has a structure. An active structure can be
seen as an aggregate of performable behaviors.
Confusing?
Understanding the behavior/structure distinction helps in understanding
TOGAF, even if the authors are not conscious of the logic behind what they
write (e.g. page 333 and chapter 37).
A behavior
element (a service or process) flows over time from start to end, and
terminates by delivering a result of value.
TOGAF assumes behaviors are performed by interoperating “building blocks”
in response to triggering events, messages or invocations.
Structural elements
can be divided between logical types which aggregate behavior
specifications, and physical instances which actually perform
those behaviors.
TOGAF calls these
building blocks (BBs) and further divides
the types between logical ABBs and
identifiable hireable/buyable/buildable SBBs.
The physical
instances could be called "operational building blocks";
however, TOGAF is not designed to address the grey sections of the table
below.
It allows
the naming of individual human actors and organisation units, but does not
expect an architect to identify software classes, objects or component
instances.
Structural element
types |
Structural element
instances |
|
Logical architecture
building blocks (ABBs) |
Physical solution
building blocks (SBBs) |
Physical
instances in deployed systems (which
occupy space and respond when asked to peform behaviors) |
A UML class is a logical specification
of the behaviors (operations, methods) one or
more physical objects can perform. |
E.g. A class coded in Java or C# |
An object is instantiated or deployed in
the software system of interest, along with physical resources it needs,
so it can respond to requests. |
A component
interface is a logical specification of the behaviors
(services, uses cases) one or more physical components can perform. |
E.g. A named CRM package or DBMS |
A component instance is deployed in
the software system of interest, along with physical resources it needs,
so it can respond to requests. |
A role
is a logical specification of the behaviors
(services, duties) one or more physical human actors can perform. |
Named actors |
A human actor is employed or deployed in the
business system of interest, along with the rewards and physical resources it
needs, so it can respond to requests |
A business
function is a logical specification of the behaviors (services, processes) one or more physical
organisation units can perform. |
Named organisation units |
An organisation unit is instantiated in the
business system of interest, along with the budget and physical resources it
needs, so it can respond to requests. |
TOGAF
allows the naming of
individual human actors and organisation units, but does not
expect an architect to name software objects or component instances.
ArchiMate
curiously classifies functions alongside processes, as though functions are
event-triggered behaviors.
ArchiMate
has some peculiarities that make alignment with TOGAF difficult. For further analysis, see footnote 1.
A system is a bounded collection of actors performing actions; it is separated from its external environment by an interface.
Consider the holding
of board meetings as a system.
An invitation list
defines a group of actors - a structure
of actors in different roles, who follow the agenda and interact in the board
room.
A meeting agenda
defines a time-bound sequence of actions - a behavior in which actors playing
different roles interact.
Inside the boardroom, the actors study inputs, interact, reach conclusions
and define goals and actions
Those outside see only inputs (briefs they may
help to prepare) and outputs (goals and actions) they must respond to.
Why do people find the external/internal distinction confusing?
Because
systems are composed and decomposed, formally and informally.
So, what is external
to a smaller system/component can be internal to a bigger system/component.
Still, at every
level of granularity, the external view is a specification of behaviors that encapsulates
internal actors/components that perform behaviors.
Arguably, roles and functions are more like external interface/type definitions than they are like internal actors and components.
E.g. TOGAF
aggregates required service types into service portfolios.
Each portfolio is
specification of behaviors that actors or components
inside the system are expected to perform.
TOGAF |
Behavioral
view |
Structural
view |
External view |
Service |
Service portfolios |
Internal view |
Processes |
Actors, Organization
Units & Components |
Service portfolios
are assigned to logical roles, functions and components (this is a business
principle as much as software principle.)
The TOGAF view is
perhaps better expressed as in the table below.
TOGAF |
Behavioral
view |
Structural
view |
External view |
Services |
Logical Roles, Functions & Components |
Internal view |
Processes |
Physical Actors,
Organization Units & Components |
ArchiMate classifies
elements differently; it positions functions as internal behaviors
alongside processes.
ArchiMate |
Behavioral
view |
Structural
view |
External view |
Services |
Interfaces |
Internal view |
Processes & Functions |
Actors, Roles
& Components |
ArchiMate says: “A business process
is defined as a behavior element that groups behavior
based on an ordering of actions.”
As you’d expect, the actions in a process are ordered
in a time sequence; this differentiates a process from a function.
WSDL is an interface
definition language, but confusingly calls an interface a web
service.
Each web service is a service portfolio, an aggregate of discretely-requestable services that WSDL calls operations.
A web service holds the addresses of component instances that realize
the operations.
WSDL |
Behavioral
view |
Structural
view |
External view |
WS Operations |
Web Services |
Internal view |
Component
instances addressed |
Another source of confusion
is that the external/internal distinction is relatable to either or both of the
next two distinctions.
An instance is a
particular thing that realizes or embodies the properties in a type (found in a
description or model).
Why do people find this distinction confusing? Because it is! It is very hard to get your head around it.
Board meeting is a type: it describes instances of which there may be many; it describes properties they all share.
A board meeting is an instance: it is an occurrence of the type; it has many unique properties not described in the general type.
“The ArchiMate language intentionally does not support a difference between types and instances.”
Except that does!
In ArchiMate, the actor symbol represents what might be called a singleton type, which can be
identified using an individual instance name.
You can label the actor symbol with a
role/type name (say CEO) and/or an actor/instance identity (say
CEO Joe Soap).
The types in the meta models of modelling languages are generic system description types (such as role and process).
The types in user models (such as student and application)
may be seen either as specializations of the more generic types, or as
instances of their use.
Run-time instances are
things (such as individual students and applications-in-progress) that embody
types in operational systems.
The table below is a translation of
ArchiMate Figure 1.
Level |
Model
at different levels |
Examples |
|||
1 |
A general theory |
ArchiMate's generic meta model |
Generic entity types |
Behavior element |
Active structure element |
2 |
Enterprise architecture |
ArchiMate's meta model |
Specializations or instances of level 1 types |
Business process |
Business role or actor |
3 |
Domain-specific models |
ArchiMate user's model |
Specializations or instances of level 2 types |
Sale process |
Marketing director |
4 |
Operational systems |
ArchiMate user's business systems |
Instantiation of level 3 types |
Particular sales |
Henry Miller |
The equivalent in TOGAF could be this.
Level |
Models at
different levels |
Examples |
||||
1 |
EA principles |
TOGAF's generic meta
model |
Generic entity types |
Service |
Logical component |
Physical component |
2 |
Enterprise architecture |
TOGAF's meta model |
Specializations or
instances of level 1 types |
Business service |
Function |
Organization unit |
3 |
Business-specific models |
TOGAF user's model |
Specializations or instances of level 2 types |
Brokered sale |
Sales |
Sales department |
4 |
Operational systems |
TOGAF user's business systems |
Instantiation of level 3 types |
Particular sales |
Sales people |
TOGAF distinguishes roles
from individual actors, and business functions from individual organization
units.
TOGAF |
Behavioral
view |
Structural
view |
Types |
Processes |
Roles & Functions |
Instances |
Performances |
Actors & Organization Units |
In TOGAF:
requirements <specify> service portfolios <are assigned to> logical
architecture building blocks.
Logical architecture
building blocks <are specialized or realized by> physical solution
building blocks <which are realized or instantiated by> deployed
solutions.
Phase |
Level |
Elements |
Required behavior to
built structure Types to instances |
A, RM |
Requirements |
Required Services
& Scenarios |
Behavioral types |
B,C,D |
Logical building blocks |
More required
Services & Processes Roles, Functions
& Logical Components (service portfolios) |
Behavioral types Structural types (aggregate behaviors) |
E,F,G |
Physical building blocks |
Actors,
Organization Units & Physical Components |
Specializations of structural types Instance names |
G,H |
Deployed solutions |
Instances of types |
Curiously (see footnote 1 for more)
Instances of
structure elements are usually called physical, and are sometimes named in
models.
Instances of behavior elements are usually called logical, and are
well-nigh never named in models.
The UML standard takes care to
distinguish types from instances using different words.
Yet it still manages
to blur structural types and instances by equating actor with role.
ArchiMate doesn’t officially draw a type/instance
distinction.
Nevertheless,
at least some of the types in a system description must be instantiated as
actors in an operational system.
And
some ArchiMate sentences mean different things depending on whether the words
apply to types or instances.
Why do people find the logical/physical distinction confusing? Because there are countless interpretations of it.
A
classic four-level idealisation hierarchy is: conceptual <abstracts from> logical <abstracts from> physical <abstracts from> real.
The
terms conceptual, logical and physical are often used to label three
increasingly elaborate specifications of things to be deployed.
But
there are many different interpretations of what each level means and is used
for.
In network engineering, logical/physical means software/hardware.
In database design, logical/physical means normalised for integrity/structured for performance.
Enterprise data architects have their own domain-specific interpretations.
Here is
a reasonably conventional way of distinguishing conceptual, logical and
physical, much as in TOGAF.
Idealisation hierarchy |
Notes |
Conceptual model |
Specifies
business processes and/or data in a computing-independent way. It need not
be related to any particular computer, application or database, but may be
reversed engineered from or related to them. |
Logical components |
Abstract roles,
functions, application and technology components (envisaged or observed). Components are encapsulated
and defined by a service portfolio (and sometimes a data model) along with
non-functional requirements. They are not explicitly related to any vendor or technology product
choice, but may be reversed engineered from or related to specific products |
Physical components |
What is hired, bought or built to realize the logical
specification; may be vendor or technology-specific. Named actors,
organization units, data/application/technology component types and
instances. Their specifications include actual non-functional attributes, costs,
configuration and deployment requirements. |
Deployed solutions |
The actors
and components of the operational system, configured
and deployed to perform actions as specified above. |
In TOGAF (and in TOG more widely) logical primarily means vendor/technology neutral specification of components by service portfolios.
Logical
roles are realized by physical actors; logical components are realized by more
physical components.
A
logical business function/capability decomposition structure is realized by a
physical organization structure.
A “functional
organization structure” is an organization structure that matches a logical
functional/capability decomposition.
You might think of a
business capability as a purely logical function, or as the one or more
organization units that realize the function.
ArchiMate doesn’t explicitly draw a logical/physical
distinction.
Likely because it does draw behavior/structure and external/internal distinctions, both
of which can be interpreted as logical/physical.
And it (sadly) ducks drawing a type/instance distinction,
which is also interpretable as logical/physical.
TOGAF is centered on dividing a system into components (structures)
defined by the services (behaviors) they provide.
It doesn’t feature
the term “interface”, but does specify logical building blocks by defining
their "service portfolios”.
Outside of the
business domain, TOGAF does not expect architects to detail internal processes.
Its core architecture description elements can be
classified using three dimensions as shown below.
TOGAF |
Behaviors |
Structures |
|
External |
Business Services IS Services Platform Services |
(Service Portfolios) |
|
Internal |
Business
Processes |
Business Functions, Roles Logical Application Components Logical Technology Components |
Logical Building Blocks |
Organisation Units, Actors Physical Application Components Physical Technology Components |
Physical Building Blocks |
ArchiMate elements
can be classified in a similar way; read “TOGAF and ArchiMate
harmonisation” for more.
TOGAF starts with analysis
of the business/human context, so there is a business to technology sequence
(left to right below).
In each architecture
domain, it starts by defining required services in the requirements
specification.
It then proceeds by
defining structural building blocks, first at logical level and then at a
physical level (top to bottom below).
This table arranges
these two sequences in a way that that shows correspondences between concepts
in different architecture domains.
TOGAF level |
Business
domain |
Information
systems domain |
Technology
domain |
|
Requirements |
Event, Business Service, Product |
Info/Data Entity |
Appl/IS Service |
Technology Service |
Logical building blocks etc. |
Function, Role, Process |
Log Info Component |
Log App Component |
Log Tech Component |
Physical building blocks |
Organization Unit,
actor |
Phys Info Component |
Phys App Component |
Phys Tech Component |
The business to
technology sequence is one of several sequential threads; others include
baseline to target and generic
to specific.
This paper suggests
sequences from 1) required behavior to built
structure, 2) external to internal, 3) types to instances and 4) logical to
physical.
TOGAF’s architecture
development method can be seen as interweaving
all these sequences.
The table below
squashes several dimensions into a two-dimensional table, but the dimensions
cannot be perfectly aligned.
Phase |
Level |
Elements |
External to internal |
Required behavior to
built structure Types to instances |
Logical to physical |
A, RM |
Requirements |
Required Services
& Scenarios |
External view |
Behavioral types |
Conceptual? |
B,C,D |
Logical building blocks |
More
required Services & Processes Roles,
Functions & Logical Components (service portfolios) |
External view Internal view |
Behavioral types Structural types (aggregate behaviors) |
Conceptual? Logical |
E,F,G |
Physical building blocks |
Actors,
Organization Units & Physical Components |
Internal view |
Specializations of structural types Instance names |
Physical |
G,H |
Deployed solutions |
Instances of types |
Real |
It doesn’t seem
right to say required services and scenarios are conceptual, since they have physical
qualities and may deliver physical products.
The logical/physical
distinction drawn in TOGAF is mostly intended to encourage vendor-neutral
specification of business and IT systems.
This is one of more
than 200 papers at http://avancier.website.
This footnote grew so large, and so dominated by questions about ArchiMate, it has been removed from here into a paper in on its own.
“Things the next ArchiMate standard might address”.
Most notably, this paper expands on the discussion of types and instances.
It also explains discrepancies between ArchiMate’s graphical meta models and its Relationship Table appendix.
And why it is meaningless to think of a collaboration as an instance, but OK to think of it as an N-way association relationship.
Domain
models (including those in international standards and books) are often drawn
using UML class diagram notations.
Those class diagrams often feature class hierarchies, and show association
cardinalities that imply questionable 1-1 associations.
But in human affairs (rather than in mathematics) the passage of time undermines class hierarchies
And cardinality constraints on relationships need to account for the full life span of persistent entity instances.
Software
designers often model objects that live only a short time in memory (perhaps
reflecting data in a small view of a larger database).
Their
code may be built around an aggregate entity (say an on-line shopping basket)
that lives for only seconds or minutes.
They may
be careless about the specifying the cardinality on association relationships,
because it has no impact on their implemented software.
The passage of time undermines class hierarchies in models of persistent business entities.
E.g. you may start out by classifying every person as either a man or a woman.
But over time, sex changes turn these “types” into “states”
of a person.
Within
a system generation - one object may change from one type to another.
Between
system generations - a type/class hierarchy is often revised – implying
persistent entities must be re-classified.
The
result is that specialization relationships are less common in models of
long-lived entities in business domain models.
To specify the cardinality of associations requires some life history analysis.
Associations between
types in a model at level N should be labelled to specify how
instances at level N+1 are related.
The rules constraining association relationships between entity types in model apply to instances of those entities.
Business
database designers understand this well, because it has an impact on the birth
and death of persistent entities.
E.g. a
mandatory 1-N association between entity types A and B implies start-of-life
constraint on the existence of instances of type B (A must exist).
It may
also imply an end-of-life constraint on instances of type A (all Bs must have
died already).
Other
modellers think of object instances at a moment in time, they don’t think how
time turns 1-to-1 associations into 1 to N, or N-to-N.
They aren’t taught how to analyse association cardinalities, and don’t worry
about them.
They
may not even realize cardinalities apply to objects/instances rather than
classes/types.
So they are careless in drawing domain models; they
·
draw composites in place of aggregates,
and aggregates in place of associations
·
draw 1-to-1 associations in place of
1-to-N, and 1-to-N in place of N-to-N
·
draw an
N-to-N association that hides a link entity important to the domain.
·
draw one association relationship
between two entities where there are two or more different associations
·
completely omit
some important associations.
The trouble is that the resulting domain model is not a true
reflection of the real-world business domain.
Safer, call it a cartoon, or an informal "concept
graph", and leave the cardinality of associations unspecified.