The ArchiMate NEXT — I keep writing and fixing ‘NeXT’, that’s history for you — snapshot drops the Business-Application-Technology layers (somewhat). This has been an essential design feature of ArchiMate since its inception. Another fundamental choice has been the split into ‘actors’, their ‘behaviour’, and what they ‘act upon’.
No TL;DR today. This is a short enough post.
This is what it said in the first TOG edition of ArchiMate:
The language consists of active structure elements, behavioral elements and passive structure elements. The active structure elements are the business actors, application components and devices that display actual behavior, i.e., the ‘subjects’ of activity (right side of the Figure 3). Then there is the behavioral or dynamic aspect (center of Figure 3). The active structure concepts are assigned to behavioral concepts, to show who or what performs the behavior.
The passive structure elements are the objects on which behavior is performed. In the domain of information-intensive organizations, which is the main focus of the language, these are usually information or data objects, but they may also be used to represent physical objects. These three aspects – active structure, behavior, and passive structure – have been inspired by natural language, where a sentence has a subject (active structure), a verb (behavior), and an object (passive structure).
It is that last part that says something important. ArchiMate as it was originally conceived was about telling a story about the enterprise. It was seen as a language, and languages are there to communicate. Communicating was a big driver for the development of ArchiMate, they wanted to design a language that would enable people to communicate in many ways about those complex business-IT landscapes.
The idea behind derived relations was originally even to create a setup where detailed models (nice for engineers and architects) could be automatically summarised for management. The name ArchiMate, by the way, comes from Architecture-Animate, the idea that this should be something pretty dynamic. That original derivation is a seductive — I fell for it too (for a short while) — but in the end rather naive thought, which by now has mostly disappeared from ArchiMate practice too.
But ArchiMate is modelled after natural language. And that means it comes with some disadvantages. One major disadvantage is that it splits what is in reality ‘one’ in two. In my Discussing ArchiMate chapter of Mastering ArchiMate (see previous post where it can be downloaded), I come up with the following stripped down example:
The idea is that you do not really need two aspects — active for objects that perform behaviour (in ArchiMate that is what Assignment is for) and passive for objects that are acted upon (in ArchiMate that is the Access relation). An object is an object, If it is accessed it is passive. If it is assigned to behaviour it is active. An object can be both at the same time.
I came across many instances where ArchiMate restricted me in an unnatural way to keep models/views simple. One has been this split in active/passive. I guess, this split came not only from natural language, it was also coming from the fact that the designers only worked with administrative organisations, hence (above) “the domain of information-intensive organizations, which is the main focus of the language” [it. GW]. But why not simply say that you have structure, and it is active when it is Assigned-To behaviour and it is passive when it is Accessed by behaviour? Then you get what is shown above and suddenly the patient becomes what they are in realty: both ‘passive’ and ‘active’.
As it turns out, the current designers have taken up the challenge, it seems. They now have added this example as follows in the ArchiMate NEXT snapshot:
Challenge accepted 😉.
What if the doctor is a psychiatrist and his therapy sessions successfully change the patient’s psychological problems, effectively by helping them to rearrange their neurons? What if an angry patient threatens a doctor that operates on them? What if the patient is scared in the MRI and needs to be helped/instructed? Of course you can all do that this split way but it becomes sometimes laughable and it is always inelegant.
The ArchiMate NEXT example also has a distinctive Descartes-like mind-body separation vibe, which is so out of date (we know after all today that even our microbiome influences our minds) that it is quite funny.
But above all it is an unnecessary consequence of forcing reality to (partly) look like how natural language grammar works. After all, “he told the doctor he had a pain, and eventually the doctor operated on him”, we may have a separate subject ‘he’ and object ‘him’ grammatically, but in reality we know that he and him are one and the same. So, why cannot our model simply show that by making ‘him’ and ‘he’ one element?
There is a different way we can look at modelling than looking at it as storytelling. We can look at it as being a map, or a blueprint. If you do that, I suspect you get a much cleaner idea about what your modelling grammar has to do and why it isn’t necessarily a good idea to force elements of the grammar of human language onto it. After all, before we all had GPS route apps, we used maps and not linguistic descriptions to get from A to B in our cars. Maps simply were a better tool. (Aside: we did use descriptions sometimes to guide us in our cars, it was called a puzzle-tour and we used language to make it harder, not simpler. I think these still exists.).
A modelling language/grammar should be as clear as possible about what reality is, because it is (future) reality what you want to communicate in one way or another. So, for instance having to model that human patient as two different elements is not making what you are showing simpler and clearer.
[Update 29/01/2026] Maybe I should add this: the idea of having separate behaviour and structure is great, I like it. The idea of using subject-verb-object is great too. However, I think that you do not need to separate structure into active and passive (as natural grammar does) to get that effect. You can improve on natural language grammar here, because your expression is not text (which requires roundabout things for this, like using ‘he’ and ‘him’ relying on the underlying working of our language sense to turn both words into one entity) but views consisting of elements and relations. Visual modelling (like in ArchiMate) is closer to maps and blueprints than it is to storytelling, and separating active/passive structure has in my view been an unnecessary adoption in a visual grammar of something that necessarily exists in text grammar. If ArchiMate can lose layers, it can lose this too.
I suggest we should simply have structure, and if that structure is assigned to behaviour we have just modelled that the structure is active. If it is accessed by behaviour we have just modelled it is passive. It can be both concurrently.
Just like in the real world.
PS. Remember this adagium: “the best model of the world is the world itself”. The more you remove the modelling language from the reality we experience, the less practical it becomes. Using natural language grammar as the bottom layer reminds me of using tokens and pixels as a foundation for intelligence…
This was the third article in a short series about ArchiMate NEXT. The previous ones were: ArchiMate NEXT drops BAT. Now what? and ArchiMate NEXT: At your service!. The next (and last) one is ArchiMate NEXT: summary verdict, “what’s in a name?”, and a wild ride.
[You do not have my permission to use any content on this site for training a Generative AI (or any comparable use), unless you can guarantee your system never misrepresents my content and provides a proper reference (URL) to the original in its output. If you want to use it in any other way, you need my explicit permission]
R&A IT Strategy & Architecture 
hi Gerben, very nice article about the passive/active split!
You also make some remarks about the derived relationships. I wonder if tooling better supports this, this would have been a very nice feature. In tooling I know of, you still have to model the derived relationship, it should be an under water relation that in reality is not a first class member in the model.
Another thing I was wondering for a while. Could the ArchiMate language just not be made from some common generic concepts, with relations and specialisations. Next is going in that direction in the process behaviour. E.g. three generic concepts: object, service, process I think looks to me enough?!
Hans
LikeLike
Thank you. There are also interesting follow-up discussions between Marc and myself on LinkedIn in the ArchiMate group here and here.
Regarding derivation, the idea behind this was naive to begin with (but seductive, I was taken in for a short while too). It was actually key to the first ArchiMate documents, that this should be possible. But the problem is that you cannot have meaning just based on grammar (in this case: grammatical ‘operations’). So, over time this stuff has become only important for the metamodel creators, not for model creators who can use any type of relation (derived or direct) in exactly the same way. I think the standard even says that explicitly. All are equally valid, grammatically. And that is fine for modellers.
ArchiMate has some higher up ‘metameta’ stuff that ends up producing the metamodel. Specialisations are easily said, but do come with some nasty questions. Like, should the specialisation have to be able to do all the things the parent can? I.e. could you create a specialisation that removes certain allowed relations (this breaks the Liskov substitution principle). I suspect that you will always end up with a compromise between this kind of ultimate elegance and practicality. The world isn’t logical, it is messy (link to the introduction of my columns at EAPJ that contains a beautiful quote from Terry Eagleton).
LikeLike