The anatomy of the reference model
This paper is published under the terms of the licence summarized in the footnote.
Abstract
In 2008, the
British Computer Society (BCS) standard reference model for enterprise and
solution architecture model was
based on a model of essential general system theory concepts.
This model is clearly akin to the generic meta model that
underpins the ArchiMate Language (later published as a standard by The Open
Group).
The concepts in the two models seem to be in
correspondence as the table below indicates.
And the concepts in
TOGAF, though more loosely defined, can be roughly aligned with both.
|
View of
system |
Nature of
element |
ArchiMate generic meta model |
BCS reference model |
TOGAF |
|
External |
Behavioural element |
Service |
Event
/ Service |
Service |
|
External |
Active structural element |
Interface |
Interface |
|
|
Internal |
Behavioural element |
Behavioural
element |
Process |
Process |
|
Internal |
Active structural element |
Structural
element |
Component
/ Role |
Component |
Since 2008, some
have interpreted the concepts in BCS and ArchiMate models differently.
Are the models the
same or different?
This paper is the
second of three addressing that question
It was written
primarily to clarify the BCS model, but it may help you interpret ArchiMate
concepts as well.
This
paper is deliberately written along the same lines as “The Anatomy of the ArchiMate Language” by
Lankhorst, Proper et al. (2008).
Contents
Enterprise
system elements (recap)
What
it means to treat the enterprise as system
Behaviour:
transient processes and services
Structure:
persistent components and interfaces
Appendix:
finding the core concepts in other sources
Appendix:
Limits to the mechanical-human system analogy
Appendix:
Limits to enterprise architecture
The word “architect” comes from the Greek “master builder”.
In enterprise and solution architecture frameworks, the buildings are “systems”.
“Enterprise architecture regards the enterprise as a system, or system of systems” (TOGAF)
“Architecture descriptions are formal
descriptions of a system.” (ArchiMate® 2.1 Specification, The Open
Group.)
The ArchiMate standard employs a conceptual framework of generic system elements, presented in a simplified form below.
|
After ArchiMate |
Behavioural view What a system does |
Structural view What a system is made of |
|
External view requirements of external entities |
Events/Services each encapsulates the processing of a discrete event or service request. |
Interfaces each is a facade that presents services for access by clients |
|
Internal view the workings of the system |
Processes each comprises one or more activities that respond to an event or meet a service request. |
Components/Roles each is a subsystem that performs process steps. |
One architect’s whole system is another’s component in a wider system, so this model can be applied at any level of granularity.
There is a fifth kind of system element: an object: an item or structure that is used, moved or made by processes.
Here are few generalisations about the concepts above.
·
Every
process and service runs from a start or trigger to an end or result.
·
Processes
and services are called behavioural (aka dynamic) elements.
·
Behavioural
elements are performed by or accessed via structural elements.
·
Components,
roles and interfaces are structural elements - designed to deliver the
behaviour required of the system.
·
Structural
elements are deployed in locations to do work.
Architectural entities can relate to each other in various
ways, for example:
·
A
component/role can execute one or many processes.
·
A
component can be decomposed into smaller components.
·
A
process can be executed by one or many components/roles.
·
A
process can be decomposed into shorter processes.
·
A
process can be encapsulated behind a service.
·
A
component can be encapsulated behind an interface.
·
A
service can be accessed via one or more interfaces.
·
An
interface can expose (make accessible) one or more services.
In what is sometimes called "realisation", the external view of a system encapsulates and is implemented by its internal components and processes.
More specifically, services are implemented by processes, and interfaces are implemented by components.
In what is sometimes called "construction", the behavioural elements of a system are assigned to structural elements.
This means services are assigned to interfaces, and processes are assigned to components.
In terms of general systems theory, a system has components that cooperate in processes to maintain the state of the system and enable it to meet its goals.
|
COMPONENTS PROCESSES |
Heart |
Blood vessels |
Lungs |
Liver |
|
Transport oxygen |
x |
x |
x |
|
|
Transport and detoxify waste |
x |
x |
x |
It is probably obvious that each component in the table above can be decomposed into smaller components.
And each process can be decomposed into shorter process steps.
Both abstraction and its opposite, refinement, are necessary in describing a large and complex system.
In EA, enterprise components and processes are recorded in EA description artefacts – usually in matrices and diagrams.
For example: an enterprise’s organisation structure of likely composed of many units (structural elements).
Such as: Executive, Marketing, Sales, Delivery, Finance, Human Resources and Procurement.
These structural components cooperate in “end-to-end” processes that can be divided into process steps (behavioural elements).
E.g. the table below shows which components cooperate in a marketing campaign process.
|
COMPONENTS Campaign PROCESS STEPS |
Executive |
Marketing |
Sales |
|
1. Understand product to be sold |
x |
x |
|
|
2. Design advertisement(s) |
|
x |
|
|
3. Get executive approval |
x |
x |
|
|
4. Publish advertisement(s) |
|
x |
|
|
5. Record responses |
|
x |
x |
|
6. Distribute responses to sales people |
|
|
x |
Note again that abstraction, here by hierarchical composition of fine-grained components and processes into coarse-grained ones - is necessary in describing a large and complex system.
An enterprise architecture usually describes system structures and behaviours at a very abstract level.
Consider a restaurant as a system, as a fuzzily-definable
human activity system; one can identify
·
Business
interfaces: menus presented to customers, perhaps in the window, perhaps by
waiters
·
Business
services: requestable items (starters, main courses, desserts and drinks)
·
Business
processes: ordering, serving, taking payment, cooking.
·
Business
components (functions or roles): waiter, cook, oven, dishwasher.
·
Business
objects: food ingredients, pots and pans, orders, payments, receipts.
A restaurant menu can be likened to an application programing interface (API).
The role a waiter plays in presenting a menu can be likened to the facade role a software module plays in presenting an API.
A system employs façade components to realise its external interfaces.
A restaurant can employs waiters to present menus and take orders.
A software system can employ “web services” to present APIs.
Given the meta model is so generic, so simple, there are inevitably some ambiguities.
Can an active
component be a passive object?
An active system element, called a component, does work, it executes processes.
A passive system element, called a passive object, is an item or structure acted on by processes.
The notion in
natural language is that subjects perform
activities on objects.
The notion in architecture description that active structural elements perform behaviour on passive structural elements.
However, when an active component is transported somewhere, or placed in a position, then is being treated as a passive object.
E.g. An application appears twice in the ArchiMate meta model – as an activity component – as a passive deployable artefact.
Is an interface
passive or active?
The conceptual framework suggests an interface is active structure; but in practice we allow that an interface can be:
· Passive: e.g. a menu, a WSDL, an SLA.
· Active: embodied in a facade component that forwards events or service requests (e.g. a waiter, a web page, a help desk).
As long as a facade component has no intelligence except where to send messages, it is convenient to call it an interface rather than a component.
Can components behave
spontaneously?
All human and computer
activity system models we build are event-driven.
Entities and activities in the wider environment may act in what appears spontaneous behaviour.
But within our systems of interest, a component never executes a process without a trigger event.
And its behaviour is deterministic, meaning its response to an event is determined by the current system state.
Suppose a person is employed to play a role in a system acts spontaneously, outside the role defined for them in the system description.
Then that action is outside the system boundary according to the system theory applied here.
(However, a component can act in an apparently spontaneous way by using a random number generator to select between actions in response to an event.)
In natural language,
we often form sentences in which subjects perform activities on passive
objects: for example, boys climb
trees.
The passive objects
in one sentence can be subjects in another sentence: for example, trees consume
water.
|
Process: One
or more activities, triggered by an event or service request, leading to a
result or output. The activities can be arranged under a logical control flow, and
are performed by one or more components. Architects have various ways to define a process: a flow chart,
use case definition, interaction diagram or service contract. |
|
Business process: a process performed in a
business, terminating in a service or result. Application process: a process performed by a
business application in the course of a human use case or fully automated
service. Platform process: a process performed by a
platform application, usually invisible to an architect. |
How to document a
process?
To complete the definition of the process, an architect may describe how to make the process start, why it exists, and other characteristics.
A use case template wraps the description of a process flow inside the attributes of a service contract (highlighted in yellow below).
The process flow itself can be documented in various styles.
Find a general process definition template in this paper.
Although non-functional requirements are commonly applied to a whole component or interface, the customer requirement applies to each kind of discrete service they request.
Inside a system, components
perform and cooperate in processes.
In the wider
environment, from outside the system, all that can be seen is the system
boundary and the events that cross that boundary.
Systems are designed
to deliver “services” requested by external clients.
|
Service: The
external view of the process that responds to a singular event or service
request. Named examples include: check customer credit, provide weather
data, consolidate drilling reports (from TOGAF), policy creation, premium
payment, claim registration, claim (from ArchiMate). A service encapsulates processes needed to
deliver the desired result, and is describable using a service
contract. “For
the external users, only this external functionality, together with
non-functional aspects such as the quality of service, costs etc., are
relevant.” ArchiMate. |
|
Business service: a singular service (e.g.
order, pay, report, weigh) that can be requested of a business by customers,
suppliers or employees. Application service: a singular service that can
be requested of a business application; a human use case or fully automated
service. Platform service: a singular service (e.g.
transaction roll back or user authentication) that can be requested of a
platform applications by business applications. |
Find a general process definition template in this paper.
A system description usually assigns active structure to perform behaviour, that is, it declares who or what components will perform which processes.
The paper “The
Anatomy of the ArchiMate Language” suggests an actor is an individual and a
role is a collection of individuals.
However, general system
theory draws an even more fundamental distinction between concrete individuals
and abstract types.
A role is not so
much a set (a group of individuals) as an abstract type (a generic description
of an individual set member).
|
Component: a subsystem that executes
processes. A
persistent component that performs activities or gives access to behaviour. It
can be specified in a component/role definition. |
|
Business component: an organisation, human
role or machine capable of performing business activities and offering
business services. Business application: a software system capable
of offering use cases or automated services. E.g.
Billing, CRM. Platform application: an infrastructure
component capable of offering the platform services business applications
need. E.g.
Operating system, message broker. |
Components are
sometimes called actors or roles, and commonly, the terms are used
interchangeably.
Here, roles are
types and actors are instances.
As a crude
generalisation, EA is a description of component types rather than instances.
The instances of the
components in an operational system may be recorded in a Configuration
Management Database (CMDB).
|
Role |
a general component type;
it defines a general responsibility for performing a defined group of
activities or offering a defined group of services. A role can be played by one
or more actors, but a role is type rather than a set. |
|
Actor |
a
specific component instance (e.g. an insurance company, a person, a
mainframe, etc.) that is capable of playing a role. If
a role is played by only one actor, you may use the actor name for the role. |
How to document
component types?
A complete definition of a component or role defines both external and internal views, so it includes an interface definition.
Find a general
process definition template in this paper.
Components cooperate in processes that act on passive objects.
EA is concerned with the description of passive object types (whereas passive object instances are recorded in the corresponding operational system).
Inside a system,
components perform and cooperate in processes that act on passive objects.
|
Passive object: An item or structure that
is used, moved or made. An
entity that is the object of an activity. In
EA, the passive objects are commonly parcels of information. |
|
Business object : a parcel of unstructured
data processed by business people. Data entity: a parcel of structured
data items processed by application components. Platform artefact: a parcel of data deployed to
a technology component. |
It is possible to
model physical objects and goods as well as information objects, but the
passive objects addressed in EA are often information objects.
Some information
objects are made or used inside a system, and some move across the system
boundary into or out of the system.
Components cooperate in processes, which are behavioural
elements rather than structural elements.
Note the earlier discussion of ambiguities.
Perhaps the biggest debatable question in these papers is whether an interface is best described as one or both of:
· a menu – a passive structural element - an abstract specification listing service offered
· a water – an active structural element - a role that presents a menu - a facade component that accepts service requests and directs them for processing
In ArchiMate, it appears that an interface is the latter, it is a point of access, found at a specific location.
We allow both meanings.
An interface can be a facade - a point of access to a collection of one or more discrete services – including location and connection details.
An interface can expose (make accessible) one or more services.
Every component can be encapsulated by an interface.
|
Interface: a facade that presents a
system’s services for access by entities in the wider environment; it
constitutes an external view of a system’s active structure. |
|
Business interface: a facade where external
entities can request services offered by business components, or external
events are recognised. It
could be defined in some kind of SLA. Application interface: a facade where business
components (and other applications) can request services offered by business
applications. It
could be defined in a user interface or an API. Platform interface: a facade where business
applications (and other platform applications) can request services offered
by platform applications. It
could be defined in the form of an API. |
The logical part of
an interface is a menu of services.
When a service has
been assigned to an interface, this assignment must be mirrored (inside the
system) by the assignment of relevant internal components to relevant internal
processes.
Having assembled a menu
of cross-system-boundary events or services, the logical interface can be made
physical when it is published at a location where clients can access the
services.
Further, the
interface may be assigned to a façade component that holds and publishes the
menu, accepts input and delivers output.
The interface can be
extended with other attributes, such as protocols for message transmission, and
the physical channel or medium via which input and output objects are
transported.
Find a general
process definition template in this paper.
In short, human and computer activity systems can be described using the same general concepts and descriptive artefacts.
And the general concepts can be specialised for each architecture domain.
System description
concepts are most readily distinguished by the attributes and
relationships we use to describe them.
Find a general
process definition template in this paper.
The table below is
an attempt to resolve some terminology confusions.
|
Generic concept |
I propose Ref. Model should
use these terms |
ArchiMate terms |
TOGAF terms |
|
Process |
Business process |
Process/Function |
Business process |
|
Application process (internal flow of application service) |
Application function |
|
|
|
Platform process |
Infrastructure function |
|
|
|
Service |
Business service |
Business service |
Business service |
|
Application service / Use case Application service / Automated service |
Application service |
Information system service |
|
|
Platform service |
Infrastructure service |
Platform service |
|
|
Component |
Business component / Business function Business component / Organisation unit Business component / Business role |
Business role Business actor |
Business function Organisation unit Role |
|
Business application |
Application component |
Application component (Logical and Physical versions) |
|
|
Platform application Node |
Node / System Software Node / Device |
Technology Component (Logical and Physical versions) |
|
|
Interface |
Business interface |
Business interface |
|
|
Application interface |
Application
interface |
|
|
|
Platform interface |
Infrastructure interface |
Application platform interface |
|
|
Passive
object |
Business object |
Business object |
|
|
Data entity |
Data object |
Data entity |
|
|
Deployable artifact |
Artifact |
|
And note FYI.
|
Generic concept |
WSDL terms |
Windows terms |
|
Application service |
Operation |
|
|
Business application |
|
Process, Application |
|
Platform application. Node. |
|
Process, Service |
|
Application interface |
Service |
|
There is a limit to how far you can push the analogy between mechanical and human activity systems.
There is a difficulty with extending the analogy to human activity systems.
Formal system descriptions cannot adequately accommodate the self-awareness, creativity and unpredictable flexibility of human components
Not only are human components are inventive and flexible, self-directed and multi-talented, far beyond any role that might be documented in any system description.
But most enterprises rely on this, at least in those humans who play more senior roles.
Consider, again, a restaurant as a fuzzily-definable human activity system.
A great deal of what happens in the system is implicit, understood without any need for communication.
But here are some services involved.
· Customers implicitly make an unspoken request for a general service: “please give me a pleasant dining experience, along with any companions that join me.”
· Customers may voice a request for more specific meta service: “please show me the menu”.
· The menu lists the more specific services a customer can request – via an actor playing a waiter role - from the restaurant.
· In answering those requests, a customer or manager may request subsidiary services from a waiter actor: take order, serve meal, clear dishes, take payment.
However, everything in a human activity system is flexible.
The human (actor) playing the waiter (role) may
· initiate and complete required services without being requested to do so.
· be asked to play another named role (e.g. dishwasher).
· invent a new role and play it.
· behave spontaneously in ways unforeseen in any prior system description.
A human actor is an amazing general-purpose component, capable of providing an infinite variety of ad hoc services to anybody who asks.
E.g. “please take a photo of my wife and me”.
Such ad-hoc services could never be defined in a formal system description.
Enterprise architecture
(EA) is focused on enabling and improving business roles and processes that are
repetitive and deterministic enough to be systematised and digitised.
In other words, it
does not focus on roles and processes that are informal, ad hoc and continually
changing.
There must be some rules: e.g. executive approval must be sought for adverts.
You can design a marketing process to be flexible; you could:
· Design alternative process paths. E.g. executive approval may be skipped for adverts costing less than a threshold value, say 1 thousand dollars.
· Include adjustable variables in the rules. E.g. The approval threshold can be an adjustable variable.
However, the kind of
flexibility that employing humans naturally brings to a process is not normally
addressed by an enterprise architect.
Obviously, the marketing process relies on human intelligence and creativity.
Yet at the level of
abstraction described by enterprise architects, as illustrated above, the
marketing process remains a designed, repeatable and deterministic process.
Humans are not machines.
In operation (at run time) a human actor playing the marketeer role might deliberately ignore the designed process steps, break documented rules, subvert the organisation structure, whatever.
E.g. They might publish a 1 million dollar advert without executive approval.
Or, they might sell advert responses to a rival company.
So while the description-time enterprise architecture remains an orderly system of repeatable, deterministic processes, the run-time operational enterprise may depart from that system.
That may be desirable; in fact most businesses depend on human flexibility.
The question here is how far an enterprise architecture, or any system description, can or should reflect such human flexibility.
Suppose enterprise architects documented that the organisation’s human actors can ignore designed processes, break documented rules, subvert the organisation structure, do whatever they choose.
Then, what the enterprise architecture describes would no longer be a system; it would no longer prescribe the system’s structure or behaviour.
Nobody reading the enterprise architecture could predict what the enterprise will do.
The enterprise may depend on human intelligence, self-awareness, creativity, flexibility and the ability to act in undocumented and unpredictable ways.
But, by definition, those actions are not systematic; they cannot be captured in an enterprise architecture artefacts; they lie outside of the enterprise architecture.
Enterprise architects set out to treat the enterprise as a system in which the processes are designed, repeated and deterministic.
Behaviour that is not designed, repeatable or deterministic is simply not recorded in an EA description.
Published under the Creative Commons Attribution-No Derivative
Works Licence 2.0 29/01/2015 19:55
Attribution: You may copy, distribute and display this copyrighted
work only if you clearly credit “Avancier Limited: http://avancier.co.uk”
at the start and include this footnote on each page .
No Derivative Works: You may copy, distribute, display only
complete and verbatim copies of this paper, not derivative works based
upon it..
For more information about the licence, see http://creativecommons.org.