Why the ArchiMate® 4 Specification Puts Simplicity First

That accumulated complexity was one of the challenges we wanted to address in the ArchiMate 4 Specification. Our aim was to keep the language focused on the enterprise architecture modeling tasks that matter most, while preserving the clarity and precision that make a standard useful.

In my first article in this series, I explained what changed in the ArchiMate 4 Specification and what remains familiar to practitioners. The second article looked back at how the ArchiMate modeling language became a global standard and what comes next. This third article turns to the design philosophy behind the changes and to a practical question they raise. Why put simplicity first in a mature modeling standard?  

Our approach is captured in five principles from the “ArchiMate Manifesto”. Jean-Baptiste Sarrodie and I explain how these principles informed the new version in The Motivation for Changes in the ArchiMate® 4 Specification, a white paper published by The Open Group.  

1. Simplicity over Comprehensiveness
2. Needs of the Many over Wants of the Few
3. Collaboration over Coverage
4. People over Tools
5. Communicating Architecture over Other Use Cases

These principles were chosen very deliberately, in order to avoid several common problems with the creation and evolution of standards. They also provide a way to decide which capabilities belong in the core language as the standard matures.

Common modeling needs and the 80/20 principle in the ArchiMate 4 Specification

First of all, standards tend to be developed by seasoned experts in the field, who typically have more advanced use cases than those of less experienced users. This can lead to the addition of features that cater to a small, advanced group, but are irrelevant or incomprehensible to regular and novice users. From the start, we have therefore aimed to create a language that is as small as possible, focused on the mainstream of enterprise architecture modeling tasks rather than supporting each and every possible edge case. This is the reasoning behind the first principle, Simplicity over Comprehensiveness.

This tendency can become more problematic over time, as specialist features accumulate into a form of conceptual debt and make the standard increasingly difficult to use for simple, ordinary use cases. Those common cases typically make up the proverbial 80%, while using only 20% of the standard’s features. The remaining 80% of the standard’s ‘high-end’ features are often a burden for the 80% of users who don’t need them. And once a feature is part of a standard, the experts who rely on it may understandably resist its removal. Because those experts are often more active in standardization than the wider community of users, their needs can become more visible in the process. This can lead the language to drift towards greater complexity. This was the main reason for the second principle, Needs of the Many over Wants of the Few.

Together, the first two principles determine what belongs in the core language. The remaining three show what that simplicity enables.

How the ArchiMate modeling language complements BPMN and UML

Aligned with the first two principles, we did not want the ArchiMate modeling language to become an all-purpose language for every kind of modeling, from high-level strategic considerations to detailed technical design. In many domains, there are established languages and techniques already, and the ArchiMate standard explicitly aims to integrate with them, rather than subsuming those domains in a massive, overcomplicated language that tries to cover everything.  

Two of the most important standards in this respect are the Business Process Model and Notation (BPMN) for business process modeling and the Unified Modeling Language (UML) for software design. The ArchiMate language intentionally includes a few concepts that are shared with those languages. For example, its Application Component concept is equivalent to UML’s Component. Those concepts serve as a bridge between models, so you can create a consistent and coherent chain of design artifacts across multiple collaborating standards. This is the background of the third principle, Collaboration over Coverage.

I discussed these relationships in more detail in Combining ArchiMate with Industry Standards for Better Enterprise Architecture.

Designing ArchiMate models for people and communication

Given the relatively high level of abstraction of the enterprise architecture discipline, the ArchiMate standard is not intended for the creation of executable artifacts or for generating code. BPMN models with sufficient detail can be used to configure a workflow engine, and UML models can be input for code generation tools, but ArchiMate models are intended for human consumption first and foremost. Of course, the language does have a standardized file format, but it intentionally avoids features such as formalized execution semantics. This is the basis for the fourth principle, People over Tools.

So, ArchiMate models are intended for human consumption. The focus on human consumption helps architects and their stakeholders understand and communicate about architectures. We intentionally avoid adding features that support technical use cases but make ArchiMate models more difficult to create or read. For instance, overly formal semantics often constrain how you can use a language and which models are considered ‘correct’.  

This brings us to the main reason the ArchiMate standard was developed in the first place. Enterprise architecture is an abstract subject that is often difficult to understand and convey, and having a shared language in which to express architectures fosters this understanding. Hence the fifth principle, Communicating Architecture over Other Use Cases.

In practice, this becomes more important as architecture work reaches beyond a small group of specialists. In our work at Bizzdesign, we see this most clearly when organizations use the ArchiMate modeling language across teams with different levels of experience. A model that architects, business stakeholders, and technology teams can interpret consistently is more useful than one whose sophistication is clear only to experts.

Simplicity without loss of rigor in the ArchiMate 4 Specification

Useful rigor comes from clear concepts, meaningful relationships, and consistent application. Additional concepts and formal constraints strengthen a language only when they help architects model and communicate more precisely.

The ArchiMate 4 Specification retains that rigor. The overall simplification of the language removes distinctions whose cost outweighed their value for most users and generalizes concepts where a single idea can be applied consistently across domains. The language continues to support analysis, communication, and governance, while becoming easier to learn and use.

Following these principles, the ArchiMate 4 Specification removed and generalized certain concepts, reducing their number from 60 to 42, all to make the language easier to understand and use for most users.  

Some advanced users may lose a favorite specialized concept, but we consider that a reasonable trade-off for improvements that benefit the great majority of architects. Moreover, an automated conversion can preserve relevant information if needed, so existing models do not simply disappear.

At scale, a smaller core vocabulary can reduce training effort, ease model governance, and help teams use concepts more consistently. Applied well, those models provide stakeholders with trusted enterprise context that helps them understand dependencies and make better decisions.

Standards rarely become simpler by accident. As the ArchiMate community grows, keeping the language usable will require continued discipline about what belongs in its core and what is better handled elsewhere. The ArchiMate 4 Specification is an important step in that direction.  

With these simplifications, I am confident that the new, streamlined ArchiMate 4 Specification will see even greater adoption in the field.

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