The need for a
more controlled vocabulary
To align ArchiMate with UML and TOGAF
Copyright Avancier Ltd 2106
This paper discusses the vocabulary used in business system modelling languages and frameworks, and proposes a more controlled vocabulary.
Principles
Generic
terms and concepts - after system theory
A more
controlled vocabulary for enterprise architecture
On abuse
of the term “service”
Conclusions
and recommendations
As Boulding suggested, in his
1956 paper on applying system theory to management science, business system
architects do not model people; they model their assignments to roles. The business systems we model are formalised social systems. Social systems are composed of actors
who communicate and perform activities according to messages received and
memories retained. Business systems are social systems in which roles are
formalised, messages are formalised in data flows, memories are formalised in
data stores and activities are performed in response to discrete events. Inter-actor transactions are formalized
by defining what actions a message can trigger, and by agreeing the
contents of messages conveyed and memories retained.
To formalise
and integrate their behaviour, interacting parties must agree the meanings of
symbols they create and use - in messages and memories.
It is very difficult to use
words in a logical and disciplined way. We don’t naturally do that. Natural language is loose and ambiguous. The
English language is said to contain over a quarter of a million
words. Different words have the same meaning. One word has several meanings.
The meanings are imprecise. The words we use to describe things are verbal
encodings of fuzzy mental models that are often not precise in our own mind,
let alone shared by others.
On the other hand, a mark of
a profession is that its members are taught and use a domain-specific language,
or controlled vocabulary. So, you would expect that when architects specify a
business system, they would use a controlled vocabulary in which words (like
“service”, “process”, “component”, “ interface” and “function”) are distinct
and unambiguous. Obviously, they want to maximise the certainty that
specifications and models will be understood by fellow professionals. (Bear in
mind that, professional architects must also translate their models into whatever
natural language untrained stakeholders use.)
What is the state of the art?
The language architects use in day to day work is chaotic, loose and
ambiguous - not a controlled vocabulary. From 1998 to 2006, I was in
charge of defining the practices and vocabulary used by about 75 solution and
technical architects working for a global company. I listened to them using
terms like service, process, component, interface and function. They used these
terms ambiguously; sometimes changing a term’s meaning from one sentence to the
next. They used the term “interface” with five or more distinct meanings. They
swapped meanings between words. That doesn’t mean they couldn’t do their work;
it does mean it was difficult follow any discussion of that work, document best
practices and teach them.
Consider:
A. The accounting department provides the accounting
service.
B. The accounting department provides the accounting
function.
C. The accounting department performs accounting
processes.
D. The accounting department provides accounting services
listed in a service level agreement document.
Consider:
A. The messaging component provides the messaging
service.
B. The messaging component provides the messaging
function.
C. The messaging component performs messaging processes.
D. The messaging component provides services through an
interface.
Consider:
A. A Web Service is a service.
B. A Web Service is an interface.
C. A Web Service operation is a service.
D. A Web Service encapsulates behaviours of one or more
remote components.
In my view, one of the
answers in each case above is an abuse of a controlled architecture
vocabulary.
Consider these named elements
in a system architecture description: Complaint handler, Complaint handling,
CRM System, Customer Relations Management, Transaction processor (CICS),
Transaction processing, Message broker, Messaging, Network service, Router
(CISCO). Which of those named elements is a role? A process?
A service? A function? A component? A node?
TOGAF is inconsistent and not
entirely coherent about the terms and concepts of business system architecture.
Many use system modelling languages like ArchiMate as they would use
PowerPoint. There is a combination of laziness, questionable examples and low
quality training. But the issues raised here can be addressed easily enough,
and surely ought to be addressed.
We have to bite the bullet and used a “controlled vocabulary” – rather
whatever seems the most natural or common language today. We need a controlled vocabulary with less ambiguous
definitions of words used to describe business systems (like event, service,
process, function, role and actor). The vocabulary should be based on a system
theory that is clearer about difference between behavioural and structural
elements, external and internal views, and types and instances.
Agreeing a vocabulary for
describing business system element types is a huge challenge. UML is
controlled, but limited and difficult to understand. TOGAF is loose and
inconsistent. ArchiMate is moderately controlled, but conceptually flaky. What
follows is probably closer to what solution architects need, and can be used to
make ArchiMate more consistent and coherent, as we shall see.
These papers go on to look at
the basis of the structure/behaviour distinction in logic.
Encapsulation of regular behaviours behind services
How we model the structure
and regular behaviours of a business system is based on the premises of system
theory and logic.
The regular behaviours are commonly
called processes or services. A service does not expose behaviour; it is the behaviour that is exposed. The
table below abstracts a general definition of “service” from those in the TOGAF
and ArchiMate standards.
|
TOGAF’s definition |
ArchiMate’s definition |
Generally speaking, a service is |
|
“an
element of behaviour that
provides specific functionality |
“a
unit of functionality that |
A
discretely invokable behaviour (short or long) that |
|
in
response to requests from actors or other services. |
a
system exposes to its
environment, |
is triggered by an event/input received from client actors or components, |
|
A
logical representation of a repeatable business activity, |
hides
internal operations, |
is
defined in a service contract that encapsulates internal process(es), |
|
has
a specified outcome, |
provides
a value, |
produces
results of value to clients, and is |
|
is self-contained, is a ‘‘black box’’ to its
consumers.” |
accessible through interfaces.” |
presented for access in one or more interfaces. |
Here are some example
services drawn from the ArchiMate 2.1 standard: Create policy type, Apply for
insurance, Take out policy, Renew policy, Collect premium, Bill customer, Open
account, Identify account status, Transfer money, Retrieve customer policy
record, Register claim, Assess damage, Pay claim, Scan document, Print
document, Deliver message.
A service is often gathered
with other services into a coarser-grained interface or service level agreement
document. Some internal services (and components) are too fine grained for
architects to consider. But architects certainly do identify and name discrete
services. That is how TOGAF expects architects to specify the behaviour(s)
required of a business or other system of interest.
Every end-to-end process (be
it called a scenario, workflow, value stream or use case) can be encapsulated
and defined as a discrete service. However long it takes (minutes, hours, days,
weeks....) the service is a discrete stimulus-response
behaviour, which can be defined in a service contract.
The structure/behaviour distinction
Key words (like service,
process, component, interface and function) can and should be divided (as UML
does) between those that represent structure elements and those that represent
behaviour elements. For example:
Behavior element: A
unit of activity that is triggered by an event and (provided its preconditions
are met) terminates with the production of an output or other response. (Related terms: service, process, use case,
user story.)
Service:
A discrete stimulus-response behavior, specified in a service contract that encapsulates
process(es) needed to
realise the service.
Process:
A step-by-step procedure that
realises one or more services, specified as a sequence of activities
performed by one or more components. (Related
terms: scenario,
workflow, value stream.)
Active structure element: A component in an activity system, responsible for
performing behaviors, which may be specified at
logical or physical levels.
Logical
component: A structure element
specified in terms of services provided and/or processes performed and
abilities required. (Related terms: interface, function, capability, role.)
Physical
component: A structure element that
can be hired, bought or built to realise a logical
component and perform required behaviors. (Related
terms: component, organisation unit, actor.)
Here is an attempt to define
the core terms in TOGAF in line with the conceptual framework above.
|
External entity |
[A logical or physical component] outside the
business or system of interest, which interacts with that business or system
by requesting or supplying services. |
|
Actor |
[A physical component] or individual able to play
one or more roles in the performance of processes. (Where non-human actors
are represented as application and/or technology components, then the actors
must be human.) |
|
Organisation unit |
[A physical component] or individual node in a
management structure, able to fulfil one or more functions. It should have
goals and objectives with measures, and a manager. |
|
Role |
[A logical component] realised or played by individual actors, specified in terms of services provided and/or
processes performed and abilities required. |
|
Function |
[A logical component], a cohesive cluster of behaviors required of any organisation unit that fulfils the
function, specified in terms of services provided and/or processes performed
and abilities required. (It is a logical business capability, not to be
confused with a managed organisation unit or discrete business service.) |
|
Business process |
[A process] that is
performed by the actors in a business, with or without information
technologies. |
|
Business service |
[A service] that can be requested of a business,
or a component thereof. (Not to be confused with
a business function .) |
|
Data entity |
[A data element] composed of data items that
represent facts about a discrete business entity or event. It may be
specified at a conceptual, logical or physical level. It may be mapped to
data stores and/or data flows input to or output from IS services. |
|
IS (app) service |
[A service] that can be requested of a
business-oriented application component, by a human actor or another
application component. |
|
Application component |
[A component] of business-oriented software (e.g.
CRM, Billing). It is specified logically by the IS services it provides, and
sometimes also by the data entities it maintains, and/or physically as a
vendor/technology specific product that can be hired, bought or built. |
|
Platform service |
[A service] that can be requested of a technology
component by an application component or another technology component. |
|
Technology component |
[A component] of generic infrastructure software
(e.g. OS, DBMS). It is specified logically by the platform services it
provides, and/or physically as a vendor/technology specific product that can
be hired or bought. |
Troublesome terms in architecture frameworks and modeling languages
include service, process, component,
interface and function. Perhaps the most troublesome term of all is “service”.
How does it differ from “function” or “role”? This
doesn’t trouble us in everyday discussion. Consider:
“Jeeves
provided butler services. His role definition identified service types to be
provided: receive guests, direct the serving of meals, polish the silver and
perform various personal services. He completed countless service instances,
from start to end. More broadly speaking, service was his function, his role.
During his service as a butler, his service was exemplary, his function was
valued, his role was vital to the well-being of his client.”
But professional specification of
business systems is a different matter. If the
graphical symbols in a system modelling language merely represent words as
people use them naturally, then the modelling language will be as large, loose
and ambiguous as natural language.
People abuse the term
service. They use the term in place of function, component or interface.
They speak of architects identifying “coarse-grained services”, without being
clear whether they mean "bigger", "longer" or
"multiple".
A structure element has
a size, and an instance of it has a place in space. A behaviour element
has a duration from start to end and an instance of it
has a place in time. So, a
coarse-grained service is not bigger than a fine-grained one, it is longer.
When people talk about a
coarse-grained service, they often mean a group of several services. Look for
example at TOGAF. With a few exceptions (e.g. transaction start, and send
email), TOGAF's Technical Reference Model lists service groups rather than
discrete services. That is fine. But a group of services is not a discrete
service. It would be better called a function, or perhaps an interface.
Clustering related or
cohesive services does not make a bigger service; it makes a group of
services, which you might assign to one function, interface or component.
One has to bite the bullet and put people right on this – else a meta model reverts to chaos of natural language. A
vocabulary that allows architects to use terms like service, process, component and interface interchangeably is not good enough.
Many ArchiMate illustrations use the service symbol to name one discrete
service type (e.g. send message); others use it to name a cluster of service
types (e.g. messaging). This is to confuse behavioural and structural elements.
ArchiMate is used to model discrete
event-driven activity systems in which a service is a unit of behaviour with a specific outcome. Unfortunately, the
“service” symbol is widely used in place of “role” or “function”. It is also
sometimes used in place of “interface” and even in place of “component”. In
this way, countless ArchiMate diagram examples abuse the service symbol. As
long as standard maintainers show the service symbol used in this way, then the
language will be deeply ambiguous.
The problem is rooted in ArchiMate’s
appeal to nouns and verbs as the explanation of what differentiates structure
from behaviour. You can always say nouning <is the
role or function of> a noun or noun phrase.
·
Scanning <is
the role or function of> a scanner.
·
Transaction
processing <is the role or function of> a transaction processor.
·
Message brokering
<is the role or function of> a message broker.
You can say noun management <is the
role or function of> a noun management system.
·
Data management
is <is the role or function of> a data management system.
·
Customer relationship management
is <is the role or function of> Customer relationship management system.
You might even say to provide a nouning service <is the role or function of> a noun
system.
·
An accounting
service <is the role or function of> an accounts system.
·
A filing service
<is the role or function of> a filing system.
None
of the 1-to-1 examples above say much of architectural significance; since to
say acting <is the role or function of> an actor is trite. But
the concern here is different, that a service is a unit of behaviour with a
specific outcome, and a grouping of
discrete services is not service, it is a role or function, or perhaps an
interface.
How to reduce ambiguity, ensure consistency and coherence in architectural specifications? It is very difficult (unnatural) to use words in a disciplined way. But it is the responsibility of a professional to understand which domain-specific words are ambiguous, where misunderstandings can occur and to specify solutions clearly. Standard modelling languages are only a part of the answer. We need a more controlled vocabulary, based on system theory. See the controlled vocabulary above.
Words
like function and service are used variously and vaguely in natural language. Asked to define
their meanings in modeling language, a committee may try to please all by
relaxing the definitions to the point of ambiguity. And so, it
becomes impossible to convey valuable and necessary concepts with any
certainty. Compromising symbol definitions to suit all comers and all
practices leads to inconsistency and incoherence, and makes it difficult
to teach architects. Both TOGAF and ArchiMate should define the meaning of its
core terms and symbols more rigorously
Copyright Avancier Ltd 2106