Let’s start with the two images of the July 2020 ArchiMate Quiz:
The questions were:
- ‘What’ do these diagrams illustrate about the ArchiMate language? (One point)
- How many of these ‘whats’ are there? (One point for a good answer, one bonus point for the number of additional ‘whats’ that makes it complete)
- What analytical observation can be made about frameworks in general and ArchiMate in particular related to the above and what is the cause of this? (Open question, points awarded by the jury (me) based on cleverness, wit, meaningfulness)
The modeller attempted to model the relation between a Sale and that what is being sold (black relations). The coloured Associations are ‘derived relations’ that were not explicitly modelled but can be ‘created’ based on the black ones. We’ll do a very short intro into derivations for those new to ArchiMate. Note: colour has no meaning in ArchiMate, using this freedom, my diagrams have a specific colouring that separates active/passive structure and behaviour. It works better than what is generally provided in tools in my experience. It is derived from the ur-ArchiMate ‘default’ colouring. See here for an explanation. For additional clarity I also generally add the element type to its label. Both style elements make it easier for people to understand what is being modelled.
This is a long read, especially the question 3 part. Bear with me.
Extremely short explanation of ArchiMate’s ‘derivations’
Before going on and for people new to ArchiMate, I will shortly explain a key concept of the language. ArchiMate has two types of relations: the core relations (these, together with the elements make up ArchiMate’s meta-model, the actual structure of the language) and derived relations. In a model (and also in the meta-model) it is possible to combine paths along relations to create ‘shortcuts’ between the ends. In an example:
Here, the Sales System is used by the Accounting System which is used by a Business Process. If you model the black relations, the red relation can be ‘derived’ without explicitly modelling it using rules ArchiMate has for these derivations. This article is about the derivations in ArchiMate 3.1. These were changed with respect to ArchiMate 3.0.1, which had them changed with respect to ArchiMate 2.1 (about ArchiMate 3.0 it is best to remain silent), which had them changed compared to ArchiMate 1. If you let the rules of derivation loose on the core relations, you get the relation tables in Appendix B of the standard, which lists all the possible combinations. All the relations of the core meta-model and all the relations that can be derived from these, together make up all the allowed relations in ArchiMate, tens of thousands in all. According to the standard, all these relations are ‘proper’ relations and are as valid as the ‘core’ ones. Hence, the difference is mostly ignored by everyone.
Before ArchiMate 3.0 was released, I urged TOG to make some changes to ArchiMate 2 in a series of open letters. One of these was Open Letter to TOG #7 and it was about fundamental problems with derived relations. As with some other suggestions I have made over the years, the issues was addressed (not necessarily in the exact way I proposed, of course). The change did not make it into ArchiMate 3, nor into ArchiMate 3.0.1 (which was a bugfix release) but in ArchiMate 3.1, the issues has been addressed and this has led to a fundamental change in ArchiMate. So fundamental that it is about as visible as the foundation of your house, i.e. ‘not’.
The quiz
The first question was: ‘What’ do these diagrams illustrate about the ArchiMate language? Several answers commented on the model, but the question was not about the example, but about the language. The correct answer is: These diagrams illustrate derivations rules. That answer would have given you a point. Specifically: they show an example of a valid and a potential derivation, a difference that is new in ArchiMate 3.1. It also already shows something else (I gave that away, sort of), but we’ll get to that.
But first, we will look at potential versus valid derived relations. We will do this at the hand of a simple example: a car. This car is an old-fashioned gas-powered car with four wheels, which is modeled as follows:
Now, the tank requires gas and the wheels require air. So, each of these is able to be served by a nozzle or valve connector, and we can derive a relation between the nozzle and valve connector on the one hand and the car on the other, like this:
This is by making use of rule DR3 (the rules are all found in Appendix B) for two ‘valid’ derivations (in green). Both derivations make sense. The wheels require air, hence the car requires air.
Now, before ArchiMate 3.1, there was no difference between ‘valid’ and ‘potential’ derivations and this rather meaningful derivation was not available. Instead, the derivation available was the opposite. Starting with the car, knowing that the car requires both air and gas,
The old derivation rule said it was possible to derive the Servings from the interfaces to components of the car, so the following green and red Servings could be derived:
Now, the green ones make sense, but the red ones do not. ArchiMate 3.1 retains this derivation, but it has become a ‘potential’ derivation, meaning: it could be true, but you cannot draw the conclusion it is true purely on the model. Whereas for ‘valid’ derivations the standard boldly claims these “are valid in any model where these rules apply”. We’ll get back to that. Anyway, you are allowed to create such a potential relation in a model, but you cannot derive its validity from other relations. So far, so good.
The second question was: How many of these ‘whats’ are there? There are 8 ‘valid’ derivation rules, 11 ‘potential’ derivation rules and 12 additional constraints. The correct answer is 19. There are also 12 additional constraints/rules, so for the bonus point the correct answer is 12.
The ‘analytical observations’
ArchiMate 1 contained one rule for one set of relations (the — then — structural relations Composition, Aggregation, Assignment, Realisation, Used-By (now Serving), Association, and Access). ArchiMate 2.1 contained three rules for two sets of relations (the same for structural relations and two for the dynamic relations — Triggering in combination with Realisation and Flow in combination with Assignment). ArchiMate 3.0.1 split the relations in four groups: Structural (Composition, Aggregation, Assignment, and Realisation), Dependency (Serving, Access, and Influence), Dynamic (Triggering and Flow), and Other (Specialisation, Association, and Junction). It provided two rules, one for the combined group of Structural and Dependency relations (not differentiating between the two, so the split was rather meaningless at the time). As things stand now, ArchiMate 3.1 has four slightly different groups of relations:
- Structural (Composition, Aggregation, Assignment, Realisation)
- Dependency (Serving, Access, Influence, Association)
- Dynamic (Triggering, Flow)
- Other (Specialisation)
Note: Association is back in the dependency group (one reply stated that you were not allowed to derive with Association, but since ArchiMate 3.1 it has been moved from group ‘other’ to group ‘dependency’ and with the new rules, you can. Junction is not a relation anymore but is now as ‘relationship connector’ in a class by itself. Association’s meandering place in the standard illustrates the volatility of the standard in this respect, see also below). And it has a completely new setup of derivations based on not 1, not 3, but a whopping 31 rules/constraints. The intention of this is to finally give the whole derivation aspect of ArchiMate a solid footing (ArchiMate 3.0.1 did the same with providing a more solid footing for the elements themselves) while not making too many backwards incompatible changes in the table of allowed relations.
I did not expect anyone to come up with my observations (though if course Jean-Baptiste as chair of the ArchiMate Forum was rather correct in his), hence the request for ‘wit’ and ‘cleverness’. But here are mine:
#1: Frameworks tend to balloon over time and ArchiMate is not an exception. The original ArchiMate had 34 element types and one derivation rule. ArchiMate 3.1 has 60 element types and 31 rules for calculating derivations. This is a natural result of trying to do something that is impossible: mapping the real world onto discrete entities (both elements and rules). People who create and maintain frameworks are part of the more logic-oriented among us and they tend to try to ‘catch the world’ in their logic. As I observed in my review of the ArchiMate 3 update under “Specification Sickness, Definition Disease, Formulation Fever”:
Behind ArchiMate too lies the goal of removing misunderstanding by improving the structure of the language we use in talking about our enterprises. Most strongly we see this in the attempt to define a structure for modelling stuff related to our intentions (Motivation Extension). Yes, I can make a model about these, but one can wonder if this can lead to actual use and thus meaning. Will the model actually be used to decide things? Can it be complete and rich enough to be a reliable tool? Or is it just a nice but too simplistic illustration of a more complex reality? Note, such nice illustrations can be useful (and thus meaningful) of course.
But, the language is confronted all the time with the imperfections of the real world, imperfections which create the friction that makes movement possible, Uncle Ludwig would say. Perfect logic is like a perfect, frictionless sheet of ice, in the end it gets you nowhere. And the reaction of becoming ever more precise, to make ever more distinctions, is as valiant as it is doomed. This is an unsolvable problem and each constructed language will have to find its own sweet spot between leaving it to the speakers (use) and leaving it to the grammar (design).
ArchiMate 3.0, the Good, the Bad, and the Ugly/
As IT is an offshoot of logic (all that digital computers are is (classical) machine logic working at unprecedented speeds on unprecedented amounts of logical values), the influence of logic and mathematics on the world has grown. As I have written in the series On the Information Revolution, this has unprecedented effects on human society and thus on the world at large. But those that create the tools, the frameworks, and so forth generally pay little attention to the weaknesses of all that logic (let alone its fundamental limitations). So, while perhaps feeling a bit uneasy about the fact that they know that the result is not logically perfect — we see this unease when the initial statement that valid derivations “are valid in any model where these rules apply” becomes shortly thereafter “are valid with high certainty” — there is still a fundamental conviction that logic will bring certainty about meaning. And yes it does, but the more certainty it brings, the more detached from reality (and meaning) it gets. There is an uncertainty relation of sorts at play here. Let’s illustrate at the hand of the quiz example. First, have a look at these:
This is something that is quite logical. If a plank is not dry, we know the woordstack is not dry. The red derivation of the black relations in Diagram C is valid. On the other hand, if the woodstack is not dry, the plank might not be dry, but we cannot derive it from the black relations alone. So, all is well? No, because while the above relations are all allowed in ArchiMate 3.1, the derivations of the coloured ones from the black ones are not allowed. This is because one of the constraints is that you cannot derive relations when the starting element is a Motivation element (you can the other way around, but only Influence and Realisations are allowed as a result, all this is meant to weed out too many silly results.).
If that was all, it was just a small constraint, but look again at the actual quiz diagrams:
Our ArchiMate-valid derivation on the right tells us that if a plank is sold, the woodstack is sold — but we cannot know that! And the ArchiMate-potential derivation tells us that when the woodstack is sold, we are not certain that each plank of it has been sold — but we are! In other words, in this situation, the potential derivation in reality is a valid one and the valid derivation is a potential one, as Jean-Baptiste also pointed out.
It is a nice illustration that you cannot catch reality in pure logic nor get true meaning from purely grammatical/logical operations (as Uncle Ludwig showed us over half a century ago), however hard you try, and that is an important lesson to keep in mind for modellers and those designing ‘logical’ modelling languages (or architecture frameworks). Every time you add (logical) volume to your framework you might have been ‘bewitched by logic‘ (which would be a good phrase to describe “2500 years of footnotes to Plato“).
A second observation that can be made is that all of this hardly matters. Take Association, it was a ‘structural’ relation in ArchiMate 1 and 2, an ‘other’ relation in ArchiMate 3.0.1, and as of ArchiMate 3.1 it is a ‘dependency’ relation. Apparently such changes could be made largely without anyone noticing (unless you read this story or are part of the core discussions, it is likely you would never have known). The fact that there is this new complex shiny logical edifice supporting the idea of derived relations is completely irrelevant for 99.9% of modellers. In fact, the whole edifice these days only exists to give a solid foundation to the calculation of the table of allowed relations, as in “Meta-model + Derivation-rules = Allowed-relation-table”. In real world modelling situations, you cannot rely on derivations (not even the ‘valid’ ones) to get you truly useful answers. The conclusion from 2017 still stands:
The derivation mechanism in ArchiMate has always been a bit of a naive dream at ‘student paper’ level, and in reality it is not that very important in real models, neither for producing ‘automatic viewpoints’ (which tool can do this?) or for analysis. It’s far more effective in ArchiMate to choose good modelling patterns and then analyse a model regardless of the derivation rules. They are not that important in daily practice.
The ArchiMate 3.0 Relations Table/
Silly me for spending roughly 2200 words on them, then…
P.S. Quiz winnners will be announced on the original Quiz post.
R&A IT Strategy & Architecture 
1 comment