The ArchiMate Next Specification Snapshot 1 (The Open Group publication S250) represents the most significant shift in the modeling language since the release of version 3.0. Published in mid-2025, it serves as a “working draft” for what is expected to be ArchiMate 4.0.
The central philosophy of this update is “radical simplification.” The Open Group has acknowledged that ArchiMate had become overly complex, leading to “diagram clutter” and a steep learning curve for non-architects.
1. The Core Transformation: “Common Domain” & The Hexagonion
The most striking change is the move away from the rigid Business-Application-Technology (BAT) matrix. While these layers still exist as organizational concepts, the metamodel has been unified into a Common Domain.
-
Unified Active Structure: Layers-specific collaborations (Business, Application, Technology) are being merged into a single Collaboration element.
-
The Role Element: The “Business Role” is being generalized into a generic Role element that can be assigned to any internal active structure element (human or system).
-
The Hexagonion: Community discussions refer to a new underlying framework—the “Hexagonion”—which replaces the traditional matrix to emphasize how elements relate across any domain rather than just top-down layers.
2. Major Removals (Reducing Redundancy)
To streamline the language, several elements and relationships that were deemed redundant or confusing have been removed or consolidated:
Removed Relationships
-
Composition: This is one of the most controversial changes. In many cases, Aggregation or nesting is now used to show “part-of” relationships. The goal is to reduce the cognitive load of choosing between two very similar structural relationships.
Removed Elements
-
Interactions: Business Interaction, Application Interaction, and Technology Interaction are gone. These are now modeled using unified behavior elements.
-
Constraints & Contracts: These specialized motivation/business elements are removed; their intent is meant to be captured via Requirements or Property attributes.
-
Gaps & Representations: Often underused in actual practice, these have been excised to keep the core language lean.
3. Tech Layer Evolution: Physical & Virtual
The Technology Layer has been renamed and refined to better reflect modern computing (Cloud, Edge, and even Quantum):
-
System Software → Software Platform: A more future-proof term that encompasses operating systems, containers, and cloud environments.
-
Device → Physical Platform: Broadened to cover any physical hardware capable of hosting or executing software.
-
Equipment → Physical Application: In a clever twist, equipment is moving closer to the “Application” domain logic, acknowledging that modern machinery is often just “hardware-wrapped software.”
4. New Features & Usability
Despite the “subtraction” theme, several high-value features have been added:
-
Relationship Cardinalities: You can now explicitly model $1..n$ or $0..1$ constraints on relationships, bringing ArchiMate closer to the precision of UML for data-heavy architects.
-
Internal vs. External Behavior: Definitions for Services (external) vs. Processes/Functions (internal) have been sharpened to resolve the long-standing “Service Mess” in previous versions.
-
Path Associations: Paths can now be explicitly associated with the internal active structure elements they connect, clearing up ambiguity in network modeling.
Comparison: ArchiMate 3.2 vs. ArchiMate Next (Snapshot 1)
| Feature | ArchiMate 3.2 (Current) | ArchiMate Next (Snapshot) |
| Structure | Strict BAT Matrix (Layers) | Unified “Common Domain” |
| Primary Link | Composition & Aggregation | Aggregation (Composition removed) |
| Interactions | Layer-specific (e.g., App Interaction) | Unified Behavior elements |
| Technology | Device, System Software | Physical Platform, Software Platform |
| Constraints | Dedicated “Constraint” element | Modeled via Requirements/Properties |
| Precision | Implicit quantities | Explicit Cardinalities ($1..*$) |
5. Summary Verdict & Migration
Experts like Gerben Wierda note that while this simplification makes the language more approachable for “high-level” sketching, it may require “creative modeling” for those who relied on the niche precision of the removed elements.
What this means for you:
-
Don’t switch yet: This is a snapshot for feedback, not a normative standard.
-
Audit your models: Identify how much you rely on the Composition relationship. If you use it heavily, your future migration to 4.0 will require a bulk conversion to Aggregation.
-
Tooling: Watch for update of the Visual Paradigm Desktop, but keep your production models in 3.2 for now.