THIS
PAPER HAS BEEN MOVED.
Click
here for the revised paper.
THE
LAST VERSION PUBLISHED HERE IS BELOW.
The confusing entanglement of architecture
dimensions
One of more than 200 papers at http://avancier.website Copyright
Graham Berrisford. Last updated 12/06/2016 20:28
This paper is one of five related
papers:
1. Coordinating
structural and behavioral views of a business (UML, VDML and TOGAF)
2. TOGAF
building blocks and services – value streams and chains
3.
TOGAF and VDML compared (function and
capability)
4. The confusing entanglement of architecture
dimensions
5.
Things the next ArchiMate standard might
address
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 (including why I get confused)
Footnote
2: The difference between “Proper Domain Models and "Concept Graphs”
Business system architects design human activity systems using models
The model conform to the usual presumptions about designed systems.
For example, the division of systems between structural and behavioral elements.
This table draws a distinction between structural and behavioral views of a system (cf. UML p 694).
A structural view or diagram |
A behavioral view or diagram |
Shows the
static structure of system irrespective
of time. Shows how
system components are related. Does not
show details of dynamic behavior. But may
relate behaviors to components. |
Shows the
behavior of a component or interacting components Shows
component actions, interactions and life histories. Describes
dynamic behavior as a series of changes over
time. Proceeds
from start to end. |
A presumption is
that a system can be described in terms of roles,
events and behaviors
It is arguable that instances of those things
in a run-time system should be named differently, 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.
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.
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 this distinction confusing? Because there are countless interpretations of it.
To keep it simple, you might say all system views and elements are logical, bar the addressable actors and components.
Activity system |
Behavioral view |
Structural view |
|
External view |
Services |
Interfaces |
Logical view |
Internal view |
Processes |
Actors /
Components |
|
Logical view |
|
TOGAF doesn't speak in
terms of interfaces, and outside of the business domain it ignores internal
processes.
It does however
encapsulate the required (physical) components by defining them in terms of
"service portfolios".
(Or
in the case of data components, by defining a logical data model for
the encapsulated data structure.)
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 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.