Terms and
concepts in system description and EA
This page is published under the terms of the licence
summarized in the footnote.
All
free-to-read materials on the Avancier web site are paid for out of income from
Avancier’s training courses and methods licences.
If you find
them helpful, please spread the word and link to the site in whichever social
media you use.
The essential conclusions of this paper are expressed more graphically in this slide show.
This is one of several background research papers that arose out of research done in 2008 for a BCS architecture reference model.
It identifies comparable terms and concepts in various EA approaches.
Contents
Enterprise
system elements (recap)
Mapping
the four generic elements to the three generic domains/layers
Service-orientation
in TOGAF, ArchiMate and BCS reference models
Beware
ambiguities in how architects use these words
How
to document the four system elements in practice?
The word “architect” comes from the Greek “master builder”, and in enterprise and solution architecture, 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.)
Two fundamental system modelling premises are set out in UML 2.1:
1. “all behavior in a modeled system is ultimately caused by actions executed by so-called “active” objects”
2. “behavioral semantics only deal with event-driven, or discrete, behaviors”
Enterprise architecture is about activity systems that are:
· event-driven, and composed of
· actors (structural elements) that communicate and cooperate in
· activities (behavioural elements) and maintain information about the
· state of those actors and activities
The table below presents a conceptual framework of generic system elements.
|
ArchiMate/BCS Grid |
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 |
Activities/Processes each comprises one or more activities that respond
to an event or meet a service request. |
Actors/Components 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.
It is impossible to prescribe a human activity system as far as a computer activity system must be prescribed.
However, similar principles apply, and key system elements in a restaurant might be naively illustrated as below.
|
Restaurant |
Behavioural view What a system does |
Structural view What a system is made of |
|
External view |
Menu item requests |
Menus |
|
Internal view |
Ordering, Cooking, Serving, Paying |
Waiters, Cooks, Ovens |
(If a waiter is nothing but a facade that presents a menu and conveys service requests, then waiters might be placed alongside the menus.)
Most of the core concepts in the ArchiMate modelling language can be placed in the ArchiMate/BCS grid thus.
|
ArchiMate/BCS
grid |
Behavioural view What a system does |
Structural view What a system is made of |
|
External view requirements of external entities |
Business Service Application Service Infrastructure Service. |
Business Interface Application Interface Infrastructure Interface |
|
Internal view the workings of the system |
Business Process Application Function Infrastructure Function |
Business Role, Actor Application Component System Software, Node |
Most of TOGAF’s core “building blocks” can be placed in the ArchiMate/BCS grid thus.
|
TOGAF |
Behavioural view What a system does |
Structural view What a system is made of |
|
External view requirements of external entities |
Business Service IS Service Platform Service |
|
|
Internal view the workings of the system |
Business Process |
Function, Organisation, Role, Actor Application Component Technology Component |
(The ambiguous placement of the word “function” in the two grids above turns out to be little unfortunate in teaching structured analysis.)
EA frameworks specialise the four generic system elements above, giving them different names in each enterprise architecture domain/layer.
The terms shown below are a compromise between different EA frameworks.
|
Behavioural view What a system does |
Structural view What a system is made of |
|
|
Environment |
External event |
External entity |
|
Business |
Business service |
Business interface |
|
Business process |
Business function, Organisation unit Role, Actor |
|
|
Information systems |
Information system service |
Application interface |
|
Application process |
Business application Data store, Data entity |
|
|
Infrastructure technology |
Platform service |
Platform interface |
|
Platform process |
Platform component |
Note
that a “use case” is an application process (with main and alternative paths)
encapsulated in an information system service.
The term “service-oriented architecture” (SOA) has been fashionable since the turn of the century, but means different things to different people.
The word “service” is used loosely and variously as a synonym for other system elements (process, function, component, interface etc.).
However, service is a distinct architectural entity in the ontologies and reference models of TOGAF, ArchiMate and the BCS.
1. TOGAF: “an element of behaviour that provides specific functionality in response to requests from actors or other services”
2. Also: “a logical representation of a repeatable business activity, has a specified outcome, is self-contained, is a ‘‘black box’’ to its consumers.”
3. ArchiMate: “a unit of functionality that a system exposes to its environment, hides internal operations, provides a value, accessible through interfaces.”
In other words, a service is a discrete unit of behaviour that encapsulates processes and produces a result for its service requester/consumer.
|
|
A discrete unit of behaviour |
that encapsulates |
processes |
and produces a result |
for its service requester/consumer |
|
1 |
An element of behaviour |
|
specific functionality |
|
in response to requests |
|
2 |
A |
self-contained black box |
repeatable business activity |
specified outcome |
to its consumers |
|
2 |
A unit |
hides internal |
operations / functionality |
provides a value |
exposes to its environment |
See this slide show for examples and discussion of services in TOGAF and ArchiMate.
Different sources use the same words with different meanings.
E.g. The Web Services Definition Language is an Interface Definition Language which names external concepts as shown below.
|
WSDL |
Behavioural view |
Structural view |
|
External
view |
Event/Service = Operation |
Interface = Service |
|
Internal
view |
Process |
Component = Address only |
The terms service and interface are used with various meanings other than the first two below.
|
What we call a |
Others may call a |
Description |
Think |
For example in |
|
Service |
Operation |
A contract, or signature only, for invoking
processes to deliver a desired result |
Menu item |
ArchiMate and TOGAF examples above |
|
Interface |
Service |
A structure that defines (and perhaps offers) several services of the first kind. |
Menu |
A WSDL file |
|
Façade |
Interface |
A structure that offers services of the first kind, a broker to service providers. |
Waiter |
|
|
Data flow |
Interface |
A data structure passed from sender to receiver. |
Message |
TOGAF’s application communication diagram |
|
(Logical) protocol |
Interface |
Rules used to convey data flows, over channels. |
HTTP |
File Transfer Protocol (FTP) |
|
(Physical) channel |
Interface |
Medium used convey data flows, using protocols. |
Wire |
A cable connecting two computers |
|
Component |
Service |
Any component that sits behind a published
interface. |
|
A "Microservice" |
|
Available app |
Service |
The availability of an application to users,
provided by IT operations. |
|
|
|
SLA contract |
Service, Interface |
Whatever services are listed in a contractual
document. |
|
|
Aside on abuse of ArchiMate symbols for “service”
and “interface”
The common practice is draw whatever architecture
diagram you think will communicate your meaning to your reader.
This not only makes the language standard
irrelevant to that particular use, it hinders the education of some architects
about architecture concepts.
Our courses set out to educate architects about core architectural concepts
(component, process, service, interface etc.) much as per the ArchiMate
standard.
Architects on the course show me diagrams that are
inefficient communication vehicles, e.g. they connect 1 Component to 1 Service
throughout.
Why? They might think a Component is a Service, or use the Service symbol
when they mean Interface, or simply copy another's misleading diagram style.
But all they really want to do is tell the support
engineer which applications are deployed on which nodes – which makes the
Service/Interface boxes completely redundant.
Sadly, these architects' practical experience of reading and writing ArchiMate
diagrams makes it harder to educate
them instead of easier!
The terms function and process are used with various meanings other than the first two below.
|
What we call a |
Others may call a |
Description |
For example in |
|
Function |
Capability |
a component or
chunk of business capability |
TOGAF-style
structured analysis. |
|
Process |
Function |
a logical
step-by-step sequence of actions |
UML activity
diagram, flow chart |
|
Aim |
Function |
an outcome or
purpose of a system |
|
|
Application |
Process |
an instance of a program running on a compute |
in the “Task
Manager” on your lap top |
Transaction: any request-reply exchange, including ones that encompass a long-term business process.
Transaction: a success or commit unit acting on data resources.
Actor: a type - a role (e.g. barber,
customer, supplier) inside or outside a system.
Actor: an instance - an individual who plays a role (my barber, me, you), inside or outside a system.
Outcome: a product – an output from a
bounded process or system (a hair cut from a barber shop).
Outcome: an aim – a purpose of the
external entity that receives the product or output (look smarter).
A thing is a part of the
universe that can be described as discrete, separable from the rest of the
universe.
The things of interest to architects include working systems and system elements.
Architects are part of a meta system whose role is to describe and change systems.
This graphic illustrates the triangular relationship between architects, systems and system descriptions.
|
Three kinds of thing |
|
|
Descriptions <create and use> <idealise> Architects <observe and envisage> System
elements |
It is impossible to impose a single perfect hierarchical structure on all the terms and concepts of interest here.
But people do find it easier to manage things organised in a hierarchical structure.
So, don’t think of the ontological structure below as “right”, it is only a tool to assist understanding.
|
System element: a unit of an operational system that can be
described. |
Structural element: a unit of what a system is made of. |
Active structural element: a structural element that can be asked to do work. |
Component: a subsystem that can perform one or more process
steps. It can be
related to other components by requesting or delivering services. It can be replaced by any other component with the
same interface(s). It is
sometimes called a building block. |
|
Interface: a façade component that presents services for
access by other components. It encapsulates any internal components needed to
deliver the services. |
|||
|
Passive structural element: a structural element that is acted upon. |
Object: an item or structure that is used,
moved or made. E.g. a data item, data structure, or any kind of structural
component. |
||
|
Location: a place where components and interfaces are found
and work is done. |
|||
|
Behavioural element: a unit of what a system does. |
Service: the external view of the processing that responds to
a singular event or service request. |
|
|
|
Process: one or more activities, triggered by an event or
service request, that ends by producing a desired
effect. It is performed by one or more components. A process is
described or defined as a sequence of actions or instructions under a
logical control flow. |
We could model a system by documenting the four system elements separately, with cross-references.
This table shows references that trace the edges of the square.
|
ArchiMate/BCS grid |
Behavioural view What a system does |
Structural view What a system is made of |
|
External
view requirements
of external
entities |
Events/Services Found in interfaces > The result of a process v |
Interfaces < Declares services Provided/required by components v |
|
Internal
view the
workings of the
system |
^ Wrapped in a service Requires Actors/Components > Processes |
^ Provides/requires interfaces < Performs processes Actors/Components |
But we often don’t document the elements separately.
Because it is often convenient to document one element within another.
In practice, the elements are documented in various aggregate documents
· A component definition includes or names one or more component interfaces.
· An interface definition names one or more services (defined separately).
· A component definition includes or names one or more performable processes.
· A process can be defined as a use case, which wraps up the process flow inside a service contract.
Document templates are proposed in this paper.
There is an International Standard for “Systems and software engineering — Architecture description” (ISO/IEC/IEEE 42010:2011).
It takes no position on what a system is (see above) but does declare an architecture description shall include the following contents:
· identification and overview of the description
· stakeholders and their concerns
· an architecture view, composed of architecture models for each architecture viewpoint used
· a definition for each architecture viewpoint used
· correspondences and inconsistencies among the description’s required contents
· rationales for architecture decisions made.
Note that this list of architecture description features is not a document template; the verb include allows for references between documents.
Many attempts to
build a controlled vocabulary suffer from one or more issues below.
·
Authors
assign meanings to words, rather than words to meanings.
·
Authors
suggest 1 to 1 relationships between concepts that are really many to many
relationships.
·
Authors
confuse structural elements (actors or components) with behavioural
elements (activities or processes).
·
Authors
wrongly believe that arranging terms in a class hierarchy will ensure a
coherent vocabulary.
·
The meta model of the vocabulary - if there is one - is
incomprehensible without deep study.
Looking at the
terminology used in well-known sources:
·
TOGAF
is poor; synonyms and homonyms abound; terms are used with multiple meanings.
·
ArchiMate
has a promising generic meta model, but doesn’t follow
it through thoroughly.
·
DoDAF
makes an earnest and concerted attempt to define a coherent vocabulary, but
falls short of UML.
·
UML
looks the best of the bunch – but is incomprehensible without deep study.
The UML meta model is probably more thoroughly worked out because it
is closer to where the rubber hits the road - testable systems.
UML started as an
object-oriented program design language, and still suffers a little from a bias
in that direction.
However, UML is
the only source to point out that all our
models assume systems are driven by discrete events.
If your
architectural vocabulary is not based on the concept of a discrete event or
service, it doesn’t have a solid foundation.
These papers
suggest that a global architecture vocabulary should start at the basic level
of general system theory.
Creative Commons Attribution-No Derivative Works Licence
2.0 01/12/2015 19:51
Attribution: You may copy, distribute and display this copyrighted
work only if you clearly credit “Avancier Limited: http://avancier.website” by means of
including this copyright statement.
No Derivative Works: You may copy, distribute, display only
complete and verbatim copies of this page, not derivative works based
upon it. For more information about the licence, see http://creativecommons.org.