Dear TOG,
I hope this letter finds you well.
As shepherd of the ArchiMate standard, you are currently working on its next iteration. As I am not part of the ArchiMate Forum, I am going to send you a few open letters with suggestions for improvement of the language and what to do an not to do. I will be voicing some stern/harsh criticisms on ArchiMate in these letters, please don’t take it personal, I’m only interested in strengthening the language which I already find useful as it is. And I apologise beforehand for my language here and there.
This is the third of such a letter. The previous ones can be found here and here.
Today, I’d like to write to you about the Realisation relation and subsequently about Composition.
Realisation is used for two things now:
- As an abstraction relation between layers
- As the relation between ‘internal’ behaviour and ‘external’ behaviour within a layer.
I’m going to address the latter now.
What is ‘external’ behaviour anyway and how is it separated from ‘internal’? It is a key underlying concept in ArchiMate. From the specification (and I apologise for the long quote):
[…] we make a distinction between an external view and an internal view on systems. When looking at the behavioral aspect, these views reflect the principles of service orientation.
A service is defined as a unit of functionality that a system exposes to its environment, while hiding internal operations, which provides a certain value (monetary or otherwise).
Thus, the service is the externally visible behavior of the providing system, from the perspective of systems that use that service; the environment consists of everything outside this providing system. […] For the external users, only this exposed functionality [is] relevant. […] Services are accessible through interfaces, which constitute the external view on the active structural aspect.
An interface is defined as a point of access where one or more services are made available to the environment.
An interface provides an external view on the service provider and hides its internal structure.
In my opinion, there is a fundamental problem here. I am going to explain this with a simple example: The Flower Shop.
The Flower Shop
We are going to model a very simple flower shop. In this shop, the customer enters, requests a beautiful bouquet. The details are discussed with the sales employee at the counter who then goes into the back and tell the floral arranger in the back what to create. The floral arranger creates the bouquet and it is given to the sales employee, who gives it to the customer in exchange for money.
The customer interacts only with the sales employee. The sales employee’s behaviour is what the customer’s behaviour (his ‘process’) interacts with, so that part of the flower shop is the ‘external behaviour’, the service. The behaviour that takes place in the back is invisible to the customer, so it is the ‘internal’ behaviour. We make things simple by assuming that the internal behaviour is only the flower arranging, not the interaction between sales employee and flower arranger.
In a BPMN model, it looks like this:
The ArchiMate version could be this:
I’m using Informal Collaboration here instead of the official Collaboration/Interaction elements which I discussed in a previous letter. The customer’s process uses all the behaviour that is in the upper lane, it is that which is visible to the customer. It is — I think — clearly “exposed to the environment” as the specification tells us.
The Issue
Now here is the problem: ArchiMate tells us that the Business Process is the internal behaviour and the Business Service is external behaviour and these are separate. But have a look at the process: both the invisible and the visible behaviour make up the process together! It is not so that the process is the ‘hidden’ part and the service is the ‘visible’ part. The process is all of the behaviour, including the parts that are visible to the outside. Now, which relation is appropriate for that? That is the Composition relation! And it looks like this:
And this should not surprise us at all. Have a look at how we are supposed to model for instance the user interface of an application:
We are all aware that the application and its user interface are not really separable, are we? So the Application Interface in ArchiMate is part of the Application Component, but on the behavioural side we do it differently.
I suggest we simplify by using Composition on both sides:
You might be tempted to argue that the ‘visible’ tasks are not completely visible, but in that case you are going to make another split (e.g. splitting ‘Get Order’ in a part that the customer sees and a part het does not (e.g. entering it on the computer). But that does not help: whatever you split, the part you call ‘visible’ is still behaviour of the Sales employee and thus still part of the process. In other words: the internal/external separation in ArchiMate is inconsistent, it should be external/whole and not external/internal. As long as you stay within ArchiMate this doesn’t really trouble the modeller, but as soon as you want to consistently model in multiple environments (BPMN used here as the other environment) you’re in trouble.
Composition
I’m aware this leads to another issue. That has to do with having a service that is the result from two or more Business Processes (or Application Functions, etc.). So, let’s look at an alternative Flower Shop process. Suppose, our flower shop has two Business Processes that together Realise the Business Service. That now looks like this:
I generally do not use this pattern within current ArchiMate, but I know that the people who proposed the current idea of internal/external and service like these sort of abstractions/aggregations. I’ve made the Flower Shop somewhat more complicated. In BPMN it looks like this (you can click on the images to get a larger version):
The single service that is visible for the customer is part of what we think of as two processes. Maybe we are a large store with more than just flowers and separate cashiers. Now, with Composition instead of Realisation we get this:
This is forbidden in ArchiMate, not just because we are using Composition, but because Composition is defined such that it forbids multiple parents of a child. This is an influence from software engineering. In software engineering of old, memory sharing (two pointers to the same piece of memory), dangling pointers and memory leaks have been major sources of bugs in programs. Hence: they are not liked by programmers. Hence the strictness about ownership; e.g. UML forbids it. But we are enterprise architects and not software architects, right? Do we have a risk of ‘dangling pointers’ and such in ArchiMate? Is it that bad that software engineers, used to UML balk at this? How bad is it that software engineers have to learn that the world is not like software?
Oh, and by the way, we already do have this ‘problem’. Multiple parents of a Composition in ArchiMate are already unavoidable as I showed in a blog post in 2013 and one in 2014.
That older blog post, by the way also explains that the Realisation relation between ‘internal’ en ‘external’ behaviour can be seen as outdated ‘heritage’ in ArchiMate. After all, the idea of a service as some sort of abstraction partly comes from the fact that ArchiMate 1 and before did not have the Motivation Extension with its Requirement element. The services in historical ArchiMate had to fulfil those roles too, but that is not necessary anymore.
So, I think we might allow multiple parents in a Composition relation. After all, we do have true sharing which we should be able to model. Have a look at the following. We want to show that we have infrastructure services that are composed of several ‘building blocks’. In ArchiMate, we now have to do this:
One thing we cannot do now is to derive relations between the Nodes or Building Block Infrastructure Services and the Application Functions. But what if we would be allowed to do this?
Or, if we make it complete and replace Realisations too (because these are derived from the same illogical internal/external split):
And what happens when the Linux Server dies?
Well, our applications cannot function because they both depend on that Node for the shared NFS shares. This is perfectly shown by the fact that both runtimes (which are made up of building blocks) are unavailable when the NFS server is unavailable.
Summary
I’m proposing to fundamentally adapt the internal/external split to a whole/visible-part (or whole/usable-part) split. The split is not consistent, neither internally, nor when looking to the world of processes.
I’m proposing to use Composition as the relation between process/function and service, thus simplifying the language.
I’m proposing relaxing the limitation of single-parent for Composition. It can still be valid in software engineering parts of your enterprise architecture, but ArchiMate is not a software engineering language and enterprise architecture is not (just) IT architecture.
Yours truly,
Gerben Wierda
Team Coordinator Architecture & Design at the All Pension Group (APG)
Former Lead Architect of APG Asset Management and of the Dutch Judiciary
Author of Mastering ArchiMate and Chess and the Art of Enterprise Architecture
R&A IT Strategy & Architecture 
The interesting thing is that visually the BPMN diagrams reveal more information without actively translating the notation.
LikeLike