Evolving: ArchiMate 4

Intention

ArchiMate 4 is not just an update—it’s a paradigm shift. It redefines enterprise architecture as:

• Goal-driven, not layer-bound.
• Human-centric, not tool-centric.
• Simple, yet powerful enough for complex, evolving enterprises.

Still Unreleased

No reference implementation yet (i.e. Archi); some third party tool vendors (e.g. Visual Paradigm) are moving forward regardless. Final specification is expected 2H 2026 with additional vendor support expected starting 4Q 2026.

Backwards-Compatible

• Existing models remain editable.
• No forced migration required.

De-emphasizing Layers — Moving to Domains

• “Layer” is replaced by “Domain” – Reflects a more flexible, non-hierarchical view of architecture.
• Motivation Domain is now central—emphasizing that architecture is driven by goals, outcomes, and stakeholder needs.
• Seven Core Domains define the new landscape:

1. 1. Motivation Domain (Center) – Stakeholders, goals, drivers, and requirements.
   2. Strategy Domain – Strategic direction derived from motivation.
   3. Common Domain – Generic elements usable across all domains (e.g., Service, Process, Event).
   4. Business Domain – Organizational structure, customer interactions, value delivery.
   5. Application Domain – Applications, data, and service interactions.
   6. Technology Domain – Infrastructure, hardware, software platforms.
   7. Implementation and Migration Domain – Evolution, rollout, and transition planning.

Common Domain: De-emphasizing Business, Application, Technology Layer Distinctions

• Active Structure Elements: Path, Role, Collaboration
• Behaviour Elements: Function, Service, Process, Event
• Composite Elements: Grouping, Location

Move to more of a semantic or context-based approach to these elements, putting the focus on the relationships rather than inherent context within the element itself.

Example: A Service can be invoked by a Business Actor, an Application Component, a Technology element, etc. etc. rather than just being, previously, a Business Service or Application Service

Relationship Multiplicity

A familiar concept in UML and ERD modelling, permitting relationships to define multiplicity / cardinality

Simplification / Deprecations

In addition to the moving of key elements to the Common Domain, some syntax / elemtns have been removed completely. The major one is the Composition relationship, which will instead require use of Aggregation (part-of) or Grouping (collections).

This is impactful typically in Capability Modelling, where previously tools defaulted to Collaboration relationships between L1/L2, L2/L3, and L3/L4 Capabilities.

As well, less commonly used elements are also being removed, including: