ArchiMate NEXT: summary verdict, “what’s in a name?”, and a wild ride.

The proposed changes from ArchiMate 3.2 to ArchiMate NEXT are summed up in Appendix E.4 in the snapshot document. Summarising (with comment) all the actual changes (not “x has been moved to section y”). Since the first Edition of Mastering ArchiMate, I have included a chapter Discussing ArchiMate, that contained critiques about the design choices in ArchiMate and proposals for change. Several of these were implemented in one way or another (not always in a way I liked, though) over the years (so: not because I suggested them, of course, I wasn’t part of those discussions).

Misunderstandings, incompleteness, fuzziness over the years

When writing these posts on ArchiMate NEXT, I also found out that I had misunderstood things over the years. For one, while the first TOG Edition placed System Software in the Behaviour aspect, it turned out the original designers hadn’t done that at all. They just made a mistake in colouring it yellow (the colour then of the behaviour aspect/column) which then apparently made TOG put it in the Behaviour aspect. That apparently confused me.

What also happened was that in the original ArchiMate, Assignment was more or less meant purely for ‘performing’ or ‘executing’. So, a Device Assigned to a Software System was meant as: de Device executes the Software System. TOG ArchiMate 1 says: “A device is defined as a physical computational resource upon which artifacts may be deployed for execution.” [It. GW]. From version 2 on it becomes ‘storage or execution’. As a result, Assignment not only covered ‘executing/performing’ anymore, but also something akin to Aggregation/Composition of a Passive Structure element by an Active Structure element. It is a nice illustration how the original design missed some essentials in the ‘infrastructure’ domain (like storage), a domain that apparently wasn’t a very important aspect for them. TOG fixed some of that over the years.

Having said that, let’s wrap it up in this post and first discuss all the substantial changes as mentioned in Appendix E.4.

Generalisations (no layers/BAT, common domain)

These are the changes that are some form of generalisation/abstraction. Most importantly of course, all the behaviour has gotten generalised into a common domain. Also the various layer-specific collaborations have been generalised into a single one. And Business Role has become a clear generalised ‘role’ concept, and so is Path.

• Behaviour elements have been merged across layers, leading to a single set of service, process, function, and event (and Implementation event has been replaced by the now generic event element)
• Business, application and technology collaborations have been merged into a single collaboration element in the Common domain
• Business role has been replaced by a generic role element in the Common domain to which any internal active structure element can be assigned
• Path is now a part of the Common Domain

What I think of the squashing of this layer/domain-specific core behaviour, I wrote about in one of the previous posts: ArchiMate NEXT drops BAT. Now What?.In short, generalisations and abstractions are often nice, but you always pay a price in precision. If that precision is important to you depends on how you use ArchiMate. If your use is just high-over illustrative, it is probably fine. If you are talking about large models where your analysis depends on e.g. following a Serving Relation from an Application Service to an Application Function/Process, but not following a Serving relation from Application Service to Business Function/Process, you have just lost the opportunity to model this in ArchiMate. I am not convinced that this simplification is going to be great for everybody. It may limit the expressiveness so much that some (serious) uses get lost.

And while the layers are gone from ArchiMate overall, they still exist inside of the domains in a way:

Anyway, ArchiMate has been simplified, at least partly. Let’s therefore not forget this important warning, especially the generally left-out second part:

In every field of inquiry, it is true that all things should be made as simple as possible – but no simpler. (And for every problem that is muddled by over-complexity, a dozen are muddled by over-simplifying).

Sydney Harris, Chicago Daily News, Jan. 2, 1964

I suspect the way this simplification in one aspect has been done is going to make it harder to use ArchiMate for more precise models. I suspect, not-structured information like labels are going to have to do more heavy lifting, and that isn’t good. But I am uncertain.

Other

• Business interaction, application interaction, technology interaction, constraint, contract, gap, and representation have been removed

I must be happy. The removal of interactions was already suggested in Mastering ArchiMate Edition I in 2012. That Constraint is just another Requirement, or Contract just another Business Object I have argued for almost as long too, I think.

• The composition relationship has been removed

It could simply have been removed from the metamodel but still available, It can be handy to model that some elements are inseparable, like the Word GUI being inseparable from the World application. I think the effects will be limited.

• Aggregation from path to technology internal active structure element has been replaced by a realization from active structure element to path

And that is an improvement. What is also an improvement is the sentence “A path can be associated with the internal active structure elements it connects.” In the past, it was said that the Path could Aggregate Nodes and could be Associated with Nodes, but it wasn’t said explicitly what that would signify. There were the Nodes that are required for the Path to exist, and there were the Nodes that make use of the Path. Which one was which was never very clear nor were there such relations from Path shown in examples. You could sort of reason it out, which is why I put a proper explanation in the (free excerpt of) Mastering ArchiMate 😀). Getting Nodes to Realise a Path is an improvement over Paths Aggregating the Nodes that make them up.

• Relationships can now have cardinalities to express the constraints put on the instances of elements on their ends

This is nice, I think. Note: watch out for oversimplification (Harris, again. Man, I wrote that in 2014…). For instance, if your cluster solution is active/passive, both nodes are not identical. So using a 1..2 cardinality is misleading.

Taking everything together, do I like it? Can’t really say yet, because I cannot say yet how much these changes are going to affect the possibility to make good models until I have tried to create new ones. The changes are so substantial that the patterns of Mastering ArchiMate will have to be revisited. Can I still clearly model software platforms, virtualisation, and all these other patterns that I created examples for in the book?

By the way, some changes I have proposed in the past still 😀aren’t there. Like the possibility to Realise Flow and Triggers by behaviour elements, which I think would be very elegant. And some other things (see that chapter). Note: some proposals I have made over the years do no longer make sense.

Which brings us to some extras to finish off with today.

$\;Fasten^{your}_{seatbelts}\,$

What’s in a name? Going Wild.

Here are some remarks about the names of concepts, some of which lead to thoughts about structure of the gramma/language.

System Software

When System Software got its concept name, it was the operating systems and databases that were on people’s mind (as can be seen from older documents and talking to some people involved). But the insight wasn’t very deep. Deploying of System Software onto System Software (which is about the most common thing in infrastructure) was left out. Here is ArchiMate 1:

You see the mistake TOG made that System Software is behaviour here. Here is ArchiMate 2.1:

No more behaviour, but still, deploying System Software on System Software isn’t possible. And here is an excerpt of ArchiMate 3.0:

Finally, we could deploy a database on an operating system. But as of ArchiMate NEXT, we still cannot deploy an application on System Software,.. Try to deploy a Java application on a Tomcat platform. No go.

System Software is a horrible name, though. I have long advocated Software Platform. In fact, what we could do:

Old Name	New Name
System Software	Software Platform
Device	Hardware Platform
Application Component	Software Application

And really we can deploy hardware (a crane) on hardware (ship). And we can deploy a Software Application on a Software Platform. By the way, Hardware Applications exists too…

If you really want to shock the world, put Wetware next to Hardware Platform and Software Platform, and have it Realise a Role. Wetware, of course is us humans, but why not include horses, sniffer dogs, etc.? A problem remains the concept of a department that is now covered by Actor, but why not have in your common domain an aggregation of various structure elements (humans, robots, horses, systems) that together make up the concept of Organisation? Organisation as structure can Aggregate all sorts of structure, not just ‘active’ (which is a suspect split anyway). After all, the desks are also a necessary element of that organisation, right? And let’s be fair: isn’t equipment not just a physical (plus software) form of an application? By the way, even going wilder: isn’t Skill for Wetware what is Application for Software and Hardware? So, we add a Skill concept? If you think about it, an application can be seen as analogous to a practical skill. So:

Old	New
System Software	Software Platform (future proof for non-digital IT such as quantum computing and analog computing)
Device	Physical Platform (covers anything on which you can deploy/store something)
Equipment	Physical Application (so moved to application domain, can of course include software)
Application Component	Software Application
	Wetware (technology domain)
Actor	Organisation (Wetware takes over the single-person use)
	Skill (application domain)

What is fun, by the way, is that if you look at the analogy of Software Application, Physical Application, Wetware Application, they are all a form of a packaged ‘skill’. And in a link to Generative AI, we see that all our GenAI Software Applications (such as ChatGPT and Friends) are in fact capable of skills, but not of actual intelligence, so fitting. For intelligence — which may depend more on imagination than we tend to think — still only a single form (Wetware) exists.

I don’t expect any AGI (let alone ASI) soon, I strongly suspect it will require non-digital technology and on that front we simply haven’t gotten the hardware yet and nothing suggests we will have this anytime soon, Not years, unlikely decades, maybe in a few centuries, We’re probably about as far off as the alchemists were from current levels of chemistry. People who think differently are massively underestimating the calculation requirements for even the limited levels of intelligence we humans have (we have cognitively fast and agile people believing the earth is flat, after all), if you ask me.

PS. I just found out WordPress can finally do some decent math. Much better that the last time I tried that, in 2016 in: How much is zero divided by zero?

See the top of this post for links to the previous posts on the ArchiMate NEXT snapshot

[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]