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.


The problem... 1

Generic terms and concepts - after system theory. 2

A more controlled vocabulary for enterprise architecture. 3

On abuse of  the term “service”. 4

Conclusions and recommendations. 5


The problem

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.



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.



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.



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.

Generic terms and concepts - after system theory

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.)

A more controlled vocabulary for enterprise architecture

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.


[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.


[A logical component] realised or played by individual actors, specified in terms of services provided and/or processes performed and abilities required.


[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.

On abuse of  the term “service”

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.

Conclusions and recommendations

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