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.

WSDL

Behavioural view

Structural view

External view

Operation

(Event/Service)

Service

(Interface)

Internal view

Hidden

(Process)

Address only

(Component)

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	ArchiMate object. TOGAF 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	ArchiMate Communication Path
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.

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 05/03/2018 17:09

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.