Ambiguous terms in architecture frameworks

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.


This is one of several related papers on at

Research done for the BCS into “architecture” sources revealed ambiguities in and discrepancies between sources.

This paper addresses some ambiguities, including three of the most ambiguous terms: Service, Interface, Function.



Architecture?. 1

Data Architecture?. 1

Function?. 2

Capability?. 2

Service and Interface?. 3

Type, instance and thing?. 4

Actor and Role?. 4

Aside on “systems thinking” and system complexity. 4

The impact of ambiguities on ArchiMate modelling in practice. 5



What does it mean to define, govern or maintain "the architecture" of a system? 

The architecture of a system is an abstraction

The architecture is only evident in a (mental or documented) system description.

Moreover, infinite different architectures can be abstracted from any operational system (or "real machine" as a system theorist might call it).

The only definitive and tractable architecture is one found in an agreed architecture/system description.


So, to maintain "the architecture" of a system means aligning:

·         The properties of the operational system, which are testable

·         The properties recorded in an agreed architectural documentation, which is readable and shareable.


Contrary to what you might infer from ISO 42010, there is no third thing identifiable or recognisable as “the architecture”.

Data Architecture?

By way of introducing terminology issues, data architecture provides an example.

An IS architect thinks of data at rest (stores) and in motion (flows), the data structures they contain (logical and canonical data models), data qualities, data owners,

An IT architect thinks of disc arrays, NAS, SAN, active/passive, synch/asynchronous replication, availability and disaster recovery.

Different architects use words with different meanings.


A Business Function is clearly a unit of Business Capability in TOGAF, a logical business component in a functional decomposition structure.

But in other sources, a function is a behaviour/process.


ArchiMate uses the term function in a somewhat ambiguous way.

In some contexts am application function is an application process.

However, the application function symbol is sometimes used to represent a smaller application component within a larger application component


The terms function and process are used with various meanings other than the first two below.

What we call a

Others may call a


For example in



a component or chunk of business capability

TOGAF-style structured analysis.



a logical step-by-step sequence of actions

UML activity diagram, flow chart



an outcome or purpose of a system




an instance of a program running on a compute

in the “Task Manager” on your lap top


Note also the ambiguity of transaction, which is used for two kinds of process:

Transaction: any request-reply exchange, including ones that encompass a long-term business process.

Transaction: a success or commit unit acting on data resources.


A capability is not a singular architectural entity.

A capability is a view of, or aggregate of, the entities in an enterprise architecture meta model.

Capability = a combination of processes, people and technologies that deliver desired effects.

Capability = a logical encapsulation of those parts of an enterprise or system that deliver required products or services.

A capability can be seen as a business function + aims + activities and resources needed to deliver the effects desired of the named function.

Read Capability-Based Planning in an EA context for more.

Service and Interface?

The terms “service” and interface” are especially ambiguous.

We distinguish addressable interfaces and invokable services.

But the terms are used as synonyms.


The Web Services Definition Language is an Interface Definition Language that names concepts as shown below.


Behavioural view

Structural view

External view





Internal view



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



For example in



A contract, or signature only, for invoking processes to deliver a desired result

Menu item

ArchiMate and TOGAF examples above



A structure that defines (and perhaps offers) several services of the first kind.


A WSDL file



A structure that offers services of the first kind, a broker to service providers.



Data flow


A data structure passed from sender to receiver.


ArchiMate object. TOGAF application communication diagram

(Logical) protocol


Rules used to convey data flows, over channels.


File Transfer Protocol (FTP)

(Physical) channel


Medium used convey data flows, using protocols.


ArchiMate Communication Path



Any component that sits behind a published interface.


A "microservice"

Available app


The availability of an application to users, provided by IT operations.



SLA contract

Service, Interface

Whatever services are listed in a contractual document.



Type, instance and thing?

Other confusions include those between:

·         Interface definitions, and façade components.

·         Types, instances and things.


Instantiation by design and creation of an instance (e.g. an OOP object) is one thing.

Instantiation by prompting a thing (e.g. a human actor) to instantiate a type (a role) is another.

We never model human actors as themselves; we model only the roles that actors play in our systems.

Human actors can do more for (and against) a system’s purposes than any role defined in a system model.

Actor and Role?

A component type is defined by the behaviour it can perform (or services it can offer).

A Role is a component type. E.g. barber, customer, supplier, or union member (defined by its ability to pay union dues, vote for a strike, and claim union benefits).


A component instance is a named and addressable individual who can play the role of the component type.

An Actor is a component instance. E.g. you are a named actor who may play the role of union member.

An Actor is not necessarily human. E.g. an organisation unit is a named individual, performing one or more logical business functions. (See next question.)


One Role can be played by many Actors. E.g. the role of union member can be played by many named actors.

One Actor can play many Roles. E.g. you can play any number of roles (and do more than is described in any role definition).


Architects never model an individual an Actor per se; they model only the Role(s) that an Actor plays in systems of interest.

(Indeed, the UML Actor usually = an ArchiMate or TOGAF Role.)

Aside on “systems thinking” and system complexity

Enterprise architecture can be seen as an application of general system theory, which is about rules and roles:

·         About regular processes performed by actors playing roles.

·         About the rules actors follow to perform processes.

·         About information feedback loops that communicate the existence of entities and occurrences of events.

It pays no attention what actors can do beyond defined roles (or their motivations).


What some call “systems thinking” is different; is rather about a social organisation, a group of human actors:

·         Who cooperate to meet some goals, and may define their own rules and roles.

·         Who can inform each other of ad hoc events in unstructured ways.

·         Who are infinitely flexible and creative (but need motivation).


What systems thinkers call a complex system has complex and adaptable human actors.

But this kind of social organisation is barely (if at all) a system to a system theorist, for whom a complex system is complex set of rules and roles.

The impact of ambiguities on ArchiMate modelling in practice

The common practice is draw whatever architecture diagram you think will communicate your meaning to your reader.

This not only makes the ArchiMate language standard irrelevant to that particular use.

It also hinders the education of some architects about architecture concepts.


The question is not whether ArchiMate users draw “complete” or even “correct” models.

It is whether diagram reader can trust what a remote diagram writer meant so say (however incomplete or incorrect).

I believe we should start by firming up the meanings of the concepts in the ArchiMate generic meta model.

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.

This 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!

People wrongly think using an ArchiMate drawing tool means they are using the ArchiMate language.

They use the boxes and lines with different meanings; and they fail to differentiate the generic meta model concepts.

When we come to teach them the concepts, their experience of drawing ArchiMate diagrams makes it harder for them to learn the concepts.


Correspondent: What do you mean "with different meanings".
Reply: Architects use the ArchiMate service box to represent a service, a component, or an interface.

They use the function box to represent a process step, or a node in a business function decomposition.

They use the lines in even more baffling ways.
Poor teaching of the standard is (sorry to say) is at least partly due to ambiguity in the standard itself.

Correspondent: We can't prevent people from making language mistakes.
Reply: We can try to minimise mistakes.

Natural language exchanges iron out misunderstandings.

Writers and readers of ArchiMate diagrams - separated in time and space - may find it impossible to understand each other.

The ArchiMate standard falls short of reducing misconceptions about what the symbols are supposed to mean.

Correspondent: Maybe we can investigate code generation tooling, since to generate working code, ambiguities need to be resolved.
Reply: Certainly, the OMG have to specify UML well enough for code generators.

And the code generators teach the UML diagram drawer to use the right symbols for the meaning they have in mind.

Correspondent: This is what I'm trying to do with ArchiMate, but architecture on the level of ArchiMate tend to be conceptual.
Reply: As Grady Booch says: “All architecture is design but not all design is architecture.

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”

We can’t generate code from architecture-level diagrams – more’s the pity.

Correspondent: Another approach could be to lead by example.

Google for examples, and there is not much out there. Supply good examples and the rest will follow.
Reply: Before that, the ArchiMate language standard should differentiate the four generic concepts better.

Correspondent: If every architect has to reinvent the wheel, inconsistencies are bound to emerge.
Reply: Yes. And the ArchiMate standard falls short of doing what it could to limit inconsistencies.

People who read the standard go on to use the symbols with different meanings.

This means the standard is serving as a list of symbols rather than a language.



Creative Commons Attribution-No Derivative Works Licence 2.0              24/03/2015 18:15

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” 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