What Really Changes in the ArchiMate® 4 Specification and What Does Not

The last major release of the ArchiMate modeling language was Version 3 in 2016. Versions 3.1 (2019) and 3.2 (2022) followed, bringing relatively limited improvements. Version 4 goes much further.

Here, I will explain the most important changes, the thinking behind them, and what remains familiar. The ArchiMate 4 Specification introduces significant changes without requiring practitioners to discard what they already know. It reduces unnecessary complexity while preserving the language’s core purpose and expressive power. Each change has a practical purpose, bringing greater clarity and flexibility to the way the ArchiMate modeling language is learned, applied, and used to communicate architecture.

“The ArchiMate® 4 Specification introduces significant changes without requiring practitioners to discard what they already know.” — Marc Lankhorst, Managing Consultant & Chief Technology Evangelist at Bizzdesign

What are the main changes from Version 3.2 to Version 4 of the ArchiMate Specification?

Overall, Version 4 reduces the number of concepts in the language by 30%, from 60 to 42. It achieves this by generalizing some concepts and deprecating others. These changes make the language easier for beginners to learn and give practitioners greater modeling freedom and flexibility to represent relationships across domains.

The Common Domain 

The most consequential example of how Version 4 achieves this simplification is the merging and generalization of behavior concepts that were previously divided across the Business, Application, and Technology layers. The specification brings them together in a single set in what we call the Common Domain. For example, instead of separate Business Process, Application Process, and Technology Process concepts, it uses a single Process concept. This has several advantages:  

• You can postpone the decision about whether a behavior is automated or manual until later in your architecture and design, when you assign specific resources to perform the behavior. In older versions of ArchiMate, you either had to decide this immediately or create convoluted models in which, for example, an automated business process was realized by some application process, basically duplicating parts of your model.
• It is now much easier to model processes in which people and machines work together, collaboratively performing some behavior. Think of factory workers and robots, or enterprise architects and AI assistants. The generic Collaboration and Role concepts are also helpful here.
• Mapping these concepts to more detailed design languages such as the Business Process Model and Notation (BPMN) or the Unified Modeling Language (UML) is simpler because those languages do not make the same upfront distinction among types of behavior.

“It is now much easier to model processes in which people and machines work together, collaboratively performing some behavior.” — Marc Lankhorst, Managing Consultant & Chief Technology Evangelist at Bizzdesign

Deprecated concepts 

Version 4 also deprecates a number of concepts that are seldom used or are just specialized versions of other concepts. Specifically, these include:

• Business Interaction, Application Interaction, and Technology Interaction: These are processes that have to be performed by more than one participant, something the ArchiMate modeling language can already express using other concepts.
• Representation: This concept was originally introduced to model paper representations of Business Objects. Such representations can now be modeled using Material for paper, or Data Object and Artifact for digital representations.
• Contract: A Contract is a kind of Business Object.
• Constraint: A Constraint is a special case of a Requirement that specifies what cannot be done.
• Gap: A Gap is essentially an Assessment of the difference between two architecture states, represented by Plateaus.  

For practitioners, this means fewer overlapping or rarely useful choices while preserving the information and relationships needed to understand the architecture.

Of course, for each deprecated concept, one or more conversion options exist, as Jean-Baptiste Sarrodie and I explain in our white paper published by The Open Group, The Motivation for Changes in the ArchiMate® 4 Specification. Bizzdesign plans to support these conversion paths as part of its implementation of the ArchiMate 4 Specification.   

Relationship multiplicity 

The new specification also introduces relationship multiplicity. This allows architects to specify lower and upper bounds for the number of instances at each end of a relationship. It is especially valuable for data architects but can support other modeling needs too. For example, a model can specify that every service must be realized by at least one process.  

This small but important improvement allows architects to express important structural constraints more precisely when those details matter, without turning the ArchiMate modeling language into a detailed design language.

Why the ArchiMate 4 Specification replaces layers with domains

The specification reflects these structural changes through a new depiction of the ArchiMate Framework, replacing the “layer cake” with a concentric, layered hexagonal diagram we call the “hexagonion”. The name combines “hexagon” and “onion.” More importantly, the term “layer” is also replaced by “domain” when referring to the different parts of the language.

The old, layered structure was sometimes interpreted as a set of conceptual, logical, and physical abstraction layers. It could also suggest a strict hierarchy in which “the business” was served by “the applications,” which in turn were served by “the infrastructure”. However, those are misinterpretations of the structure of the language.

For practitioners, the move to domains makes the intended structure clearer and helps them represent relationships across business and technology without imposing artificial hierarchies.

What remains unchanged in the ArchiMate 4 Specification?

Although the framework looks different, its underlying structure remains.

The new representation no longer shows the aspects of the language, but they remain part of it. The core idea of using the structure of human language with subjects (active structure), verbs (behavior), and objects (passive structure) is still very much alive. It is simply not shown in the new framework depiction.

Nor have the key principles behind the language changed. They also deeply informed the development of Version 4. Years ago, we captured them in what we call the “ArchiMate Manifesto,” inspired by the Agile Manifesto:

• Simplicity over Comprehensiveness: The most important design consideration is that the language has been explicitly designed to be as small as possible, but still usable for most Enterprise Architecture modeling tasks.
• Needs of the Many over Wants of the Few: Any change to the language shall cover a clearly identified and important use case of a substantial part of its users. Keeping things simple for the proverbial “80%” is more important than catering for the wants of the “20%”.
• Collaboration over Coverage: If a need is already covered sufficiently by another modeling language, it is preferred to define a mapping to that language. For example, a detailed software design model is better written in UML, and the ArchiMate application component concept can be used to map between both models.
• People over Tools: The language was designed for communication among human users rather than for technical usage. There are many more technical languages already.
• Communicating Architecture over Other Use Cases: The ArchiMate language was designed first and foremost to support (Enterprise) Architects in communicating architectures. Accommodating use cases of other users should not get in the way of this key user group.

In summary, the ArchiMate 4 Specification stays true to its core tenets while doing the necessary housekeeping to streamline the standard. It makes the language easier to understand and use without sacrificing the structure needed for serious architecture modeling.

This evolution reinforces a broader principle for architecture practice. Making models easier to understand and apply helps you establish a shared view of the enterprise. Such a shared view supports more informed conversations with your stakeholders and better and faster decisions about change. At a time when AI is accelerating transformation and dependencies increasingly cut across business and technology, such clarity and speed is essential.

ArchiMate and The Open Group are registered trademarks of The Open Group.