Skip to content

ArchiMate 3.2 vs 4.0 — What Changed and Why

ArchiMate 4.0 was officially released by The Open Group in 2026. It represents the most significant structural change to the language since its creation — consolidating elements, removing redundancy, and shifting from a layer-based to a domain-based organization.

This article covers the motivation, the concrete changes, migration guidance, and implications for the Linked.Archi ontologies.

1. Motivation for Change

Enterprise architecture standards tend to accumulate complexity over time. Advanced users demand specialized features, backward compatibility discourages cleanup, and prospective users are underrepresented in standards discussions. The result is conceptual bloat, steep learning curves, and unnecessary modeling overhead.

ArchiMate 4 addresses this with a clear strategy:

  • Simplicity over comprehensiveness — practical modeling for the "80% use case"
  • Human communication over tool optimization — models should be readable by stakeholders, not just parseable by engines
  • Collaboration with external standards — better alignment with BPMN and UML rather than duplicating their capabilities
  • Delayed implementation decisions — whether a process is manual or automated should not force structural modeling choices

It is worth noting that these goals directly address the reasons many teams adopted C4 over ArchiMate in the first place. C4 succeeded because it is simple to learn, lives in Git, and focuses on communication over formalism — particularly among development teams working primarily in the application domain. ArchiMate 4.0 narrows that gap — fewer elements, specialization-first design, and generic behavior concepts mean a team can start with a handful of types and grow into the full language without hitting a complexity wall on day one. The trade-off remains: C4 gives you speed and developer adoption for application-level modeling; ArchiMate gives you typed relationships, cross-domain traceability, and formal governance across business, strategy, motivation, and infrastructure — domains C4 does not cover at all.

Usage data backing the changes

Analysis of over 600,000 elements and approximately 1,000,000 relationships across 17 organizations in multiple industries shows:

  • Business Actors and Application Components dominate usage
  • Deprecated concepts (Interaction, Representation, Contract, Constraint, Gap) are rarely used in practice
  • Interactions rank near the bottom of element usage across all surveyed organizations

2. The Core Problem: Layer-Specific Behavior Duplication

In ArchiMate 3.x, behavior concepts were duplicated across layers:

Business Application Technology
Business Process Application Process Technology Process
Business Function Application Function Technology Function
Business Event Application Event Technology Event
Business Service Application Service Technology Service
Business Collaboration Application Collaboration Technology Collaboration

These concepts are semantically identical. The only distinction is who performs the behavior — determined by the assignment relationship to an active structure element, not by the behavior element's type.

The problem in practice: partially automated processes

In ArchiMate 3.2, modeling a process that is partly manual and partly automated requires duplication:

Business Actor ──assignment──▶ Business Process
Application Component ──assignment──▶ Application Process
Application Process ──realization──▶ Business Process

Issues: - Duplicate behavior elements for what is conceptually one process - Artificial realization relationships - Implementation decisions (manual vs. automated) forced too early - Harder to understand for non-specialist stakeholders

The ArchiMate 4 solution

Business Actor ──assignment──▶ Process
Application Component ──assignment──▶ Process

One process, multiple performers. Execution semantics are determined by the assigned active structure elements, not by the behavior element's type. This also naturally supports human + AI collaboration:

Human Claims Specialist ──assignment──▶ Claims Assessment Process
AI Claims Assessor ──assignment──▶ Claims Assessment Process

3. Structural Shift: Layers → Domains

ArchiMate 3.2 uses a matrix of Layers × Aspects with an implied hierarchy (Business above Application above Technology — "lower layers serve upper layers").

ArchiMate 4.0 replaces this with peer architecture domains — the "ArchiMate Hexagonion":

  • Common Domain — generic elements shared across all contexts (Service, Process, Function, Event, Role, Collaboration, Interface)
  • Business Domain — business-specific elements (Business Actor, Business Object, Product, Value Stream)
  • Digital Domain — application/technology elements (Application Component, System Software, Node, Device)
  • Physical Domain — physical world elements (Equipment, Facility, Material, Distribution Network)
  • Strategy Domain — strategic elements (Capability, Resource, Course of Action, Value Stream)
  • Motivation Domain — motivation elements (Stakeholder, Driver, Goal, Requirement, Principle)
  • Implementation & Migration Domain — change elements (Work Package, Deliverable, Plateau)

The shift is philosophical: no implied hierarchy, no "lower layers serve upper layers" — domains collaborate as peers.

The term "layer" is replaced by "domain" throughout the specification.

4. Elements Removed

The following elements from ArchiMate 3.2 have been removed in 4.0:

Removed Element Rationale Migration Path
Business Interaction Poorly understood, rarely used, semantically ambiguous Process + multiplicity (multiple assigned actors)
Application Interaction Same as above Process + multiplicity
Technology Interaction Same as above Process + multiplicity
Constraint Rarely used, overlaps with Requirement Specialization of Requirement
Contract Rarely used, overlaps with Business Object Specialization of Business Object
Gap Rarely used, overlaps with Assessment/Deliverable Specialization of Assessment or Deliverable
Representation Rarely used, overlaps with passive structure Specialization of Data Object, Artifact, or Material
Implementation Event Redundant given generic Event Use the now-generic Event element

Why Interaction was removed specifically

Interactions were intended to model collective behavior requiring multiple participants. In practice they were: - Poorly understood by modelers - Rarely used (near-bottom in usage statistics) - Semantically ambiguous (is it a process? a function? a collaboration?)

ArchiMate 4 solves the same problem more elegantly with multiplicity on assignment relationships — a process with a minimum of two assigned actors is inherently collaborative, without needing a separate element type.

5. Elements Merged / Generalized

The most impactful change is the merger of behavior elements across layers into a single set in the Common Domain:

ArchiMate 3.2 (per-layer) ArchiMate 4.0 (generic)
Business Service, Application Service, Technology Service Service
Business Process, Application Process, Technology Process Process
Business Function, Application Function, Technology Function Function
Business Event, Application Event, Technology Event, Implementation Event Event
Business Collaboration, Application Collaboration, Technology Collaboration Collaboration
Business Role Role (generic, assignable to any internal active structure element)

Additionally: - Path moves to the Common Domain - Role becomes generic — any active structure element can be assigned to a role, not just business actors

6. New Capabilities

Feature Description
Relationship multiplicity UML-style cardinalities (1..*, 0..1, 2..5) on relationship ends — supports richer data modeling, infrastructure constraints, cluster modeling, mandatory realizations
Generic Role + Assignment Any active structure element (human, application, device) can be assigned to a role, enabling human + AI collaboration patterns
Specialization-first design Organizations are expected to specialize generic elements (e.g., <<Business>> Process, <<Application>> Process) rather than rely on pre-defined per-layer variants
Hexagonion visualization New visual depiction of the language structure replacing the layer matrix
Better BPMN/UML alignment Generic behavior modeling is closer to how BPMN and UML model processes and activities (see below)

BPMN and UML alignment in practice

ArchiMate 3.2 had an awkward relationship with BPMN. A BPMN Process is a behavioral container — it doesn't declare itself as "business" or "application" level. BPMN handles the human-vs-system distinction at the task level through typed tasks (bpmnl:UserTask, bpmnl:ServiceTask, bpmnl:ManualTask, bpmnl:ScriptTask, etc.) and through participant assignment (Pools and Lanes), not by duplicating the Process concept per layer. But importing a BPMN model into ArchiMate 3.2 forced a layer choice: is this a Business Process or an Application Process? If the process involves both human tasks and automated steps (which most do), you either pick one layer and lose precision, or split it into two elements connected by a realization — adding modeling overhead that doesn't exist in the source BPMN model.

ArchiMate 4.0's generic Process eliminates this friction. A BPMN Process maps directly to an ArchiMate Process. The performers (Business Actor, Application Component) are attached via assignment, mirroring how BPMN attaches Participants to Pools and typed tasks to Lanes. The structural mismatch between the two languages is largely gone — both now express "who performs what" through assignment rather than through element type duplication.

The same applies to UML. A UML Activity or Operation maps to a generic Function or Service without forcing a layer decision. UML's Class maps to a generic passive structure element. The conceptual distance between ArchiMate and UML/BPMN shrinks because ArchiMate no longer insists on layer-specific variants of concepts that other standards treat as universal.

For more on BPMN modeling in Linked.Archi, see the BPMN Deep Dive and the BPMN Lite ontology which provides a simplified profile designed for exactly this kind of cross-model EA reasoning.

7. Technology Domain: Not Over-Simplified

An important point: the simplification does not extend to the technology domain. Reasons:

  • Physical and digital technology coexist in modern enterprises
  • Infrastructure architects need specificity (Node, Device, System Software remain distinct)
  • Industry 4.0 and operational resilience require richer modeling (robots, data centers, power infrastructure, digital twins)
  • NATO adoption required physical technology concepts
  • Cloud platforms need distinct infrastructure modeling

The technology/physical domains retain their specificity — the simplification targets behavior duplication, not infrastructure modeling.

8. Element Count Comparison

Metric ArchiMate 3.2 ArchiMate 4.0
Element types 62 ~55
Relationship types 11 11
Layers/Domains 7 layers 7 domains
Behavior elements 15 (5 per layer × 3 layers) 5 (generic)
Active structure elements 9 (3 per layer × 3 layers) ~6 (generic + domain-specific)

9. Relationship Changes

The 11 relationship types remain the same (Composition, Aggregation, Assignment, Realization, Serving, Access, Influence, Triggering, Flow, Specialization, Association). However:

  • Aggregation from Path to Technology Internal Active Structure → replaced by Realization from Active Structure Element to Path
  • Realization between services of different layers → replaced by Specialization (from realizing service to realized service) or Aggregation (from realized service to realizing service)
  • Relationships that are no longer permitted between specific element pairs should be replaced by Association
  • Multiplicity is now expressible on any relationship

10. Migration from 3.2 to 4.0

Two migration approaches are available:

Option 1: Simple Conversion

Convert all layer-specific behavior elements into their generic equivalents directly:

Business Actor ──assignment──▶ Process (was: Business Process)
Application Component ──assignment──▶ Process (was: Application Process)
Process (application) ──specialization──▶ Process (business)

Option 2: Conversion with Profiles (Specialization)

Use specialization to preserve origin semantics while adopting the new structure:

Business Actor ──assignment──▶ <<Business>> Process
Application Component ──assignment──▶ <<Application>> Process
<<Application>> Process ──specialization──▶ <<Business>> Process

This retains backward traceability — you can still distinguish "business-level" from "application-level" processes through specialization stereotypes, without requiring separate element types.

Element-level migration rules

  1. Constraint → specialization of Requirement
  2. Contract → specialization of Business Object
  3. Gap → specialization of Assessment or Deliverable
  4. Representation → specialization of Data Object, Artifact, or Material
  5. Interactions → Process or Function with multiplicity ≥ 2 on assignment
  6. Layer-specific behavior elements → their generic counterpart
  7. Implementation Event → Event
  8. Invalid relationships → Association (or restructure per the new validity matrix)

11. Implications for Linked.Archi Ontologies

Linked.Archi maintains both versions:

Version Location Status
ArchiMate 3.2 modelingLanguages/archimate/3.2/ Current (widely adopted)
ArchiMate 4.0 modelingLanguages/archimate/4.0/ Draft (tracking the new spec)

Ontology differences

The 4.0 ontology (archimate4-onto.ttl) reflects the structural changes:

  • Fewer concrete element classes (~55 vs 62)
  • Generic behavior elements in a Common Domain taxonomy node
  • Removed elements are absent (no Constraint, Contract, Gap, Representation, Interaction classes)
  • Role is generic (not Business-specific)
  • Relationship validity matrix updated (fewer valid combinations due to element removal, new combinations for generic elements)

Cross-version mapping

The archimate4-tax.ttl taxonomy uses domain-based grouping instead of layer-based. SKOS skos:broadMatch / skos:closeMatch annotations can link 3.2 elements to their 4.0 equivalents for organizations migrating models.

SHACL shapes

The 4.0 relationship shapes (archimate4-relationship-shapes.ttl) are regenerated from the updated relationship validity matrix (.reference/archimate4/archimate-relationships-matrix-4.0.xml). Fewer element types means a smaller matrix but with broader applicability per cell.

12. Which Version to Use

Scenario Recommended
Existing models in ArchiMate 3.x tools (Archi, Sparx, BiZZdesign) 3.2
New greenfield architecture practice 4.0
Extending ArchiMate with custom elements 4.0 (simpler base, specialization-first design)
Academic or standards-compliance work 4.0 (current normative version)
Organizations not ready to migrate tooling 3.2 (with migration plan)
Human + AI collaboration modeling 4.0 (native support via generic Role + Assignment)
Cross-domain process modeling 4.0 (no forced layer choice)

Both versions share the same Linked.Archi core foundation (arch:Element, arch:QualifiedRelationship, SHACL, SKOS) — switching between them is a matter of which ontology you import, not a fundamental architecture change.

13. See Also

14. References