Ambiguous
terms in architecture frameworks
THIS OLD PAPER HAS
BEEN SUPERCEDED BY THIS
NEWER PAPER
THE REMANTS BELOW
ARE OUT OF DATE
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 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.