Harmonising two conceptual frameworks
for EA
Mapping TOGAF® to ArchiMate® (aka
terminology torture)
One of about 300 papers at http://avancier.website. Copyright
Graham Berrisford. Last updated Saturday, 14 July 2018
A comprehensive enterprise architecture (EA) framework, for the architectural design and planning of large-scale changes to business systems, should provide both processes and products.
The Open Group develops open standards with a view to enabling the efficiency, effectiveness, portability and interoperability of business systems.
Two of their standards are intended to assist enterprise architects.
TOGAF is a wide-ranging management framework for
architecture-intensive work.
It is best known for its process, the Architecture Development Method
(ADM).
It also offers a menu of products (deliverables and artifacts)
architects may find helpful.
It classifies
artifacts into catalogs, matrices and diagrams.
It does not
include a language drawing the diagrams.
ArchiMate is more
limited in its scope
It is a
modelling language for drawing diagrams that represent the structures and
behaviors of business systems.
People
naturally assume the two standards can be married together.
The
difficulty is that the bride and groom come from different families, with
different cultures.
To put it
simply: ArchiMate tries to present a coherent and consistent conceptual
framework, using a tightly controlled language.
TOGAF tries
to embrace all terms and concepts that its authors have found useful in
practice, resulting in some terminology torture.
However, you can find a coherent conceptual framework within the TOGAF standard; and it is close to conceptual framework of ArchiMate.
If TOGAF is to maintain its own conceptual framework, it needs to be exposed more clearly, and change requests be reviewed against it.
(This paper includes material
from papers at http://avancier.website copyright ©
Avancier Ltd, and three diagrams from the ArchiMate version 3.0.1 standard,
Copyright © The Open Group, All Rights Reserved.
TOGAF and ArchiMate are registered trademarks of The Open
Group.)
Contents
Service-orientation
in the TOGAF standard
Abstraction
in the TOGAF standard
The
generic meta model that underpins ArchiMate
Mapping
terms in the two standards
“Business planning at the strategy level
provides the initial direction to Enterprise Architecture”. (TOGAF Ch. 5)
TOGAF says the “non-architectural inputs” from business planning include “business strategy, business principles, business goals, and business drivers”.
The business context for EA also includes stakeholders who have an interest in whatever changes an architect is engaged to design and plan.
Both TOGAF and ArchiMate assume architects start by capturing and recording business directions.
ArchiMate includes symbols for drawing diagrams to describe the context or motivation for EA.
TOGAF includes an artifact designed to record the relation in this table.
|
Driver/Goal/Objective
catalog |
Drivers |
<stimulate> |
Goals |
<are decomposed into> |
Objectives |
Both TOGAF and ArchiMate are service-oriented.
Both presume architects should start by defining business services to support goals and objectives.
TOGAF includes an artifact to show the relation in this table.
|
Goal/Objective/Service
diagram |
Goals |
<are decomposed into> |
Objectives |
<are met by provision of> |
Services |
Note that measures assigned to services (e.g. response time) may well reflect measures assigned to objectives (e.g. to speed up a business process).
This paper is not concerned with board-level business planning.
The focus below is on the business system planning that needs to be done in response to business planning
“EA structures
the business planning into an integrated framework that regards the enterprise
as a system or system of systems.” (TOGAF Ch. 5)
A business system is a social activity system in which the roles and rules are
formalised.
This means that actors act in
response to defined messages, in the light of defined memories, according to
defined business rules.
It is also what is known as a discrete
event-driven system.
Architects model business operations in terms of events that trigger actors (active structures) to perform repeatable activities (behaviors).
An event is often input to a system in the form of a data flow.
It may instead be a time event, or a state change inside a system.
An event triggers an active structure to perform a particular behavior, in the light of the current system state.
Events often carry data that influence the behavior to be performed.
Active structures go by many names, including actor, organization unit, component, module and node.
An active structure may be encapsulated by an interface that lists the services it can perform, in response to events.
Relatively logical active structures (like role, business function and logical component) specify what relatively physical active structures (like actor, organization unit and physical component) can do.
Behaviors go by many names, including process, scenario, value stream, use case, service and operation.
A behavior runs from an event-triggered start to an end, which may be specified at two levels:
· One or more products (output flows and/or system state changes).
· One or more desired results to be met by users of those products (see footnotes).
A behavior may fail; but if its preconditions are met, and it completes, then its post conditions will be met.
That is to say, it will produce whatever products it is designed to produce.
Following which, users of those products may use them to meet some higher or longer term goal or objective.
Two behaviors can collaborate by communication, and one can invoke the other.
However, a behavior cannot perform another behavior; you need an actor
to perform an activity; you need an active structure to perform a behavior.
Long behaviors are divided into
shorter ones assignable to actors
A service is a behavior exposed at the interface of a system or component thereof.
It may update or change the internal state of the system.
It may “add value” by progressing an artifact or activity.
It may consume and produce external I/O flows that contain passive structures.
·
IS
services consume and produce flows of data (messages if you like).
·
Business
services consume and produce flows of data and materials (products if you like).
A service is definable by a contract that defines the inputs, outputs, rules and quality measures of a service.
It encapsulates the one or more processes (in one or more components) needed to complete the service.
A passive structure is a structure that does not act, but is acted on.
It can be a material or data structure.
A data structure may be conveyed in transient input or output data flow, or stored in persistent data component.
(Note that an active structure may be passive in some contexts, when being moved or deployed somewhere.)
To recap, key points in a generic conceptual framework for EA are:
· EA is about business system planning.
· Business systems are designed to meet business goals and objectives.
· A business system is a structure of interoperating components.
· A service is unit of behavior, defined as an external user sees it.
· A component is a unit of active structure, which may be defined logically and/or physically.
· Logical components are realized by physical components.
The Open Group develops open standards with a view to enabling the efficiency, effectiveness, portability and interoperability of business systems.
Their overarching vision is called Boundaryless Information Flowtm.
And their general principle is that
standards should be based on “executable
specification”.
This means specifying a system by defining the behaviors it is required to perform, and their results.
TOGAF applies this general principle
to the specification of business systems.
TOGAF defines the
architecture of a system as a set of interoperating components that interact, to perform the behaviors required of that
system, by providing services to each other.
TOGAF’s many authors use terms differently.
For example, some use the terms “building block” and “component” as synonyms, others use the term “building block” more loosely, applying it to any element of architecture description.
This section fixes the meanings of some terms for the purposes of this paper.
The unit of behavior is a service
A service is a required behavior or unit of work (the same
meaning as in ArchiMate).
A service is defined as a service requester sees it.
A service is a logical representation of a repeatable
behavior that has a specified result.
A service may be short (retrieve customer address) or long (deliver a package).
The scope depends on what the
requester wants and the resources available to the service provider.
A service is realised by one or more components performing
one or more processes.
The unit of
structure is a component (aka
“building block” aka “active structure”)
A component is a subsystem or actor of
any kind, including human and computer actors.
A component may be coarse-grained or
fine-grained.
A component can realise one or more services, either on its
own or in collaboration with others
A component can play the client role of service requester and/or server role of service provider.
A component requests
a service by sending a message
that identifies the service to be performed.
(Less commonly, it pushes a
service when triggered by a time event or system state change event.)
Architecture description is based on a
generic relation
A simple relation
underpins the artifacts used in TOGAF to define a business system.
Required services <are assigned to> Logical Components <are realized by> Physical Components.
Logical
means “An implementation-independent definition", one that is portable and supplier-neutral.
Physical
means “A description of a real-world entity”, but although physical
components are more physical than logical ones, they are still
“considerably abstracted
from implementation“.
Architecture description elements are
classified using the “Enterprise Continuum”
The Enterprise Continuum classifies component specifications in two dimensions.
· Left to right: from generic or universal, to specific or unique to an organisation.
· Top to bottom: from logical to physical to real, as shown below.
|
Requirements
and context Required Services |
Architecture
Requirements Specification includes Business and Application/IS Service contracts. |
|
Architecture
continuum Architecture Building Blocks |
Logical Components are defined by the services they provide
to each other and to external entities, also by the abilities and data
resources they need. |
|
Solution
continuum Solution Building Blocks |
Physical Components are procurable; they can be hired, bought
or built to realise Logical Components, and so deliver the required Services. |
|
Deployed
solutions Operations |
The real world components employed or deployed to
do work at run-time (which might be called Operational Components). |
TOGAF phases A to D focus on defining required
services and logical components.
However, it is normal to identify some physical
components at the same time.
The generic relation has been a little obscured by changes to the TOGAF standard in recent years.
Still, it makes sense.
It enables TOGAF to be read as a coherent and consistent standard.
And knowing it helps readers recognise where some authors use core terms in different ways.
The table
below expresses the generic relation in two different ways.
It shows the
specialisation of that generic relation in the business, applications and
technology domains, recorded using different artifacts.
|
Generic |
Required behaviors |
<clustered and assigned to> |
Logical Active Structures |
<realised by> |
Physical Active Structures |
|
TOGAF
9 artifacts |
Services |
<clustered and assigned to> |
Logical Components |
<realised by> |
Physical Components |
|
Business Service/Function catalog |
Business Services |
Functions |
Organization Units |
||
|
Role catalog + Actor/Role matrix |
Activities (in processes) |
Roles |
Actors |
||
|
Application portfolio catalog |
IS Services |
Logical Application
Components |
Physical Application
Components |
||
|
Technology portfolio catalog |
Technology Services |
Logical Technology
Components |
Physical Technology
Components |
The artifacts
mentioned in the table above connect the three elements shown.
Other
artifacts (some listed below) define other attributes and relationships of the
same elements.
The service to component relationship
A service is “a repeatable activity that a building block
may be requested or otherwise triggered to perform.”( TOGAF Ch. 3)
TOGAF encourages architects to assign the responsibility for one service
to one component (at least in the logical specification), and to minimise
duplication of service provision by different components. However, a component
can delegate work to other components. So, generally, one component may provide many services, and
one service may be provided by many components.
The logical component to physical
component relationship
In the
application and technology domains, the ideal is a 1-to1 relation:
·
one Logical Application Component is realised by
one Physical Application Component.
·
one Logical Technology Component is realised by one
Physical Technology Component.
In practice, the relationships may be more complex, or logical
components may be reverse-engineered to keep the relationship simple.
In the
business domain, there are artifacts to capture the many-to-many
logical-to-physical relationship .
|
Function/Organization matrix |
N
Functions |
<are realised by> |
N Organization Units |
|
Actor/Role matrix |
N
Roles |
<are realised by> |
N Actors |
The generic meta model is simplified for discussion in this paper. It is a grid with two dimensions.
|
ArchiMate terms |
Behavior element |
Active structure element |
|
External element |
Service: an explicitly defined exposed behavior |
Interface: a point of access where one or more
services are provided to the environment |
|
Internal element |
A unit of
activity performed by one or more active structure elements (e.g. process). |
An entity that
is capable of performing behavior (e.g. component). |
One dimension distinguishes active structures from the behaviors they perform.
·
Active structures (e.g. Butlers) perform
behaviors (e.g. polish shoes).
·
Behaviors cannot perform behaviors – that
would undermine the structure/behavior dichotomy.
·
Processes cannot perform processes,
but they can invoke processes, directly or via exposed services.
The other dimension distinguishes the external or client view of a system from how it works internally.
Since systems can be nested (recursively composed and decomposed) the external to internal boundary is a matter of choice or design.
In a “green
field” scenario, a recommendation is to design from out to in, from external to
internal:
·
define
services to be provided by a system (A) with minimal regard to its internal organization.
·
divide
that service portfolio into interfaces for different external service
requesters
·
divide
that service portfolio into service bundles for assignment to internal
subsystems AA, AB etc.
·
either
assign one external service to one internal subsystem (which may delegate to
others), or introduce a broker to orchestrate internal subsystems to provide
that service.
Recursively,
you can now define services to be provided by subsystem AA with minimal regard
to its internal organization.
And so on,
until you identify where a suitable subsystem or component exists, or can hand
over design to another, or are listing “atomic activities” presumed to be
performable without further definition.
System design
always requires some insight into what is achievable, with some regard to the
internal abilities and resources of a
system.
You don’t ask
your dentist to sell you cheese.
You don’t
expect your customer relationship management system to report which stock
levels are low in a particular warehouse.
Note that
services can be “bigger” than components.
Components
can be big or small, services may be long or short; both can be composed and
decomposed.
And to
provide one service, a component may delegate work.
So, one long
service (e.g. package delivery) may require the participation of very many
components in a business (e.g. a logistics company).
The table below maps terms used in ArchiMate to terms used
in TOGAF.
|
Required behavior Has entry conditions (trigger, inputs and ppreconditions) and exit conditions (outputs and post-conditions). |
Logical active
structure An abstract specification of what one or more physical actors can do. |
Physical active
structure Has abilities and resources. It realises services by
performing activities in processes. |
||||
|
ArchiMate |
TOGAF |
ArchiMate |
TOGAF |
ArchiMate |
TOGAF |
|
|
Business |
Business service |
Business service |
Business Function |
Function |
Business Actor |
Organization Unit |
|
Business process |
Process |
Business Role |
Role |
Actor |
||
|
Applications |
Application service |
IS service |
Application Interface |
Logical application component |
Application Component |
Physical application component |
|
|
Application Function |
|||||
|
Technology |
Technology Service |
Technology Service |
Technology Interface |
Logical technology component |
Node |
Physical technology component |
|
|
Technology Function |
|||||
TOGAF
encourages architects to specify systems at portfolio management and solution
architect levels.
ArchiMate is often used at level of work that is closer to physical implementation, and so a more natural fit to specification at the solution and software architect levels.
Some terminology torture:
·
A Web Service is an Interface Definition,
which contains a Service Portfolio in
TOGAF terms.
·
A Web
Service Operation is an Application/IS Service in ArchiMate and
TOGAF terms.
·
A Micro Service is an Application Component in ArchiMate and TOGAF terms.
Compare ArchiMate’s generic meta model:
|
ArchiMate terms |
Behavior element |
Active structure element |
|
External element |
Service: an explicitly defined
exposed behavior |
Interface: a point of access where one or more
services are provided to the environment |
|
Internal element |
A unit of activity performed by one or
more active structure elements (e.g. process). |
An entity that
is capable of performing behavior (e.g. component). |
With TOGAF’s generic relation:
|
Services |
<clustered and assigned to> |
Logical Components |
<realised by> |
Physical Components |
Process
In both standards, a process is a sequence of stages or steps that leads to a result of value.
Service
In both standards, a service is a behavior that can be requested of a system (e.g. Replace battery, Replace exhaust, Annual service, Remove tooth), defined without regard to internal procedures required.
In system operation, a service does involves the performance of one or more processes by one or more components within a system.
But in describing that service, the internal procedures and component structure should be hidden as far as possible.
A service can be short or long.
Its performance may involve the performance of many shorter subordinate services.
E.g. “Build a house to this plan” is a big/long service; it might take a year, and involve much delegation of shorter services to many third parties.
In your local bar, the much smaller “serve customer” may be decomposed into subordinate services: “take order”, “serve product” and “take payment”.
Of course you can model “serve customer” as composite or sequence of the other three smaller/shorter services.
Or model it as invoking or orchestrating the other three services.
But that is to disrespect the external/internal division in the ArchiMate generic meta model.
The SOA principle is to define a service explicitly by its entry conditions and exit conditions with minimal reference to internal procedures and structures.
So, you define “serve customer” as an external view of the end-to-end behavior, hiding processes that realise it and subordinate services that are invoked.
Then, you can not only re-sequence the internal procedure, but also restructure the internal components and whatever services they delegate to.
If services are not distinguished from processes, there is no point having both concepts.
·
A component can perform services, or more
accurately...
·
A component can perform processes, both to
realise services and to invoke other processes, directly or via exposed
services.
·
When component A uses (aka delegates to)
component B, a process performed by component A invokes a process performable
by component B.
·
The invocation must both locate component B
and identify the required process, directly or via an exposed service (Jeeves,
polish my shoes).
·
Services can neither perform services
or processes nor invoke them, because services are “logical
representations” (TOGAF 9.1), defined declaratively, with no awareness of
processes that realise them or any services those processes invoke.
Compare ArchiMate’s generic meta model:
|
ArchiMate terms |
Behavior element |
Active structure element |
|
External element |
Service: an explicitly defined exposed behavior |
Interface: a point of access where one
or more services are provided to the environment |
|
Internal element |
A unit of
activity performed by one or more active structure elements (e.g. process). |
An entity that is capable of
performing behavior (e.g. component). |
With TOGAF’s generic relation:
|
Services |
<clustered and assigned to> |
Logical Components |
<realised
by> |
Physical Components |
Component
In both standards, components are the things that do work.
Components perform processes to provide services (or they are logical specifications of such components).
Interface
An interface is a complex
architectural entity type that has both logical and physical aspects.
There are:
·
logical interface definitions (Menus, SLAs, Web page designs,
WSDL-defined web service operations) in which services are defined.
· physical channels or mediums (Waiters, Telephones, Computer Screens, WSDL-defined addresses) via which services can be requested and delivered.
TOGAF presumes a component can defined logically by a service portfolio, which is a collection of services grouped using criteria such as customer experience, abilities or resources needed.
It speaks of components or“building blocks” having “published interfaces, but elsewhere its uses the term interface loosely.
In ArchiMate, an interface has both logical
and physical aspects.
In business architecture examples, the interface symbol is often used to represent a physical channel or medium.
In the application layer it is more often used to indicate an interface that is defined by logical services or operations offered, before relatively physical protocols and end point addresses are defined.
In TOGAF, the logical definition is the first concern.
You define business goals and objectives, and then define business services to meet them.
You group business services into bundles for a) presentation to requesters and b) provision by business functions (logically) and organization units (in reality).
Similarly, you may bundle activities into a group performable by one business role (logically) or actor (physically).
Compare ArchiMate’s generic meta model:
|
ArchiMate terms |
Behavior element |
Active structure element |
|
External element |
Service: an explicitly defined exposed behavior |
Interface: a point of access where one or more
services are provided to the environment |
|
Internal element |
A unit of
activity performed by one or more active structure elements (e.g. process). |
An entity that
is capable of performing behavior (e.g. actor or business role). |
With TOGAF’s
generic relation:
|
Required behaviors |
<clustered and assigned to> |
Logical Active Structures |
<realised by> |
Physical Active Structures |
|
Activities (in
processes) |
Roles |
Actors |
Role
“A business role is the responsibility for performing specific behavior”. (ArchiMate)
TOGAF’s role has the same meaning.
Simply put, a business role is a collection of behaviors that are grouped because they can be performed one actor with the necessary abilities.
You might
speak either of behaviors, or of the responsibility for performing behaviors,
but when documented, they look the same.
A role (as in the script of a film, a play or a symphony) defines behaviors that actors playing that role are expected to perform.
The role does not perform behaviors; it only specifies behaviors to be performed.
It is an abstraction, a type.
An instantiation of that type is not an actor, it is the performance of some or all behaviors associated with the role by an actor.
The actor is the instantiator rather than the instantiation.
A role name is a type name – a general name given to each instantiation.
The role definition defines the behavior types an actor playing that role is responsible for.
It may also define abilities and resources an actor needs to perform the role.
Actor
“A business actor is a business entity that is capable of performing behavior.” (ArchiMate)
TOGAF’s actor has the same meaning.
In the most straightforward interpretation, an actor (e.g. ABC inc.) is an individual
human or organization unit.
Using individual actor names is probably best reserved for roles played by very stable actors and important stakeholders.
In a goods receipt process model, rather than name an individual actor (ABC inc.) you’d probably better name the role played – perhaps Supplier.
In a budget approval process, there might be only one approver (Joe Ledger), but even then, you might better name the role played - Finance Director, or Budget Approver.
In the example below, note that saying an organization unit is “composed of” the actors is misleading, since those same actors may play other roles in other organizations.
ArchiMate
example 22 http://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc489946043
|
ArchiMate terms |
Behavior element |
Active structure element |
|
External element |
Service: an explicitly defined exposed behavior |
Interface: a point of access where one or more
services are provided to the environment |
|
Internal element |
A unit of activity performed by one or
more active structure elements (e.g. process). |
An entity that
is capable of performing behavior (e.g. component). |
Process
“A business process represents a sequence of business behavior” (ArchiMate)
In TOGAF similarly, a process (Sell product, Send message) is a sequence of activities, usually connected in a diagram by trigger arrows.
Function
“A business function is a collection of business behavior based on a chosen set of criteria” (ArchiMate)
In TOGAF similarly, a function (Sales, Messaging) is a logical group of activities; functions are usually connected in a diagram by flow arrows.
In TOGAF however, a function is a “package” rather than “unit” of functionality.
It is a collection of behaviors grouped according to criteria such as customer experience, abilities or resources needed.
It is related in the service/function catalog to a collection (portfolio or bundle) of business services.
It can be seen as a logical organization unit, and may be mapped to one or more real organization units in an organization/function matrix.
Beware! ArchiMate standard examples of the function symbol (examples 23, 27 and 30) appear to show processes.
This might be explained and justified as compatible with other standards, but can mislead people about the function/process distinction in TOGAF.
ArchiMate
example 23 http://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc489946043
More terminology torture
Process is a generic term, used in most applications of system theory, for any level or length of process.
In some specific business analysis methods, the term value stream is used for a specific kind of process.
Compare ArchiMate’s generic meta model:
|
ArchiMate terms |
Behavior element |
Active structure element |
|
External element |
Service: an
explicitly defined exposed behavior |
Interface: a
point of access where one or more services are provided to the environment |
|
Internal element |
A unit of
activity performed by one or more active structure elements (e.g. process). E.g. Business Function? |
An entity that
is capable of performing behavior (e.g. component). |
With TOGAF’s generic relation:
|
Required
behaviors |
<clustered and assigned to> |
Logical
Active Structures |
<realised by> |
Physical
Active Structures |
Behavior
In general system theory and UML, behaviors are services or processes than run over time.
ArchiMate has a different view, that all groupings of activities are behaviors.
Structure
The active structures and components in models are types.
A type is an abstraction, it cannot do anything; it can only describe what an instance of that type can perform.
In TOGAF, some types (ABBs) are more abstract, more logical, more idealised, further removed from run-time instances, than other types (SBBs).
ArchiMate classifies functions as behavior because they group activities.
However, all active structures group activity types at design or description time.
And by the same reasoning, business roles and physical application components could be classified as behavior.
A business role is a grouping of behavior types
A role is designed by grouping activities an actor can perform (as shown seen in diagrams that associate a role with a service or process.) Behaviors are grouped using criteria such as abilities or resources needed.
Real world actors instantiate roles by performing behavior instances at run time.
A physical application component is a grouping of behavior types.
An application is designed by grouping use cases, services or operations an instance of it should perform.
Behaviors are grouped using criteria such as data or technology resources needed.
Deployed applications perform behavior instances at run time.
A function is a grouping of behavior types
A function is designed by grouping services or activites that an organisaiton should perform.
Behaviors are group using criteria such as customer experience, or abilities or resources needed.
The activities-to-business function relationship is seen in diagrams that associate a function with a service or process.
Real-world organization units instantiate functions by performing behavior instances at run time.
In TOGAF terms, business functions are logical active structures.
And a functional decomposition is a logical organization structure.
True, in a “functional organization”, the functional decomposition looks like the real-world management structure, but one may change without the other.
More terminology torture
You might
speak either of a function, or of a capability to perform a collection of
behaviors, but when documented, they look the same.
Functional decomposition diagrams are usually, if not always, indistinguishable from business capability maps.
Such terminology variations lead to the creation of parallel vocabularies and parallel artifact sets.
In ArchiMate, a data object can be a data store, or the payload in a message or data flow.
It can also be a data entity/item within a data store, or an element within a message, at any level of granularity.
In TOGAF’s
business architecture, when defining a conceptual data diagram, a data
entity/business function matrix, or a business service/information
diagram, you define business data created and used by business processes,
with no reference to applications or IT.
There is no
implication that the data is digital, though it is increasingly digital of course.
Making “no reference to
applications or IT” doesn’t mean defining business architecture artifacts regardless of digital data that exists.
And any duplication or overlap of
data definition has to be managed somehow.
In TOGAF,
architects define “data entities” that are stored and maintained in digital
“data components”.
However, when
defining the meaning of a data entity type, the storage mechanism is
irrelevant.
A data entity may model, describe or represent a material object (your motor car) or a conceptual/data object (an insurance claim).
To define such a data entity is not to define its physical nature (ink on paper, magnetic pattern on discs, sound waves, electron movements in wires).
In defining
it, you make no reference to IT, rather, you define the meaning of the thing
the data represents.
So, to define the data entity is tantamount to defining the
business entity it represents.
A business object is supposedly more logical or conceptual in nature than a data object, but data definition is already conceptual.
E.g. the definition associated with a “Supplier” data entity may be indistinguishable from the definition of a “Supplier” real-world entity.
And 50 years into the Information Age, often, the things or events of importance to a business are data objects.
This example shows a business object that is realisable by three different physical representations.
In practice, the definition of the “Claim” business object in this model may be indistinguishable from the definition a corresponding “Claim” data object (whether the object instances are digital or not).
ArchiMate
example 24 http://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc489946043
Data architecture is not only about data structures at
rest (in store); it is also about data structures in motion (in flows).
TOGAF classifies artifacts that record the production and
consumption of transient data flows under the headings of business and applications architecture.
As a result, what it classifies under the data
architecture heading are artifacts that record the creation and use of data
entities in persistent data stores.
TOGAF says:
“The purpose of the Data Entity/Data Component catalog ... including data
entities and also the data components where data entities are stored.”
In other
words, a data component relates persistent data entities in a passive data
structure that persists.
That data
structure must survive the deletion of application/technology component
instances, and the turning off of electricity to devices.
In the simple and normal case, one logical data component is realised in one physical data component, defined in the form required by a physical technology for storage in one location.
For some
reasons (e.g. agile development) one logical data structure may be divided
between two or more physical data components, which may be integrated
asynchronously.
For other reasons, one physical data component may contain two or more logical data components.
Where are business layer data
entities defined in artifacts?
The conceptual data diagram
and data entity/business function matrix can contain only a small
fraction of the number of data entities in the application layer data
entity/data component catalog.
|
Data entity/business function matrix |
Business data entities
|
<are created and
used by> |
Business functions |
|
Conceptual data diagram |
Business data entities |
<are related to> |
Business data entities |
Moreover, business data entities
may differ by aggregation or generalisation from application data entities.
This implies need for a separate
business data catalog in which those larger or more generic data entities are
defined.
The
business data catalog should serve to define business objects that are
important enough to be remembered as data entities.
(Would
we want to define business objects that are not that important?)
Where are application layer
data entities defined in artifacts?
Data
entities can be related to each in a larger data structure using a logical data
diagram.
|
Logical data diagram |
Data entities |
<are related to> |
Data entities |
One
data entity type may appear in several logical data diagrams.
A logical data diagram may be realised in a variety of physical
database schema.
These
relationships are recorded in the data entity/data component catalog.
|
Data entity/data Component catalog |
Data entities |
<are related
together in> |
Logical Data
Components |
<are realised by |
Physical Data
Components |
The data relation
above looks like the generic relation, but it is different.
There is
neither behavior nor active structure in the relation above; there are only
three passive structures.
Where are data flows defined
in artifacts?
Data
flows are recorded in two matrices and one catalog.
|
Information Exchange matrix |
Data flows |
<pass between> |
Business Entities |
|
Application Interaction matrix |
Data flows |
<pass between> |
Application Components |
|
Interface catalog AKA Data flow catalog |
Data flows |
<pass between> |
Application Components |
Data
flows can also appear as arrows in these two diagrams.
|
Business Interaction diagram |
Business architecture
entities |
<communicate
with> |
Business architecture
entities |
|
Application Interaction diagram |
Application
architecture entities |
<communicate
with> |
Application
architecture entities |
In these two
diagrams, the “communicate with” relationship may be modelled in two different
ways, using a flow arrow or a serves arrow.
And the arrow
may represent one flow or service, or several of them.
Where is data flow in the meta model?
Looking
at the meta model of TOGAF, some see “data entity” as standing for data
structures both in stores and flows, and/or see data components as data flows.
Instead,
however, data flows can be seen attributes of business and application/IS
services.
Both
ArchiMate and TOGAF standards define a service as a requestable or exposed unit
of behavior.
This
interaction between a client actor/component and a server actor/component is
definable in a contract.
Indeed,
the Architecture Requirements Specification includes business service
contracts and application/IS service contracts.
Ideally,
a contract declares any input and output data flows that a service
consumes and produces, without reference to internal procedures.
Where are data flows that are not defined in service contracts?
Will
all data flows be associated with and defined in service contracts? And
if not, then where are they documented? One obvious place is what TOGAF calls
the interface catalog.
And
if architects use that to record data flows, then should service contracts
cross-refer to it? And if the interface catalog is where application layer data flows are recorded, then where are business layer flows recorded?
Where are data structures conveyed within data flows
defined?
A customer told me they have an
enterprise message catalog containing more than 2,000 message types, with
duplicated content but different data types.
A presumption of EA is that
application integration costs will be lower if there is a single point of
definition (SPOD) for data elements.
Business actors exchange defined
messages, and act in response in the light of defined memories.
TOGAF addresses the memory side of
things along the lines in the left hand column below.
Superficially, the messaging side
of things can be described in a similar way, but it is different.
|
Data elements in memories (entities in data stores) |
Data elements in messages (canonical data
structures) |
|
A data entity is a structure of data items that
is or represents a thing or event that a business needs to
remember. E.g. customer, order, product, application,
employee, or asset. |
A message element is a structure of data items
that is a collection of facts business entities need to
exchange in messages. E.g. name + address + telephone, order + items,
or a table of exchange rates. |
|
One data store contains a data structure composed
of several/many data entities related semantically to each other in a logical structure (an entity-attribute
relationship model). |
One data flow contains a data structure composed
of one or more message elements related to each
other in a sequential structure (a regular expression). |
|
Data entities may be related in different data structures, in different data stores, which are differently located. |
Message elements may be related in data flows
that are differently sequenced, sent to different receivers and differently timed. |
Data flows
are weakly represented in most EA frameworks. However...
In TOGAF,
data flow structures are defined in or associated with the Interface Catalog
and the Information Exchange Matrix.
The artifacts
culd include business and application data flow catalogs, in which the data
flow structure is an attribute of a data flow.
Surely,
rather than confuse the definition of data stores and data flows, the next step
would be add a canonical data model for defining message elements?
ArchiMate’s interaction and collaboration were derived from those in UML.
An interaction is an “internal behavior”, a process which
may realise a service.
A collaboration is the term for a structure of communicating
elements, which may perform interactions.
Interactions as behaviors
In UML, an interaction diagram shows a process than can
be performed from start to finish.
An interaction is composed of “traces”, each being a
“sequence of event occurrences”
“The sequence of the messages is considered important for
the understanding of the situation.”
“In an interaction diagram each vertical line describes
the time-line for a process, where time increases down the page.”
In ArchiMate, an interaction is “A unit of collective
behavior performed by (a collaboration of) two or more structure elements.
“The name of an application interaction should clearly
identify a series of application behaviors”.
“An application interaction may realize an application
service.”
Collaborations as structures
In UML, “A collaboration defines a set of cooperating
participants.”
It explains “how a system of communicating elements
collectively accomplish a specific task or set of tasks”.
In ArchiMate, a collaboration is an “internal active
structure”.
It is “an aggregate of two or more active structure
elements, working together to perform some collective behavior.”
Behaviors go by many names, including process, scenario, value stream, use case, service and operation.
A behavior runs from an event-triggered start to an end, which may be specified at two levels:
· One or more products (output flows and/or system state changes).
· One or more desired results (goals, objectives, outcomes) to be met by users of those products.
Flows as products
The input and outputs of a behavior may be called flows.
Architects describe I/O flows contain data and sometimes material goods.
The product of a service includes any data or material flow a requester or consumer obtains from it.
E.g. An “inspect exhaust service” produces a flow of information to the vehicle owner
E.g. A “fit new tyre service” produces a flow of material goods to the vehicle owner.
System state changes
as products
Another product of a service is a change to the state of a system.
E.g. value added to a product.
E.g. address updated after a change of address
Results as outcomes
of product use
Actors make use of the products of behaviors to meet goals, objectives or achieve outcomes.
“Desired results” is a label used in the OMG’s business motivation model for goals and objectives.
Value propositions
Architects define different value propositions for different stakeholders in any proposed change.
Architects might define different value propositions for different consumers of one product.
Capability
A capability is ability to do something (perform one
or more processes) or achieve something (reach one or more goals).
So a capability is always in 1 to 1 correspondence
with something else that can be modelled.
Business
Capability is a subtype of Capability in 1 to 1 correspondence
with Business Function.
(This paper includes material
from papers at http://avancier.website copyright ©
Avancier Ltd, and three diagrams from the ArchiMate version 3.0.1 standard,
Copyright © The Open Group, All Rights Reserved.
TOGAF and ArchiMate are registered trademarks of The Open
Group.)