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.
Today, I’d like to write to you about the Assignment relation and subsequently about layering and ‘automated business behaviour’.
I can understand the wish of the designers (and now maintainers) of the ArchiMate language to keep it as simple as possible. Don’t keep on adding concepts and relation types if existing one can do the job. There is a small ‘but’ here: you’re not going to get almost all of the CXX-level types to read and understand the language any in depth. They need other forms of information, so if you accept ArchiMate as the language mainly for and between architects, information managers, and designers and such, you can give yourself some room. Even then, some enterprise architects already struggle (but I don’t think we can blame ArchiMate for that too much). On the other hand, you have been adding a couple of concepts (Contract, Collaboration and Interaction) which could be left out without hurting the language’s expression too much, especially if you make Junctions just a bit more specific as well as usable in other parts of the language.
To be honest, we can do without Interactions. Even those things that need to be done really strictly together (e.g. two employees opening a bank vault together, each with his own key) are in process terms (e.g. in BPMN) just a process with two tasks that run in parallel. If you keep Interaction, maybe to signal the importance of the togetherness of the process, make it a specialisation of Process. But I digress. The subject is Assignment.
The core role of Assignment is to assign active elements to behavioural elements. E.g. a Business Role is Assigned-To a Business Process to signal that that Role performs the process. To prevent the number of relation types to grow too much, Assignment is also used for:
- Assigning a Business Actor to a Business Role. This might be a bit of heritage. In the earliest ArchiMate versions a Business Role had somewhat of a halfway ‘active’ halfway ‘behaviour’ status, so assignment between Business Actor and Business Role still was a bit like assigning an active element to a behavioural one. The old Business Role behaved like an active element towards business behaviour but as a behavioural element towards Business Actor. The Business Role as some sort of abstraction of actors (their responsibility) as it is now is – I think — an improvement in ArchiMate 2. Assignment is still used for this relation, mainly I guess because you do not want to drown ArchiMate in a sea of relation types and because of backward compatibility (which is something of a double-edged sword).
- Assigning System Software to a Device signalling ‘deployed on’. Here again, there is a bit of heritage from the ArchiMate 1 and pre-1 days. In ArchiMate 1, System Software was positioned as behaviour (of the Device)and so it was quite natural to have an Assignment between a Device and System Software. In ArchiMate 2 the Infrastructure Function was included (another improvement) and System Software became fully an active element but the Assignment between it and Device was kept (for backward compatibility, I guess), now meaning ‘deployed on’ instead of ‘performs’ (but doubling a bit with another form of deployed-on, see the next one).
- Assigning Artefacts to Nodes. Here Assignment means ‘resides on’.
- Assigning Locations to various other elements. This one was new in ArchiMate 2. It means ‘takes place (behaviour) or resides (active/passive structure) at’.
- Assignment between an Application Component and business behaviour signals that this Application Component ‘performs’ that business behaviour, or in other words: that that business behaviour is automated. A sibling Assignment exists between Application Interface and Business Interface.
To start with, note that a Business Role is some sort of abstraction of a Business Actor. The first Assignment (between Business Actor and Business Role) might thus be replaced with a Realisation. This opens the way for a much more elegant way to represent automated processes, namely by allowing Application Components (and System Software of course) to also Realise a Business Role, see ‘robotic roles’ discussed in Section 28 of Mastering ArchiMate Edition II where the proposal to let Application Components Realise Business Roles to denote an automated business ‘actor’ is described. And see below.
The second Assignment, from Device to System Software has remained and it now means ‘deployed on’). I ran into problems with that relation when trying to model virtualisation (Section 16 of Mastering ArchiMate), as you cannot Assign System Software to System Software in ArchiMate. It is of course easy to fix that (and frankly, I expect you to do that), but in that case don’t forget the then missing case of Assigning Application Components to System Software. Application Components generally run in some sort of runtime (an OS, or other) or platform (which is what System Software is intended for), so in the case you keep this relation, you should also allow us to model an Application Component ‘deployed-on’ System Software.
And what about ‘resides on’? Suddenly there are three ways to show that a platform requires another platform.
- System Software Assigned-To Artefact Realises System Software.
- System Software Assigned-To Infrastructure-Function Realizes Infratructure Service is Used-By System Software, or System Software Composes Infrastructure Interface is Assigned-To Infratructure Service is Used-By System Software. This, by the way, becomes simplified to Assignment when you follow the suggestions of the previous letter.
- System Software is Assigned to System Software
With the use of a few derived relations:
Platform 1 Realises, is Used-By and is Assigned-To Platform 2. Isn’t that a bit much? Maybe. We need enough power of expression in the language for it to be ‘rich’ in its usage. By the way, if you switch the strength of Assigned-To and Realises (as I’ve proposed in the Section 28 of the book), the ‘deployment’ Assigned-To becomes valid as a derived relation of the ‘resides-on’ Assignment and the Realisation relation as well as the route via Infrastructure Function.
The third one is Artifact resides on Node. This in fact means that the bits of the Artifact are part of the Node. Destroy the Node and the Artifact is destroyed as well. That sounds suspiciously like Composition.
The fourth use of Assignment is ‘resides/takes place at’. Why don’t we use Association for that?
By the way, since Assignment has become directional in ArchiMate 2, might it not be better to give it a directional representation? I would suggest to drop the small black circle at the end (not the beginning) so it is close to the Composition and Aggregation in its form which is appropriate as its meaning is also closer to those than to, say, Used-By or Realisation or Used-By. Maybe with an arrow head. Here are two possibilities:
Layering and Automatic Business Behaviour
Let’s talk about the fifth use of Assignment: signalling automated business behaviour. Many enterprise architects who (sometimes almost religiously) stick to the view that ‘EA is not about IT’ (they’re wrong, its is also about IT) want to be able to model everything in this business layer. Architects love abstraction. Others will happily combine elements from the business layer and the other layers to show what is going on.
Within ArchiMate lie some seeds of confusion for both approaches. A serious one is about the positioning of the ‘business layer’. As an illustration, a simple question that baffles many could be: “I am offering a web site to a customer. Is that a Business Service or an Application Service?” Or both? Even the ArchiMate specification itself shows the confusion in the Telebanking example where the example provided effectively shows the bank (instead of the customer) use its own telebanking application.
(Tip for beginning modellers: add a few extra elements from other ‘columns’ to see if your pattern still makes sense. E.g. if you are modelling behaviour, just to check if it makes sense try to add the ‘performers’ (active structure).
So, the business layer is somewhat confused: it can be ‘what humans do’ (supported by IT) and it can be ‘the abstraction of what IT does’, e.g. by Assigning Application Components to Business Processes and Application Interfaces to Business Services.
Layering in itself has advantages and disadvantages and I’m afraid ArchiMate shows some history here as it was designed in a time where EA was still about (and by people who lived in a world where) the business layer was about ‘humans’ and their processes being ‘supported by applications’.
If I were designing a new EA language today, I probably think long and hard about layering. Now that you are trying to go forward from an established (but imperfect) base, there are less options. But one option that we do have is to at least relax the way layers are forced upon us. For instance, if we would be able to flow and trigger between behaviour of all layers and if for instance Business Processes could consist of a mixture of business behaviour and IT behaviour, the language could become a lot stronger in describing the situation in real enterprise. For instance, why can’t we do something like this?
I.e. some human enters data in an application, this application works with the data and triggers infrastructure which flows information back to the application (which is an Artifact for the infrastructure and a Data Object for the application). The infrastructure function also triggers some human work (e.g. a log file or a print ends up somewhere and someone reads that). Having this freedom also makes it easier to connect with languages like BPMN (which has no layering at all). A simplified view in ArchiMate would be:
Originally, Assignment was about assigning behaviour to performers (active structure). These days it is used for many things. I think that can be cleaned up.
Originally, the business layer in ArchiMate was ‘the human layer’ (except that a little bit of confusion quickly entered with Assignment between application layer and business layer to signify automated processes). But these days, business processes are not just human work, sometimes they may even be fully run by IT. It is of course possible to go back to that clean separation between humans and IT. But in that case, we should lose the current way of expressing automated processes, because Assigning Application Components to a Business Process is a shortcut that messes everything up. We might maybe add Application Process and Infrastructure Process and have processes as something that is not purely human, something that is not bound to any layer. In the business layer we might have Human Process and Human Function. Let’s in that case not call it the ‘business layer’ at all but the human layer. Or maybe the ‘human domain’. And then we need the ‘EA’ domain to stitch it all together. My guess is: that will be a too wild move for you.
Or we decide that the Business Layer is more than just human, it is also an abstraction of IT. In that case we must let Application Components (and System Software) Realise Business Roles (Robotic Role) instead of Assigning them to Business Processes. Here the two ways are then both shown:
Filling in the blanks (interfaces, services and such) is left as an exercise for the reader*). And the same for infrastructure. If IT performs business behaviour, we do not use Used-By (because it would be using itself) we use only Realisation. Let’s drop the use of Realisation for anything except crossing layer boundaries and abstraction (see also my third letter).
Anyway, there are several ways to fix this and make the whole thing more clear and more consistent.