ArchiMate 4, ArchiMate 3.2, Enterprise Architecture, TOGAF, The Open Group, modeling languages, metamodeling, UML, MOF, model driven engineering, architecture governance, semantic governance, architecture repository, Common Domain, architecture domains, viewpoints, specialization, profiles, complexity, socio-technical systems, operational evidence, digital transformation
ArchiMate 4 is not a radical reinvention of the ArchiMate language. It is a deliberate simplification and normalization of a mature enterprise architecture notation. Compared with ArchiMate 3.2, it replaces layers with domains, introduces the Common Domain as a central modeling structure, merges behavior elements across domains, generalizes role and collaboration, moves path into the Common Domain, removes several specialized elements, and introduces multiplicity on relationships. This article reads those changes from two perspectives. The first is practical: what changed, why it changed, and how enterprise architects should migrate models and repositories without losing semantic precision. The second is more critical: ArchiMate 4 appears precisely when enterprise systems are becoming more complex, distributed, cyber-physical, data-intensive, and partially autonomous. The language becomes simpler while the systems to be governed become harder to describe. The article argues that this is not a defect of ArchiMate alone, but a structural limit of human-readable modeling languages. The history of UML, MOF, and model-driven engineering shows that modeling languages tend either to expand until they become too heavy for ordinary use, or to simplify until much of the real meaning moves into profiles, stereotypes, tools, conventions, and governance practices. ArchiMate 4 chooses the second path. Its success will therefore depend less on the elegance of the core metamodel than on the discipline with which organizations govern specializations, viewpoints, repositories, and links to operational evidence. ArchiMate should not be treated as the complete model of the enterprise. It should be treated as the intentional semantic map of the enterprise: a human-scale abstraction layer connected to more detailed and volatile sources of truth such as cloud inventories, IAM graphs, CMDBs, API catalogs, data lineage, SBOMs, security tools, telemetry, and delivery pipelines. The future of enterprise architecture is not a larger diagramming language, but a governed semantic layer between organizational intent and computational reality.
Enterprise Architecture exists because organizations cannot be governed reliably through isolated documents, meetings, organograms, application inventories, project plans, and technology roadmaps. At enterprise scale, decisions about capabilities, processes, information, applications, infrastructure, security, operating models, physical assets, suppliers, and transformation programs are interdependent. A local change rarely remains local. It may propagate through services, data flows, responsibilities, interfaces, controls, investment plans, and operational constraints.
ArchiMate was created to make those dependencies explicit. It is a visual modeling language for describing, analyzing, and communicating Enterprise Architectures as they change over time. The ArchiMate 4 Specification defines a set of concepts and default iconography for representing Architecture Descriptions, and the wider ArchiMate ecosystem also includes an XML exchange format intended to support model and diagram exchange between tools.1
%%{init: {"theme": "neo", "look": "base", "layout": "elk"}}%%
flowchart LR
subgraph FULL["ArchiMate 4 Full Language"]
M["Motivation Domain<br/>stakeholders, drivers, assessments,<br/>goals, outcomes, principles,<br/>requirements, meaning, value"]
S["Strategy Domain<br/>resources, capabilities,<br/>value streams, courses of action"]
subgraph CORE["Core Language"]
C["Common Domain<br/>generic elements usable across domains"]
B["Business Domain"]
A["Application Domain"]
T["Technology Domain<br/>information technology and<br/>operational / physical technology"]
end
I["Implementation & Migration Domain<br/>work packages, deliverables, plateaus"]
D["No separate Data Domain<br/>information is modeled through passive structure:<br/>business objects, data objects, artifacts"]
end
M -. "explanatory: architecture motivation" .-> S
S -. "explanatory: strategic direction" .-> CORE
I -. "explanatory: evolution and implementation" .-> CORE
C -. "explanatory: common elements used with" .-> B
C -. "explanatory: common elements used with" .-> A
C -. "explanatory: common elements used with" .-> T
D -. "explanatory: passive structure across domains" .-> B
D -. "explanatory: passive structure across domains" .-> A
D -. "explanatory: passive structure across domains" .-> T
ArchiMate should not be confused with TOGAF. TOGAF is primarily an Enterprise Architecture framework. It provides a method, governance structure, content guidance, and a way to organize architecture work. ArchiMate is primarily a modeling language. TOGAF helps structure the architecture practice; ArchiMate helps express the architecture. The two standards are complementary rather than equivalent. The ArchiMate 4 Specification itself follows the TOGAF sense of enterprise as an organizational scope that may span multiple organizations, ecosystems, or federations, not only a single legal entity.
Both ArchiMate and TOGAF belong to the standards landscape of The Open Group, the consortium whose stated mission is to support Boundaryless Information Flow through interoperability, consensus based standards, certification, and collaboration among customers, suppliers, tool vendors, integrators, academics, and consultants.2 This institutional context matters. ArchiMate is not just a drawing convention. It is meant to support repeatable communication among architects, stakeholders, tool vendors, training organizations, and architecture repositories.
ArchiMate 3.2 was the previous official version of the standard. The Open Group white paper on the ArchiMate 4 changes identifies ArchiMate 3.2 as document C226, published in October 2022, and ArchiMate 4 as document C260, published in April 2026.3 ArchiMate 4 must therefore be read as a revision of a mature language, not as the invention of a new notation.
The important point is that ArchiMate 44 is not merely a syntactic update. It is a deliberate act of semantic cleanup. The Open Group white paper states that the new version aims to stay true to the goals of the ArchiMate Specification while carrying out the necessary housekeeping to clean up and streamline the standard, improve ease of adoption and use, and avoid prioritizing the complex needs of advanced users at the expense of regular and prospective users. This framing is essential: the new version is not trying to model everything. It is trying to reduce conceptual debt.
The central thesis of this article is that ArchiMate 4 is mainly a simplification and normalization release. It reduces redundant domain-specific concepts, introduces the Common Domain as the place for generic elements, replaces several specialized elements with specializations of more fundamental concepts, changes the visual structure of the language from a layered matrix to a domain oriented hexagonal representation, and introduces multiplicity on relationships. The result is a smaller and cleaner metamodel. The cost is that more responsibility moves from the standard itself to modeling discipline, specialization governance, repository rules, and migration practice.
The first principle is that every modeling language has a cost. A new concept is never free. It creates a classification decision for the modeler, a validation burden for the tool, a training burden for the organization, and an interpretation burden for the reader. If the language contains too many near duplicate concepts, it may appear more expressive, but in practice it becomes harder to learn, harder to govern, and harder to use consistently.
The Open Group white paper on the motivation for ArchiMate 4 makes this point explicitly. Evolving standards tend to be shaped by advanced users, because they are the people most likely to participate in standardization work. Advanced users often ask for advanced features for advanced use cases. The problem is that this can make the standard heavier for regular users, and even more so for prospective users, whose concerns are often not represented at all in standards forums.5
This is the structural reason behind the simplification. The issue is not that the previous language was unusable. The issue is that a standard accumulates conceptual debt over time. Backward compatibility protects existing users and tools, but it can also preserve old distinctions, historical compromises, and concepts whose value is no longer proportional to the cognitive load they impose. The white paper uses exactly this logic: without housekeeping, legacy and conceptual debt would be carried forward indefinitely, increasing the baggage of the language.
ArchiMate 4 should therefore be read as an attempt to reduce this conceptual debt. The objective is not theoretical minimalism for its own sake. The objective is adoption. The standard must remain usable by the majority of enterprise architecture practitioners, not only by specialists who already know the metamodel in depth. This is why the ArchiMate Manifesto gives priority to simplicity over comprehensiveness, needs of the many over wants of the few, collaboration over coverage, people over tools, and communication of architecture over other use cases.6
These principles are important because they explain the direction of the change. ArchiMate 4 does not try to compete with BPMN for detailed process execution semantics, with UML for detailed software design, with data modeling notations for logical and physical schemas, or with cloud provider specific diagrams for infrastructure details. Its role is different. It is a language for communicating Enterprise Architecture across domains and concerns. When another language is better suited to a specialized modeling problem, the intended strategy is mapping and coexistence, not absorption.
In ArchiMate 3.2, the language contained several domain-specific variants of concepts that were semantically very close. There were business, application, and technology behavior elements. There were business, application, and technology collaborations. There was a business role, but no equally generic role concept across the whole core. There were elements such as constraint, contract, representation, and gap, which were useful in some contexts but could also be interpreted as special cases of more fundamental concepts. This gave modelers expressive detail, but it also created redundancy.
ArchiMate 4 attacks that redundancy directly. The official change logic is that behavior concepts are merged into a single generic set: service, process, function, and event. The performer of the behavior is no longer encoded primarily in the type of behavior element. It is expressed through assignment relationships to active structure elements. This means that the same process can be performed by a business actor, an application component, equipment, a node, or a collaboration across domains.7
This is especially relevant for modern enterprise systems. Many real processes are no longer purely human, purely application based, or purely technology based. A claims handling process may involve employees, applications, AI components, documents, rules, and automated decisions. A manufacturing process may involve operators, robots, sensors, MES functions, ERP transactions, and physical materials. A cybersecurity process may involve analysts, SIEM platforms, SOAR automation, identity systems, and infrastructure controls. ArchiMate 3.2 could model these cases, but often with duplication or artificial separation. ArchiMate 4 makes the mixed nature of these systems easier to express.
The same reasoning explains the generalization of role and collaboration. A role is no longer only a business role. It can express the purpose or responsibility of a business actor, application component, node, device, system software, equipment, facility, or collaboration. This reflects an architectural reality: in modern systems, responsibility and function are distributed across human and non human structures. The white paper explicitly notes that assignment of non human actors to roles becomes increasingly relevant in the age of AI, while also clarifying that responsibility and legal accountability remain different notions.8
However, ArchiMate 4 is not a blind reduction of the language. The white paper also asks why the language was not simplified further. The answer is that simplification has a limit. The Technology Domain still needs to distinguish IT and physical technology, software and hardware, processing and networking, and physical technology concepts such as facility, equipment, material, and distribution network. These concepts may be less common in traditional IT centric enterprise architecture, but they matter for operational resilience, Industry 4.0, digital twins, physical infrastructure, energy, manufacturing, defense, and cyber-physical systems.9
The design choice is therefore balanced. ArchiMate 4 removes or generalizes concepts where the distinction was mostly redundant, unclear, rarely used, or better represented through specialization. It preserves concepts where collapsing them would make the language too abstract for important use cases. The result is not the smallest possible language. It is a smaller language that tries to remain useful for the broad enterprise architecture problem.
This is the key to understanding the new version. ArchiMate 4 does not remove the ability to model business processes, application services, technology events, contracts, gaps, representations, or domain-specific behaviors. It removes several of them as primitive language elements and expects the same meaning to be expressed through generic concepts, explicit relationships, specialization profiles, attributes, and governed modeling conventions.
The benefit is a cleaner metamodel and a lower barrier to entry. The cost is that organizations can no longer rely only on element names to carry semantic precision. More meaning must now be carried by modeling discipline. In practice, ArchiMate 4 makes the standard simpler, but it makes local architecture governance more important.
One of the most important changes in ArchiMate 4 is also one of the easiest to underestimate: the language moves from the old idea of layers to the more neutral idea of domains. At first sight this may look like a terminology change. It is not. It changes the mental model through which the language asks architects to look at the enterprise.
%%{init: {"theme": "neo", "look": "forest"}}%%
flowchart TB
subgraph A32["ArchiMate 3.2: layer-oriented reading"]
direction TB
B32["Business Layer"]
A32L["Application Layer"]
T32["Technology Layer"]
B32 -. "often read as above" .- A32L
A32L -. "often read as above" .- T32
end
subgraph A4["ArchiMate 4: domain-oriented language structure"]
direction TB
subgraph CORE["Core Language"]
direction TB
CD["Common Domain<br/>generic elements"]
DOMS["Business Domain<br/>Application Domain<br/>Technology Domain"]
CD -. "explanatory: used with" .- DOMS
end
subgraph FULLONLY["Other domains in the Full Language"]
direction LR
MOT["Motivation"]
STR["Strategy"]
IM["Implementation & Migration"]
end
FULLONLY -. "explanatory: same full language" .- CORE
end
A32 -. "terminology and visualization shift<br/>not a formal ArchiMate relationship" .-> A4
The official white paper is explicit on this point. The new hexagonal visualization intentionally moves away from the layered matrix of previous versions. The reason is not cosmetic. The notion of layers suggested a hierarchy, as if lower layers existed mainly to serve or realize upper layers. The white paper notes that ArchiMate 3.0 had already relaxed the strict condition that serving relationships should only point upward between layers, but the old image and the term layer continued to suggest that hierarchy. ArchiMate 4 replaces that visual grammar with the ArchiMate Hexagonion and replaces layer with domain to emphasize that no hierarchy is implied by the structure of the language.10
This is central because diagrams do not only represent concepts. They discipline thinking. A layered drawing silently teaches its reader to see architecture as vertical decomposition: business above application, application above technology, technology below everything else. That view can be useful as a stakeholder simplification, but it is dangerous when it becomes the implicit ontology of the enterprise. Enterprises are not layer cakes. They are graphs of responsibilities, behaviors, information, services, assets, constraints, and transformations.
The problem is not that the old layered representation was formally wrong in every use. The problem is that it encouraged an interpretation that was too strong. Many readers naturally interpreted the Business Layer as a conceptual abstraction of the Application Layer, and the Application Layer as a conceptual abstraction of the Technology Layer. The motivation paper rejects this interpretation directly. It states that the ArchiMate layers were not abstraction layers. The Business Layer was intended to model the human perspective on enterprise architecture: what people and organizations do, not an abstract version of what software and technology implement. A business actor is not realized by an application component. A department, a customer, or a supplier is not an abstraction of a software system.11
This distinction matters in practice. If the Business Layer is mistaken for the conceptual level, then every automated behavior tends to be forced into an artificial pattern: first describe it as business behavior, then describe a parallel application behavior, then connect the two through realization. This may look architecturally tidy, but often it is just duplication. The motivation paper gives exactly this argument for partially automated processes: in ArchiMate 3.2, to model that a business process was partially automated, one often had to create an application process realizing the business process, and then model an assignment from the application component to that application process to show that the component performs the automated part of the behavior. The paper describes this as overhead that duplicates part of the model without adding insight.12
The deeper issue is that implementation choice is not always known at the beginning of architectural reasoning. When an architect first identifies a process, it may not yet be clear whether that process will be performed manually, supported by an application, executed by a robot, delegated to an AI service, or distributed across several human and technical participants. Under the old layered intuition, the modeler was pushed to classify the behavior too early as business, application, or technology behavior. Under the ArchiMate 4 logic, the modeler can first represent the process as a generic behavioral element, without prematurely deciding who or what will perform it. The execution model is then added explicitly through assignment relationships to active structure elements: business actors, application components, nodes, devices, equipment, facilities, roles, or collaborations.
This is a more faithful abstraction. From first principles, behavior and performer are different dimensions. A process is a temporal or causal organization of behavior. A performer is the active structure that carries out that behavior. These two dimensions should not be collapsed prematurely into a single layer-specific element. ArchiMate 4 separates them more cleanly. The model can say that a process exists, and only then say who or what performs it.
%%{init: {"theme": "neo", "look": "forest"}}%%
flowchart TB
subgraph AS["Active Structure"]
IAS["Internal Active Structure Elements<br/>business actor, application component,<br/>node, device, system software,<br/>equipment, facility"]
R["Role"]
C["Collaboration"]
IF["External Active Structure Elements<br/>business / application / technology interface"]
end
subgraph BEH["Behavior"]
IB["Internal Behavior Elements<br/>process, function"]
EV["Event"]
SV["Service<br/>external behavior"]
end
subgraph PS["Passive Structure"]
P["Passive Structure Elements<br/>business object, data object,<br/>artifact, material"]
end
IAS -- assigned to / fulfills --> R
IAS -- assigned to / performs --> IB
R -- assigned to / responsible for --> IB
C -- assigned to / performs collectively --> IB
IAS -- aggregates / provides --> IF
IB -- realizes --> SV
IF -- assigned to / exposes --> SV
IB -- accesses --> P
SV -- may access --> P
EV -- triggers / is triggered by --> IB
EV -- may access --> P
This change also explains why the new term domain is better than layer. A domain is a classification space. It tells the reader which kind of architectural reality is being modeled:
The Business Domain depicts the organization, how it relates to customers, and what it consumes and produces.
The Application Domain depicts applications, how they work together, and which data they process.
The Technology Domain comprises both information technology and operational or physical technology.
The Common Domain contains generic elements that can be used with elements from different domains. Motivation, Strategy, and Implementation and Migration extend the language beyond the core.13
A domain does not imply that one region is above another. It only says that a concept belongs to a certain area of architectural description. That is closer to how enterprise systems actually work. A cyber-physical production line, a cloud platform, a digital customer journey, a data product, an AI assisted claims process, or an energy plant cannot be understood as a simple vertical stack. Human actors, application components, devices, facilities, equipment, data objects, artifacts, materials, services, and requirements interact in multiple directions.
This is also why the ArchiMate 4 depiction is not only a new picture. It is a correction of a misleading spatial metaphor. The old matrix mixed aspects and layers. The new hexagonal representation makes the language look less like a stack and more like a set of adjacent modeling territories around motivation, strategy, common concepts, core domains, and implementation. That visual shift matters because architecture methods often inherit more from their diagrams than from their formal definitions. People remember the picture before they remember the metamodel.
The shift also clarifies the relation with TOGAF. The white paper notes that TOGAF uses the term architecture domain and distinguishes business, data, application, and technology domains. ArchiMate matches the Business and Technology Domains, combines TOGAF application and data concerns inside the Application Domain, and adds Common, Motivation, Strategy, and Implementation and Migration Domains.14 This is not a perfect one-to-one mapping, and that is precisely the point. ArchiMate is not a diagrammatic copy of TOGAF. It is a language with its own metamodel, but it now uses terminology that better aligns with enterprise architecture practice.
This has a consequence for data architecture. ArchiMate 4 still does not define a separate Data Domain. The specification states that information modeling is supported across domains through passive structure elements: business objects, data objects, and artifacts represent information entities at different abstraction levels.15 This means that data is not absent. It is deliberately modeled through its relationship with business meaning, application processing, and technology realization. The architectural risk is that data architects may expect a distinct domain and read its absence as a weakness. The more precise reading is that ArchiMate treats data as a passive structure concern that cuts across domains rather than as a separate vertical layer.
The same applies to technology. The Technology Domain in ArchiMate 4 is not merely an infrastructure layer under applications. It includes information technology and operational or physical technology. This is essential for architecture domains such as manufacturing, utilities, logistics, healthcare, defense, smart buildings, energy systems, industrial automation, and digital twins. In those environments, technology is not just below software. It is part of the operational reality being governed. Equipment, facilities, material flows, distribution networks, communication networks, nodes, and system software may all participate in enterprise behavior.
The move from layers to domains therefore changes how architects should build views. A view should not start from the question which layer am I drawing? It should start from the concern to be addressed. If the concern is customer value, the view may combine stakeholders, outcomes, value streams, capabilities, products, services, and applications. If the concern is operational resilience, the view may combine business services, application components, nodes, communication networks, facilities, equipment, suppliers, and requirements. If the concern is AI-supported work, the view may combine roles, collaborations, processes, application components, data objects, models as artifacts, and governance requirements. The domain classification remains useful, but it is no longer the visual prison of the model.
This also affects how architects should explain ArchiMate to stakeholders. The old explanation was often: business uses applications, applications use technology. This remains acceptable as a simplified dependency story, but it is not the semantics of the language. A better explanation is: ArchiMate models an enterprise through domains and aspects. Domains classify the kind of reality being described. Aspects classify whether something is active structure, behavior, passive structure, motivation, or composite organization. Relationships then express how those concepts depend on, serve, realize, trigger, access, compose, or specialize one another.
In practical terms, this change should lead to stricter modeling discipline. A layer diagram can hide weak reasoning because vertical placement itself seems to imply meaning. A domain based model must make the meaning explicit through relationships. If an application component supports a process, show the service or assignment relation that makes the support clear. If a technology element realizes an application component, show the realization or deployment logic. If a human role and an AI service jointly perform a process, model the collaboration rather than forcing the process into a single layer.
The architectural gain is substantial. ArchiMate 4 becomes better suited to enterprises in which the boundary between business, application, technology, and physical operation is increasingly porous. A modern operating model may include humans assisted by AI, applications orchestrated through APIs, data products consumed by analytics services, IoT devices feeding operational decisions, cloud platforms controlling physical assets, and suppliers participating directly in enterprise processes. In such an environment, the old layer metaphor becomes too narrow. Domains provide a better abstraction because they classify without imposing a hierarchy.
This does not mean that layered views should disappear. They remain useful for communication, especially when the audience needs a high-level dependency picture. But they should be understood as viewpoints, not as the ontology of the enterprise. A layered view is one possible projection. The language itself is now telling us more clearly that architecture is not a stack. It is a set of interrelated domains, joined by explicit relationships, interpreted through stakeholder concerns.
The move from layers to domains is therefore one of the conceptual foundations of ArchiMate 4. It supports the merger of behavior elements, the introduction of the Common Domain, the generalization of role and collaboration, and the ability to model mixed human, application, technology, and physical systems without artificial duplication. It is the visible sign of a deeper correction: architecture should not be modeled as a vertical hierarchy unless the stakeholder concern genuinely requires that projection.
The move from layers to domains would remain incomplete without the introduction of the Common Domain as a first class part of the ArchiMate core language. If the previous section explains why the old vertical picture had to be corrected, this section explains what replaces it at the metamodel level. ArchiMate 4 does not merely rename layers as domains. It also extracts a set of concepts that were previously repeated across business, application, and technology contexts, and places them in a shared modeling space.
This is one of the deepest changes in the new specification. The ArchiMate core language is now defined as containing four core domains: Common, Business, Application, and Technology. The Common Domain contains generic elements, especially behavior elements, that can be used in combination with elements from different domains.16 This apparently simple formulation changes how the language should be read. The Common Domain is not an additional business, application, or technology area. It is the shared semantic kernel through which the other core domains can be connected without forcing every behavior, role, collaboration, or path into a prematurely specific category.
The official specification describes Chapter 4 as the chapter that covers the common, generic ArchiMate elements. The list is compact but structurally important: role, collaboration, path, service, process, function, event, grouping, and location.17 These are not marginal utility elements. They are the concepts through which much of the architecture becomes readable: who or what plays a role, who or what collaborates, what behavior is performed, what service is exposed, what event occurs, how elements are grouped, where things are located, and through which logical path exchange takes place.
%%{init: {"theme": "neo", "look": "forest"}}%%
flowchart TB
COMMON["Common Domain<br/>(classification, not an ArchiMate element)"]
subgraph AS["Active Structure Elements"]
R["Role"]
C["Collaboration"]
P["Path"]
end
subgraph BH["Behavior Elements"]
S["Service"]
PR["Process"]
F["Function"]
E["Event"]
end
subgraph CO["Composite Elements"]
G["Grouping"]
L["Location"]
end
N1["Grouping aggregates concepts<br/>that belong together by a common characteristic"]
N2["Location aggregates structure elements<br/>and may also aggregate behavior elements<br/>to indicate where behavior is performed"]
COMMON -. "explanatory classification" .-> AS
COMMON -. "explanatory classification" .-> BH
COMMON -. "explanatory classification" .-> CO
G -. "explanatory" .-> N1
L -. "explanatory" .-> N2
In earlier versions of the language, some of these ideas were present as abstract generic metamodel elements or as layer-specific concrete elements. ArchiMate 4 changes their status. The Common Domain replaces the previous generic metamodel treatment with concrete modeling elements that can actually be used in models. This matters because a concept that exists only as an abstract metamodel category does not directly help the modeler. A concept that exists as a concrete element does. The modeler can now represent a process without first deciding whether it is a business process, an application process, or a technology process.
The design logic is precise. From first principles, the distinction between behavior and performer is fundamental. A behavior is something that happens or is done. A performer is the active structure that carries it out. If the language encodes the performer inside the behavior type, it mixes two dimensions that should remain separable. A business process, an application process, and a technology process are all processes. What differs is not the abstract nature of the process, but the active structure assigned to it, the objects it accesses, the services it realizes or exposes, and the domain context in which the view is being built.
The motivation white paper makes this explicit. It argues that the previous triplication of behavior elements across the Business, Application, and Technology Layers created unnecessary overhead because the basic behavior concepts were semantically identical across layers. A business process, application process, and technology process all model causal or temporal sequences of behavior. The difference is who or what can perform them. ArchiMate 4 therefore collapses the three sets of behavior concepts into a single set, where assignment of active structure to behavior decides how that behavior is executed.18
This is why the Common Domain should not be treated as a cosmetic reshuffling of boxes. It changes the modeling grammar. A process is now a process before it is business, application, or technology related. A function is now a function before it is allocated to a department, a software component, a node, or a piece of equipment. A service is now a service before it is branded as a business service, application service, or technology service. The domain meaning is no longer primarily carried by the element type. It is carried by the structure of the model.
This is the decisive point. Under the old logic, an element name could carry much of the semantic burden. A business process was business because the element type said so. An application service was application because the element type said so. Under ArchiMate 4, the model must show the reason. A process may have a business actor or application component assigned to it, be supported by a node through a service, be associated with a location where the behavior is performed, access a data object, realize a service, or be part of a larger value stream. The architectural meaning emerges from the network of relationships, not from a single label.
That is a better architecture principle. Enterprise architecture should not depend on isolated names. It should depend on typed relationships between concepts. If an application component performs a behavior, that fact should be visible. If a human and an AI assistant collaborate in a claims process, that fact should be visible. If equipment and software jointly execute an operational routine, that fact should be visible. ArchiMate 4 makes these cases easier because it no longer forces each behavior into one domain-specific class before the real execution structure is known.
The Common Domain also supports delayed design commitment. This is architecturally important. At early architecture stages, it may be clear that a process must exist, but not yet clear whether it will be manual, automated, robotic, AI assisted, outsourced, or distributed across humans and systems. In ArchiMate 3.2, choosing a business, application, or technology process could force a design decision too early. In ArchiMate 4, the modeler can first represent the process as a generic behavioral element, without prematurely deciding who or what will perform it. Its realization and execution can then be refined later through assignment, realization, serving, access, and specialization relationships.
This aligns with how architecture actually evolves. Early architecture work often starts with intent, capability, outcome, and behavioral need. Only later do architects decide which organizational roles, applications, platforms, facilities, devices, equipment, or suppliers should perform the behavior. A language that forces execution classification too early creates artificial certainty. A language that allows behavior to be represented generically preserves architectural optionality.
This is particularly important in AI-supported and cyber-physical architectures. Consider a process such as Assess Claim. It may be performed by a human claims specialist, an AI-powered application component, a rule engine, a document processing service, or a collaboration of all of them. The Open Group motivation paper uses a similar insurance example to show an automated AI-powered claims assessor collaborating with human employees in a claim handling process. It also notes that ArchiMate 4 permits the assignment of non human actors to roles, while distinguishing responsibility to perform tasks from legal accountability.19 This example is not a fashionable AI anecdote. It reveals the structural reason for the Common Domain: modern enterprise behavior is often performed by mixed human and machine structures.
The same applies to operational technology. A maintenance process in an energy plant may involve a field technician, a remote service provider, a SCADA application, diagnostic software, network infrastructure, equipment, and physical facilities. It is artificial to force the process into a single layer if execution crosses people, software, hardware, and physical assets. A generic process with a collaboration of active structure elements assigned to it is semantically cleaner.
The Common Domain therefore functions as an anti-duplication mechanism. In ArchiMate 3.2, a partially automated process could require both a business process and an application process, connected by realization, just to express that part of the work was automated. The motivation paper describes this as duplication that adds model elements without adding insight.20 ArchiMate 4 removes the need for this pattern. The process can remain one behavior, while the assigned active structures explain how it is performed.
The same logic applies to service. In previous modeling practice, business service, application service, and technology service were often treated as distinct architectural species. ArchiMate 4 pushes toward the more fundamental idea: a service is explicitly defined behavior provided to an environment. The provider may be a business actor, an application component, a node, a device, system software, equipment, a facility, a role, or a collaboration.21 The service is not made meaningful by its color alone. It is made meaningful by who provides it, what realizes it, what interface exposes it, what consumes it, and what value or requirement it is connected to.
This shift is subtle but powerful. It reduces the tendency to model services as layer labels and encourages modelers to express service boundaries explicitly. A customer facing service may be realized by business and application behavior. An integration service may be exposed by an application interface and supported by technology services. A plant monitoring service may involve application components, communication networks, devices, and remote operational roles. The Common Domain lets the service concept stay stable while its realization structure varies.
Role is another important example. In ArchiMate 4, role is generic. It represents the position or purpose that a business actor, application component, node, device, system software, equipment, facility, or collaboration has in performing specific behavior.22 This breaks the assumption that roles are only organizational or human categories. Architecturally, many non human structures play roles: an application may act as system of record, policy decision point, identity provider, orchestration component, monitoring agent, or claims assessor. A node may act as gateway, broker, hosting environment, or security boundary. Equipment may act as controlled asset, sensing device, actuator, or production unit.
This does not mean that machines become legally accountable. The motivation paper explicitly warns against that confusion. It explains that roles can represent responsibility for performing tasks, while responsibility and accountability are different notions.23 This distinction is useful. In an enterprise model, an AI component may fulfill the role of Automated Claims Assessor in a process. But the accountability for the claim decision may still belong to a business actor, such as a legal department, claims manager, or regulated entity. ArchiMate 4 gives the language enough flexibility to model this separation, provided the organization defines the right specialization and accountability conventions.
Collaboration follows the same pattern. It is now a generic Common Domain element. It can collect business actors, application components, nodes, devices, system software, equipment, facilities, roles, and other collaborations that work together to perform collective behavior.24 This is essential because many enterprise capabilities are produced not by one actor or one system, but by socio-technical ensembles. An incident response capability may involve analysts, SIEM tools, SOAR automation, identity platforms, network devices, cloud services, and external providers. A manufacturing capability may involve operators, robots, MES, ERP, sensors, materials, and facilities. A digital lending capability may involve customers, brokers, scoring engines, document services, data providers, compliance checks, and human approval roles.
A generic collaboration allows the architecture to represent this collective execution without inventing artificial layer-specific collaborations. This is another place where ArchiMate 4 better fits real enterprise systems. The enterprise is not made of pure business processes above pure application processes above pure technology processes. It is made of coordinated behavior performed by mixed active structures.
Path also becomes more significant because it is part of the Common Domain. A path represents a logical link between active structure elements through which information, data, energy, or material can be exchanged.25 Its inclusion in the Common Domain is coherent with the move from layers to domains. A path is not only an IT network concern. It may represent organizational communication, logical data exchange, material movement, energy distribution, or other exchange patterns. Its physical realization may later be modeled through communication networks, distribution networks, facilities, equipment, or other active structures.
This matters because many architectures confuse logical connectivity with physical realization. A remote maintenance path, for example, is not the same thing as a VPN, a firewall rule, a jump host, a private link, or a mobile connection. Those may realize or support it. The path is the logical dependency. Modeling it as common avoids tying it too early to a particular technology implementation.
Grouping and location also become part of this shared architecture vocabulary. Grouping collects concepts that belong together based on some common characteristic. Location represents a place or position where structure elements can be located or behavior can be performed.26 These concepts are deceptively simple, but they are essential in enterprise models because they allow architects to express boundaries that are not always purely business, application, or technology boundaries: security zones, deployment environments, legal entities, sites, regions, cloud locations, plants, data residency areas, transition scopes, product domains, and architectural building blocks.
However, the Common Domain must not become a dumping ground. That is the main governance risk. If modelers use generic process, service, role, collaboration, and path without explicit relationships, the result is not a better model. It is a less informative one. The Common Domain only works if the modeler accepts that meaning must be expressed relationally. A process should show who or what performs it. A service should show what realizes it and what it serves. A role should show which active structure fulfills it. A collaboration should show its participants. A path should show what it connects and how it is realized where relevant.
This is the price of normalization. ArchiMate 4 removes redundant primitive distinctions, but those distinctions do not disappear from architectural reasoning. They must now be reconstructed through context. This is a stronger and more flexible method, but it requires more disciplined modeling.
For repository governance, this has concrete implications. A model repository should not allow the uncontrolled proliferation of generic elements without context. It should enforce or at least report missing assignments, unserved services, unrealized services, unassigned roles, collaborations without participants, and paths without connected structures. It should define when a process needs a specialization profile, when a generic service is acceptable, when a role represents performance responsibility, and when a separate accountability construct is required. Without this governance, the Common Domain can reduce formal complexity while increasing semantic ambiguity.
The migration from ArchiMate 3.2 makes this issue visible. The motivation paper describes two conversion options. The first is to turn each layer-specific concept into the corresponding generic concept and infer its origin from assignments where possible. The second is to add specialization profiles to preserve the original layer semantics, so that no information is lost during conversion.27 The second approach is more robust for serious repositories. If an enterprise has years of models using business process, application process, and technology process, it should not collapse everything into undifferentiated process without preserving the original semantic intent.
This means that a mature ArchiMate 4 adoption should define a profile strategy. For example, an organization may keep specializations such as Business, Application, and Technology for behavior elements converted from ArchiMate 3.2. It may later decide that some of these specializations are only transitional, while others remain useful for governance. The important point is that the decision must be explicit. If the distinction is architecturally relevant, preserve it. If it was only a historical artifact, remove it. But do not let a tool migration make the decision silently.
The Common Domain also changes how architects should teach the language. In the old teaching pattern, one often started with layers: business, application, technology. In ArchiMate 4, it is more rigorous to start with aspects and domains: active structure, behavior, passive structure, motivation, composite organization, and then explain how domains classify architectural reality. This reflects the linguistic analogy already present in the specification: active structure is like the subject, behavior is like the verb, and passive structure is like the object.28 The Common Domain supplies several of the generic verbs and coordination constructs that can operate across the whole sentence of architecture.
This also changes the semantics of color. In many ArchiMate diagrams, colors have been used to distinguish domains. The specification allows colors to be used for emphasis and gives example domain colors, including warm gray for the Common Domain.29 But once concepts become generic, color cannot carry too much semantic weight. A gray process assigned to a business actor may still be business relevant. A gray service realized by application behavior may still be application relevant. Domain color becomes a cue, not the full meaning. The model structure must do the semantic work.
The introduction of the Common Domain is therefore both a simplification and a challenge. It simplifies the language by reducing redundant constructs. It improves expressiveness for mixed human and machine systems. It supports gradual refinement from generic behavior to specific execution. It aligns better with BPMN and UML, where behavior is not subdivided by enterprise layer in the same way.30 It makes cross domain collaboration easier to model. It reduces duplication in partially automated processes.
But it also makes weak models more visible. If an architect used business process as a substitute for explaining who performs the work, that shortcut is less available. If a repository relied on element type alone to separate domains, it must now rely on better relationships, profiles, attributes, views, and validation. If a tool presented architecture mainly as colored boxes, it must now help users understand the semantic graph behind those boxes.
In my view, this is the right tradeoff. A mature enterprise architecture language should not multiply primitives whenever execution context varies. It should define stable concepts and let relationships express context. The Common Domain is exactly this kind of stable core. It says that some architectural notions are more fundamental than business, application, or technology classification. Processes, services, functions, events, roles, collaborations, paths, groupings, and locations are not owned by one domain. They are the connective tissue of enterprise architecture.
The Common Domain becomes central because ArchiMate 4 is no longer organized around a simple vertical stack. Once the language abandons the misleading hierarchy of layers, it needs a shared vocabulary for concepts that naturally cut across domains. The Common Domain is that vocabulary. It is the place where ArchiMate 4 expresses the fact that modern enterprise architecture is not built from isolated layers, but from relationships among actors, systems, physical assets, behavior, information, and transformation intent.
The merger of behavior elements is the operational core of the ArchiMate 4 redesign. The move from layers to domains changes the mental picture of the language. The Common Domain provides the shared vocabulary. But the merger of behavior elements is where the new semantics become concrete. ArchiMate 4 no longer asks the modeler to choose among business process, application process, and technology process as different primitive concepts. It gives the modeler one process concept. The same logic applies to service, function, and event.
This change is not only a simplification of notation. It is a correction of a modeling error that emerges when the performer of behavior is confused with the behavior itself. From first principles, a behavior is an occurrence, activity, capability in execution, or externally visible functionality. A performer is an active structure element that carries out or exposes that behavior. These are different dimensions. If the language creates separate behavior concepts for each class of performer, it encodes execution allocation into the type of the behavior itself. That is too early and too rigid for many enterprise architecture problems.
The Open Group white paper states the issue directly. In ArchiMate 3.2, the set of behavior elements was basically identical across the Business, Application, and Technology Layers. The only real difference was who or what could perform that behavior, meaning which active structure elements could be assigned to it. The paper observes that there is no inherent semantic difference between a business process, an application process, and a technology process: all three model causal or temporal sequences of behavior.31
This is the central argument. If two concepts differ only because different performers are allowed to execute them, then the distinction belongs in the assignment relation, not in the behavior concept. A process should be classified as a process because it is a sequence of behaviors that achieves a result. Whether it is performed by a person, an application component, equipment, system software, a robot, a collaboration, or a mixture of these is a separate architectural fact.
The ArchiMate 4 Specification is consistent with this separation. It defines the Behavior Aspect as representing processes, functions, events, and services performed by actors, with structural elements assigned to behavioral elements to show who or what displays the behavior.32 This is the clean abstraction: behavior is the verb; active structure is the subject; passive structure is the object. The sentence is not encoded by choosing a different verb for each possible subject. It is encoded by relating subject, verb, and object explicitly.
This also means that ArchiMate 4 makes the model more relational. In ArchiMate 3.2, an element type such as Business Process carried two meanings at once: it said that something was a process, and it said that the process belonged to the business layer. In ArchiMate 4, the element type says only the first thing. The second meaning must be shown by context: assignment to a business actor or role, access to a business object, realization of a service, participation in a value stream, association with a product, or specialization profile if the repository wants to preserve the old classification.
This is more demanding, but also more precise. It prevents a common false certainty. In many transformation initiatives, a process is initially described as business simply because the discussion starts with business stakeholders. Later, part of that process becomes automated, outsourced, instrumented, monitored, or delegated to an AI component. If the original model fixed the process as business behavior, the architect then has to duplicate the behavior as application behavior or technology behavior and connect the two. The model grows, but the architecture has not necessarily become clearer.
The motivation white paper uses the example of partially automated processes to explain this. In ArchiMate 3.2, properly modeling that a business process was fully or partially automated often required creating an application process, connecting the application process to the business process through realization, and then modeling an assignment from the application component to the application process. The paper describes this as duplication without added insight, because the duplicated behavior and the realization relation become overhead introduced by the language structure itself.33
ArchiMate 4 solves the problem at a more fundamental level. Instead of modeling business behavior and application behavior as two different primitive kinds, it models behavior once and uses assignment to indicate execution. The motivation paper states the solution plainly: the standard collapses the three sets of behavior concepts into a single one, so instead of business process, application process, and technology process, there is a single concept, process. The assignment of an active structure element to that behavior element decides how the behavior is executed.34
This has direct consequences for architecture work. A process can now be modeled before its implementation mode is known. At an early stage, the architect may know that claims must be assessed, invoices must be matched, maintenance must be planned, access must be approved, energy production must be forecast, or incidents must be triaged. At that stage, the architectural question is behavioral: what must happen? The design question of who or what performs it may come later. ArchiMate 4 allows that separation.
This is especially useful because modern enterprise behavior is often hybrid. A claims assessment process may involve a human specialist, a workflow engine, an AI classifier, a document extraction service, a rules engine, and a compliance reviewer. A warehouse picking process may involve workers, handheld devices, warehouse management software, automated conveyors, scanners, and robotics. A SOC incident process may involve analysts, SIEM rules, SOAR playbooks, identity platforms, cloud logs, endpoint agents, and external threat intelligence. A plant maintenance process may involve field technicians, SCADA systems, remote service zones, diagnostic applications, network infrastructure, equipment, and physical facilities.
In all these cases, the old layer-specific behavior vocabulary creates pressure to split the real process into multiple artificial fragments. ArchiMate 4 removes that pressure. One process can be performed by a collaboration of active structure elements from different domains. The white paper identifies this as one of the explicit motivations: ArchiMate 3.2 could not easily define a process performed by active structure elements from different layers, such as a factory worker plus a robot, or an office worker plus an AI assistant. It states that this modeling pattern is increasingly common and was not easy to represent before.35
The merger of behavior elements also improves the relationship between ArchiMate and specialized behavioral notations. The white paper compares ArchiMate with BPMN and UML. BPMN does not divide tasks into business, application, and technology layers; its basic task concept may be specialized, and the participant or swimlane helps determine who or what performs the work. UML activity diagrams similarly do not subdivide actions according to the layer of the performer.36 This comparison matters because enterprise architects often need to connect an ArchiMate view to a more detailed process or software design model. A generic process concept makes that mapping more natural.
This does not mean ArchiMate becomes BPMN. It remains an enterprise architecture language. The ArchiMate 4 Specification explicitly says that an ArchiMate process depicts the existence of high-level processes, end-to-end processes, macro flows, workflows, and automated processes, but does not list the detailed flow of activities; detailed process modeling is typically done in a process design language such as BPMN.37 This boundary is important. ArchiMate 4 simplifies the conceptual bridge to BPMN, but it does not absorb BPMN execution semantics.
The distinction between process and function becomes more important after the merger. If the old distinction between business process and application process disappears, modelers need to rely more carefully on the internal distinction between kinds of behavior. The ArchiMate 4 Specification defines a process as a sequence of behaviors that achieves a specific result. It defines a function as a collection of behavior based on a chosen set of criteria.38 Informally, a process expresses flow, while a function groups behavior by resources, skills, competencies, knowledge, application support, or another organizing criterion.
This distinction should not be treated casually. A process is appropriate when sequence, triggering, outcome, or flow matters. A function is appropriate when grouping, responsibility, capability support, competence, system function, or operational grouping matters. For example, Approve Purchase Order is probably a process when the concern is the sequence from request to approval. Procurement Management is probably a function when the concern is the grouping of procurement related behavior. Replicate Database may be modeled as a process if the concern is execution flow, or as a function if the concern is a stable capability of a platform. The correct choice depends on the architectural concern, not on whether the performer is human or technical.
Service also changes in practical importance. Under ArchiMate 4, service is no longer only business service, application service, or technology service as a primitive type. It is a generic external behavior element: explicitly defined behavior that some active structure element, role, or collaboration provides to its environment.39 The architectural question becomes: what behavior is exposed, to whom, through which interface, and realized by which internal behavior? This is a better service model because it keeps the black box and white box distinction clear. The service is the externally visible behavior. The process or function is the internal behavior that may realize it.
This distinction is especially useful in API, platform, shared service, and OT scenarios. A platform may expose a Data Replication Service realized by technical functions and application processes. A business capability may expose a customer onboarding service realized by human and automated behavior. A plant operator may expose a remote diagnostic service realized by OT applications, network paths, jump hosts, procedures, and human roles. The service remains one conceptual kind. Its provider and realization structure explain the domain context.
Event also becomes more generic. The ArchiMate 4 Specification defines an event as something that happens or occurs inside or outside the enterprise, such as a state change. Events may trigger or be triggered by behavior, and may originate from customers, external systems, internal systems, or physical environments.40 This is important because events in modern architectures are not purely business events, application events, or technology events. A sensor alarm, customer request, market signal, cybersecurity alert, equipment fault, API notification, workflow milestone, or regulatory deadline may all be architecturally relevant events. The relevant question is what the event triggers, what information it carries, and which structure detects or emits it.
The benefit of the merged behavior model is therefore not only fewer boxes. It is better separation of concerns. The model can distinguish:
the behavior itself;
the performer of the behavior;
the service exposed by the behavior;
the interface through which the service is accessed;
the passive structure acted upon;
the event that triggers the behavior;
the function that groups behavior;
the process that sequences it.
These distinctions are more fundamental than the old layer-specific behavior labels.
The same reasoning clarifies automation. In ArchiMate 3.2, automation could be misrepresented as a realization relation from application behavior to business behavior, reinforcing the mistaken idea that application behavior is a lower level realization of business behavior. The motivation paper notes that this workaround may have given the impression that the Business Layer is an abstraction of the Application Layer, although that was not the intent.41 ArchiMate 4 avoids this by letting automation be expressed through assignment: the process is performed, wholly or partly, by an application component or by a collaboration including technical structures.
This has a strong methodological implication. Architects should stop using realization as a default way to say this part is automated. Realization should remain for the relation between more concrete and more abstract elements where that semantics is intended. If the real question is who performs behavior, use assignment. If the real question is what exposes behavior, use service and interface. If the real question is what supports behavior, use serving. If the real question is what sequence occurs, use triggering or flow. ArchiMate 4’s merged behavior model makes this distinction cleaner.
The merger also reduces premature decomposition. In earlier versions, a business process might be decomposed into a mix of business subprocesses and application processes, but the layer-specific rules could make this awkward. In ArchiMate 4, processes can aggregate other processes or functions regardless of whether some are manual, automated, or mixed. This supports incremental refinement. At a high-level, Handle Claim may be one process. Later, it may aggregate Accept Claim, Assign Claim, Adjudicate Standard Claim, Adjudicate High Risk Claim, Pay Claim, Notify Customer, and Close Claim. Human roles may be assigned to some of them. Some may be performed by application components through assignment relationships. Some may be performed by collaborations through assignment relationships.
This is exactly the type of example shown in the motivation paper’s cross domain diagram. The paper describes an automated AI-powered claims assessor that collaborates with human employees in the claim handling process. The AI-powered assessor may adjudicate standard claims, while high risk claims require a senior legal specialist.42 The example matters because it shows that the language change is not abstract housekeeping. It supports a real pattern of work: human and machine behavior in one architecture.
This does not remove the need for accountability modeling. If an AI component performs a task, the enterprise still needs to know who is accountable for the result. ArchiMate 4 gives the modeler the ability to assign a non human active structure to a role, but the motivation paper warns that this does not imply machines become legally accountable. Responsibility for performing tasks and legal accountability are different notions.43 This is a critical governance point. The merged behavior model enables better representation of machine participation, but the enterprise still needs explicit rules for accountable human or organizational ownership.
The migration issue is not trivial. If an existing ArchiMate 3.2 repository contains thousands of business processes, application functions, technology services, application events, and technology processes, a simple mechanical replacement may lose useful information. The motivation paper describes two conversion options. One is to convert each layer-specific concept into the corresponding generic concept and infer its origin from assignments where possible. The other is to assign a specialization profile showing from which ArchiMate 3.2 layer the generic concept originated, so that no information is lost.44
For serious enterprise repositories, the second option is safer. A large repository is not only a set of diagrams. It is an institutional memory of architecture decisions. If the repository distinguishes business processes from application processes, that distinction may be redundant in some cases, but meaningful in others. It should not be erased blindly. During migration, architects should classify which distinctions were merely artifacts of the old language and which distinctions are still needed for governance, reporting, ownership, or stakeholder communication.
A practical migration policy should therefore treat behavior elements in three classes.
| Class | Migration treatment | Rationale |
|---|---|---|
| Generic without loss | Convert to the corresponding ArchiMate 4 behavior element | The performer and domain context are already clear from relationships |
| Generic with preserved specialization | Convert to the generic element and preserve the old origin through a specialization profile or attribute | The old distinction remains useful for reporting, governance, or stakeholder communication |
| Refactor | Remove artificial duplication and rebuild the model around generic behavior, assignment, realization, service exposure, and access relationships | The old structure existed mainly to satisfy ArchiMate 3.2 modeling constraints |
The last class is the most valuable. ArchiMate 4 offers an opportunity to remove artificial pairs such as business process plus application process where the application process only existed to show automation. The cleaner ArchiMate 4 model may contain one process, assigned to the correct combination of active structures, with services and interfaces modeled explicitly. This reduces model size and improves semantic transparency.
However, there is a danger on the opposite side. Generic behavior elements can become too vague if modelers do not use assignments, relationships, and profiles consistently. A diagram full of gray processes and services without clear performers, consumers, accessed objects, realized services, or triggering events is not a better ArchiMate 4 model. It is a weaker model. The merger of behavior elements only works if modelers express execution context explicitly.
This means that repository validation should become more important. Architecture teams should define rules such as:
every process should have at least one assigned role, collaboration, or active structure unless it is deliberately abstract;
every service should have a clear provider or realization path;
every event should have a meaningful triggering or access relation where relevant;
every function should be distinguishable from a process by naming and modeling pattern;
every converted behavior element should either preserve its legacy specialization or be explicitly normalized.
These are not language rules imposed by the standard. They are governance rules needed to make the simplified language work.
The merger also changes architectural analysis. In ArchiMate 3.2, reports could filter by element type: business processes here, application functions there, technology services elsewhere. In ArchiMate 4, analysis must often follow relationships. To find processes performed by applications, query processes to which application components are assigned. To find human performed behavior, query processes or functions assigned to business actors or roles. To find mixed execution, query behavior assigned to collaborations aggregating active structures from multiple domains. This is analytically better because it reflects the actual model semantics, but it requires more capable repositories and better query discipline.
This is why the merger is not a mere reduction of concepts. It is a shift from taxonomic modeling to relational modeling. The old language put more meaning in the taxonomy of element types. The new language puts more meaning in the graph of relationships. For enterprise architecture, this is the right direction, because real architectures are not just classified inventories. They are dependency structures.
There is also a philosophical consequence. ArchiMate 4 recognizes that behavior is domain independent at the level of enterprise architecture. A process is not business because it is called business. It is business relevant because it is performed by business actors, realizes business services, supports a value stream, accesses business objects, or contributes to business outcomes. A process is application relevant because application components perform or support it. It is technology relevant because nodes, devices, equipment, system software, or facilities participate in it. The same behavior can be relevant to several domains at once.
This better matches modern operating models. Digital transformation, automation, AI, platformization, and cyber-physical integration all make the boundary between business and technology less clean. The old statement business defines what, IT defines how is often too simple. In many enterprises, the what is shaped by what platforms, data, algorithms, and operational technology make possible. Conversely, technology decisions are shaped by organizational roles, regulatory constraints, customer value, and operating model design. A generic behavior model is more capable of representing that mutual shaping.
The merger of behavior elements therefore has two meanings. At the language level, it reduces the number of primitive concepts and removes redundancy. At the architecture level, it supports a more realistic description of hybrid execution. It lets architects model behavior first, then assign responsibility, automation, realization, service exposure, data access, and event dependency through explicit relationships.
This is the heart of ArchiMate 4. The language becomes smaller, but the model should become more truthful. It no longer says this is business behavior merely because a box belongs to the Business Layer. It asks the architect to show how the behavior is performed, by whom or by what, on which objects, through which services, under which triggers, and in which architecture context. That is harder than choosing a layer-specific element. It is also closer to the real structure of enterprise systems.
The removal of interaction elements is a smaller change than the merger of behavior elements, but it is conceptually important because it shows how strict ArchiMate 4 is about eliminating weak primitives. Business interaction, application interaction, and technology interaction are no longer part of the core language as separate elements. The ArchiMate 4 Specification lists them among the concepts removed from version 3.2, and states that business, application, and technology interactions can be replaced by a specialization of function or process.45
This change should not be read as a denial that collective behavior exists. Collective behavior is still central to enterprise architecture. What changes is where that meaning is represented. In ArchiMate 4, collective execution is modeled primarily through collaboration, assignment, process, function, and, where needed, multiplicity or specialization. The separate interaction element is no longer needed as a primitive.
The first reason is empirical. The Open Group white paper states that the interaction concepts were hardly used in practice. Its usage analysis, based on a sample of 17 medium to large user organizations across sectors such as government, banking, insurance, infrastructure, energy, and manufacturing, found that the three interaction concepts were in the lower part of the usage list. The sample covered more than 600,000 elements and nearly 1,000,000 relationships, so this was not a trivial anecdotal observation.46
Usage frequency is not, by itself, a proof that a concept should be removed. Some rare concepts are still important. The white paper itself notes that frequency is not the only measure of relevance, since concepts such as stakeholder and principle may be important without appearing thousands of times in models.47 But low usage becomes significant when combined with semantic ambiguity. A rarely used concept whose meaning is clear may deserve preservation. A rarely used concept whose meaning is unclear becomes a candidate for removal.
That is exactly the case for interaction. The white paper says that the meaning of interaction was not very clear or well understood, which may explain why most users ignored it. The ambiguity is fundamental: is an interaction sequence like a process, because it represents behavior performed in a specific order, or is it grouping like a function, because it collects behavior according to some criterion other than sequence?48
This is not a superficial naming problem. It is a metamodel problem. A primitive concept should earn its place by adding a distinction that cannot be represented more cleanly by existing concepts. If interaction is sequence oriented, then it is very close to process. If it is grouping oriented, then it is very close to function. If its only special property is that behavior is performed collectively, then that property belongs to the assignment of a collaboration or to a multiplicity constraint on assigned active structure elements, not to a separate behavior element.
The white paper makes this point explicitly. If interactions are process like, their only differentiating property is that they must be performed by more than one active structure element. With multiplicity on relationships, ArchiMate 4 can express this more flexibly, for example by using a cardinality such as 2..* to indicate that at least two active structure elements must have an assignment relationship with a process.49 This is a cleaner model because the collective nature of execution is expressed where it belongs: in the relation between performers and behavior.
The second reason is theoretical. Interaction mixed two questions that should remain separate. The first question is: what kind of behavior is this? The second question is: how many and which active structures perform it together? Process and function answer the first question. Collaboration, assignment, and multiplicity answer the second. A separate interaction concept combined both dimensions into one box. ArchiMate 4 removes that shortcut.
This is coherent with the previous sections. The move from layers to domains rejected the idea that behavior should be classified through a vertical hierarchy. The Common Domain introduced generic behavior and active structure coordination concepts. The merger of behavior elements separated behavior from performer. The removal of interaction continues the same logic: do not create a primitive concept when the same meaning can be represented by a more precise combination of simpler concepts.
The old interaction concepts were also constrained by the old layer structure. Business interaction was collective business behavior. Application interaction was collective application behavior. Technology interaction was collective technology behavior. The ArchiMate 4 Specification still gives these as possible specializations of Common Domain behavior concepts, defining business interaction as collective business behavior performed by a collaboration of business actors, roles, or business collaborations, application interaction as collective application behavior performed by a collaboration of application components, and technology interaction as collective technology behavior performed by a collaboration of technology internal active structure elements.50
This is an important nuance. ArchiMate 4 does not forbid the vocabulary of interaction. It demotes interaction from a primitive element to an optional specialization. That is exactly the right status for a concept that may be useful in some organizations but is not fundamental enough to burden all users of the language.
The distinction matters for governance. A primitive element is part of the standard language every modeler must understand. A specialization is a controlled local or example refinement. It can be used where it adds value, but it does not force every modeler to learn and maintain a separate conceptual category. This is consistent with the broader ArchiMate 4 strategy: keep the core small, and allow specializations where more precision is needed.
There is also a strong practical reason to prefer collaboration plus process or function. Collaboration is now generic. It can represent a collection of business actors, application components, nodes, devices, system software, equipment, facilities, roles, or other collaborations that work together to perform collective behavior.51 This is more powerful than the old interaction elements, because modern collective behavior often crosses old layer boundaries.
Consider an incident response scenario. A security incident is triaged by analysts, SIEM correlation rules, SOAR playbooks, endpoint agents, identity systems, cloud controls, and sometimes external providers. Is that business interaction, application interaction, or technology interaction? It is all of them and none of them. The right model is not a layer-specific interaction. The right model is a process or function with a collaboration of active structures from several domains assigned to it.
The same applies to an AI-supported approval process. A human reviewer, an AI classifier, a workflow application, a policy engine, a data quality service, and a compliance role may jointly participate in the behavior. The collective nature is real. But it is not purely business, application, or technology. A generic collaboration assigned to a process represents it more accurately than a layer-specific interaction.
The same applies to operational technology. A maintenance action may be performed by a technician, a robot, equipment, a diagnostic application, a remote service platform, and a plant control system. Calling this a technology interaction may hide the human and organizational dimension. Calling it a business interaction may hide the equipment and software dimension. Treating it as a process or function performed by a cross domain collaboration is more faithful to the actual architecture.
This is why the removal of interactions is not a loss of expressive power. It is a removal of a misleading compression. The previous concept compressed collective behavior, sequence or grouping, and domain classification into one element. ArchiMate 4 decomposes that meaning into more fundamental parts. The behavior is a process or function. The collectivity is collaboration or multiplicity. The domain context is expressed by the assigned active structures and optional specialization profiles.
The modeling pattern becomes straightforward. First, decide whether the behavior is sequence oriented or grouping oriented. If the concern is flow, order, triggering, or result, use process. If the concern is capability grouping, responsibility area, system function, or stable behavioral grouping, use function. Then model the performers. If several active structures jointly perform the behavior and the combination has architectural identity, model a collaboration and assign it to the behavior. If the exact collaboration is not important, but the number of participants is architecturally relevant, use multiplicity on assignment. If the old interaction distinction remains useful for communication or migration, apply a specialization profile.
This is more rigorous than simply drawing an interaction element. It forces the architect to state what kind of collective behavior is being modeled and how the collective execution works. Does the behavior require all participants, or any one of several participants? Is it a stable collaboration or a temporary one? Is the sequence important? Is it a function performed by a team or platform? Is the behavior collective because the active structures work simultaneously, because they coordinate sequentially, or because they jointly provide a service?
The old interaction element did not answer these questions clearly. It only signaled that some collective behavior existed. ArchiMate 4 makes the modeler be more explicit.
There is also a relationship with junctions and multiplicity. In older models, interaction could sometimes be used as a high-level placeholder for several participants and behaviors. In ArchiMate 4, if the concern is logical participation, collaboration and assignment are better. If the concern is branching or joining behavior, junctions on triggering relationships remain available. If the concern is the number of required assigned performers, multiplicity can express it. These are different architectural facts and should not be collapsed unnecessarily.
This matters because collective behavior is often where architectural risk hides. If a behavior requires two departments, three systems, and an external provider, the risk is not simply that an interaction exists. The risk lies in the dependencies among participants, the handoff points, the ownership model, the data exchanged, the service boundaries, and the failure behavior. A generic interaction element is too coarse to govern those questions. A process or function with explicit collaborations assigned to it, and connected through flow, triggering, access, and serving relationships is more useful for analysis.
For example, in a claims process, a human legal specialist and an AI assessor may both participate, but not with the same authority. The AI assessor may handle standard claims, while high risk claims require the legal specialist. The motivation white paper uses a similar example on pages 9 and 10, showing an automated AI-powered claims assessor collaborating with human employees, with high risk claims requiring a senior legal specialist.52 This is a good illustration of why generic interaction is insufficient. The architectural concern is not merely that behavior is collective. The concern is which participant may perform which part under which condition.
In a migrated ArchiMate 4 model, that scenario should be expressed through process decomposition, assignment, roles, specialization where useful, triggering, and perhaps constraints or requirements. A single interaction element would hide too much. The new model may seem slightly more explicit, but it is more analyzable.
This is also why the conversion rule matters. The ArchiMate 4 Specification says that business, application, and technology interactions can be replaced by a specialization of function or process.53 The word or is important. It means that conversion cannot be purely mechanical in all cases. The modeler must interpret the old interaction. Was it intended as sequence? Convert it to process. Was it intended as a behavioral grouping? Convert it to function. Was the old interaction used only to show collective execution? Convert it to process or function, then model the collaboration and assignment explicitly.
A responsible migration therefore needs a semantic review of interactions. Because the white paper says their meaning was often unclear, the migration should not assume that every old interaction was used correctly. Some interactions may represent actual process behavior. Some may represent functional grouping. Some may be redundant because a collaboration and assignment already express the intended meaning. Some may be ambiguous and require discussion with the model owner.
This is also a good example of why repository migration from ArchiMate 3.2 to ArchiMate 4 should not be treated as a file format exercise. If the repository contains interaction elements, each one is a signal that the model may contain hidden ambiguity. The migration team should ask what the interaction was trying to say. If the answer is two or more actors perform this behavior together, then collaboration and assignment are probably enough. If the answer is these activities occur in an ordered exchange, then process and triggering may be needed. If the answer is these components cooperate to provide a function, then function and collaboration may be better.
The same discipline should apply to specializations. Keeping Business Interaction, Application Interaction, and Technology Interaction as specialization profiles may be useful during migration, especially when old diagrams are still used by stakeholders. But these specializations should not become a way to reintroduce the old ambiguity permanently. A specialization should have a definition, a modeling rule, and a reason to exist. Otherwise it becomes conceptual debt under a new name.
This is the broader lesson of the interaction removal. ArchiMate 4 does not remove complexity from the enterprise. It removes a weak category from the core language. The complexity of collective behavior remains and must be modeled more explicitly. That is a good tradeoff. A weaker primitive is replaced by a stronger composition of concepts.
The practical consequence is that architects should model collective behavior with a small set of questions. What is the behavior: process or function? Who or what participates: roles, actors, application components, nodes, devices, equipment, facilities, or collaborations? Is participation mandatory, optional, alternative, or conditional? Does the collective have architectural identity as a collaboration? Does the behavior expose a service? Does it access business objects, data objects, artifacts, or material? Does it require a specialization profile for communication or migration?
Those questions produce better models than the old interaction element because they expose the structure of cooperation. Cooperation is not one thing. It may be sequential, parallel, conditional, organizational, technical, contractual, physical, or automated. ArchiMate 4 gives the modeler the smaller primitives needed to represent these differences without forcing every user to carry a separate interaction concept.
The removal of interactions therefore belongs to the same design movement as the Common Domain and the behavior merger. ArchiMate 4 becomes less taxonomic and more compositional. It removes element types that encoded too much and replaces them with combinations of process, function, collaboration, assignment, multiplicity, and specialization. The model becomes slightly less dependent on vocabulary and more dependent on explicit structure.
In my judgment, this is a correct decision. Interaction was not useless, but it was not fundamental. Its useful meaning can be recovered by clearer constructs. Its ambiguous meaning should not be preserved. In a language whose stated goal is communication, concepts that are both rarely used and poorly understood are expensive. Removing them reduces cognitive load and forces collective behavior to be modeled where it belongs: in the relation between behavior and the active structures that perform it.
The generalization of role and collaboration is one of the most important consequences of the Common Domain. It is also one of the changes that best reveals the deeper architectural direction of ArchiMate 4. The language no longer treats role as only a business construct, and it no longer treats collaboration as three separate layer-specific constructs. Role and collaboration become generic concepts that can operate across the whole ArchiMate core.
The ArchiMate 4 Specification states the change directly: business, application, and technology collaborations have been merged into a single collaboration element, and business role has been replaced by a generic role element to which any internal active structure element can be assigned.54 The motivation white paper explains the same point in the context of the behavior merger: a single collaboration concept replaces layer-specific collaboration concepts and may aggregate active structure elements from all core layers; a generic role replaces business role and may receive assignment relationships from internal active structure elements from all core layers, not only the Business Layer.55
This is not merely a cleanup of names. It corrects a structural limitation. In ArchiMate 3.2, role was strongly associated with the Business Layer, and collaboration existed separately as business collaboration, application collaboration, and technology collaboration. That was consistent with the old layered structure, but it became increasingly artificial as enterprise systems became more mixed. Modern enterprise behavior is often performed by combinations of people, applications, platforms, infrastructure, devices, equipment, and external parties. A language that can only express collaboration inside one layer has difficulty representing that reality cleanly.
The first principle is simple: a role is not necessarily human. A role is a position, purpose, or responsibility in the execution of behavior. A human can fulfill a role, but so can an application component, a node, a device, system software, equipment, a facility, or a collaboration. The ArchiMate 4 Specification defines role exactly in this broader way: a role represents the position or purpose that a business actor, application component, node, device, system software, equipment, facility, or collaboration has in performing specific behavior.56
This definition is important because it separates three concepts that are often confused: actor, role, and accountability. An actor is an active structure element capable of performing behavior. A role is the purpose or responsibility that an actor, component, node, device, or collaboration has in a context. Accountability is a governance or legal notion that may or may not be represented by a role specialization. ArchiMate 4 gives a more flexible modeling structure, but it does not erase the difference between operational responsibility and legal accountability.
This distinction is especially important in the age of AI. The motivation white paper explicitly states that ArchiMate 4 permits the assignment of non human actors to roles, which is increasingly relevant with AI. It also warns that this does not imply machines should become legally accountable, because roles are used to model responsibility for performing tasks while responsibility and accountability are different notions.57 That warning should be taken seriously. An AI-powered claims analyzer may fulfill the role of automated claims assessor. It does not follow that the AI system is accountable for the decision in a legal, regulatory, or organizational sense.
This is a useful improvement because many contemporary architectures are full of non human role playing structures. An application component may act as system of record, policy decision point, policy enforcement point, orchestration engine, identity provider, data quality gate, pricing engine, fraud detection service, claims assessor, or recommendation engine. A node may act as hosting platform, integration gateway, broker, security boundary, observability collector, or control plane. Equipment may act as actuator, sensor, production unit, energy storage unit, controlled asset, or safety relevant device. A facility may act as regulated site, operational hub, data center, plant, warehouse, or customer contact point.
In ArchiMate 3.2, modelers could often represent these ideas, but the language did not provide the same clean, generic role concept across domains. In ArchiMate 4, the model can state that a component fulfills a role without pretending that the role is a human position. That is more precise. It reflects the fact that enterprise architecture increasingly assigns purpose and responsibility to socio-technical structures, not only to organizational units.
The policy decision point example in the specification is particularly telling. The ArchiMate 4 Specification gives examples in which a business actor is assigned to roles such as Requester or Approver, and an application component is assigned to roles such as Policy Enforcement Point or Policy Decision Point.58 This example is small but significant. It shows that role is now useful for security architecture, identity architecture, platform architecture, integration architecture, and governance architecture, not only for business process responsibility.
This also helps with modeling architecture patterns. In many architectures, the same structural element may play different roles in different contexts. A customer master application may be system of record for customer data, data provider for analytics, policy enforcement point for access decisions, and integration participant in onboarding. A cloud platform may be hosting environment, security boundary, deployment target, control plane, and cost center. A BESS plant component may be controlled asset, telemetry source, remote maintenance target, and safety critical equipment. Role allows the architect to model context dependent purpose without multiplying structural elements.
The generic role concept also improves separation between structure and responsibility. A business actor such as Supplier depicts an entity. The role Supplier depicts a responsibility or position that can be carried by different actors. The ArchiMate 4 Specification makes this distinction in the Business Domain by explaining that a generic business actor can depict an organizational entity, while a role depicts a responsibility; specific or generic business actors can then be assigned to carry those responsibilities.59 With the generic role, this distinction can be extended across technical and physical domains.
This matters for enterprise architecture because many organizational problems are responsibility problems disguised as system problems. Who owns the data? Who approves the exception? Which component enforces the policy? Which platform is the source of truth? Which external provider performs the monitoring role? Which facility is the operational control point? Which AI service performs first level classification? Which human role overrides the automated decision? Generic role gives the language a better way to express these questions.
Collaboration follows the same logic. The ArchiMate 4 Specification defines collaboration as a collection of business actors, application components, nodes, devices, system software, equipment, facilities, roles, and other collaborations that work together to perform collective behavior.60 This is much broader than the old layer-specific collaboration concepts. It can represent a collective structure that mixes humans, software, infrastructure, physical assets, and other collaborations.
This is necessary because many enterprise capabilities are not performed by one actor or one system. They are performed by ensembles. An incident response capability may involve security analysts, SIEM platforms, SOAR automation, endpoint agents, identity systems, firewall infrastructure, cloud services, and external responders. A claims handling capability may involve claims employees, automated claims assessors, document extraction services, policy systems, data objects, legal specialists, and customer communication channels. A plant maintenance capability may involve technicians, remote service providers, SCADA systems, diagnostic applications, network paths, equipment, spare parts, and facilities.
A layer-specific collaboration is too weak for these cases. It forces the architect to ask whether the collaboration is business, application, or technology collaboration. That question is often the wrong one. The correct question is: which active structures must work together to perform the behavior? ArchiMate 4 makes that question explicit.
This is also why generic collaboration is tightly connected to the merger of behavior elements. Once behavior is generic, collective performance also needs to be generic. A generic process can be assigned to a collaboration that includes a business actor, an application component, a node, and equipment. Without generic collaboration, the behavior merger would remain incomplete. The language could model a generic process, but it would not be able to model the mixed performer cleanly.
The motivation white paper identifies this limitation directly. It says that ArchiMate 3.2 could not easily define a process performed by a collaboration of active structure elements from different layers, such as a factory worker plus a robot or an office worker plus an AI assistant. It then explains that the new structure allows collaborative execution of behavior across layers, including combinations of human and machine.61 This is one of the most concrete reasons why collaboration had to become generic.
The AI claims example in the white paper illustrates the point. It shows an automated AI-powered application for analyzing insurance claims collaborating with human employees by fulfilling a role in a claim handling process. The automated claims assessor may adjudicate standard claims, but high risk claims require involvement of a senior specialist from the legal team.62 This example has several architectural facts: a non human structure fulfills a role, human and machine participants collaborate in a process, different claim types follow different responsibility patterns, and accountability cannot simply be assigned to the AI system. Generic role and generic collaboration are exactly the constructs needed to model this without distorting the architecture.
The same pattern appears outside AI. In Industry 4.0, a robot, a worker, an MES application, a PLC, a sensor, and production equipment may jointly perform a production or quality control process. In digital banking, a customer, mobile application, identity provider, fraud engine, core banking component, compliance team, and external data provider may jointly perform onboarding. In OT cybersecurity, a SOC analyst, jump host, firewall, remote vendor, asset inventory, SIEM, and control system may jointly perform controlled remote access or incident triage. None of these collaborations is purely business, application, or technology.
The architectural value of generic collaboration is therefore not that it makes diagrams nicer. It gives the model a place to represent a real operational unit of cooperation. This is essential for impact analysis. If only one application component is assigned to a process, the model may hide the human approval, infrastructure dependency, equipment participation, or external provider involvement. If a collaboration that aggregates all relevant active structures is assigned to the process, the model can expose the full dependency surface.
This also matters for resilience and risk. Collective behavior has failure modes that individual behavior does not. A collaboration can fail because one participant is unavailable, because a handoff is unclear, because a role is unassigned, because authority is ambiguous, because a technical interface fails, because data is not available, or because a human override path is missing. If the collaboration is explicit, these risks can be analyzed. If the collaboration is hidden behind a generic interaction or behind a single assigned component, they are harder to see.
Generic role and collaboration also improve modeling of outsourcing and ecosystems. Many enterprises no longer perform all behavior internally. External providers monitor systems, maintain platforms, host infrastructure, manage SOC operations, supply data, execute logistics, operate plants, and provide business services. A provider may be a business actor, but it may also provide application components, technology services, equipment, facilities, or operational teams. Roles and collaborations allow the architecture to show not only who the provider is, but what responsibility or purpose it fulfills in a given process or service chain.
This is especially relevant because the ArchiMate 4 Specification adopts a broad TOGAF aligned definition of enterprise, where an enterprise may span multiple organizations or an ecosystem. Enterprise architecture is therefore not limited to the legal boundary of one organization.63 Generic collaboration is consistent with that view. A collaboration may cross organizational, technical, and physical boundaries.
However, generic role and collaboration also create a governance obligation. If everything can play a role, the modeler must be clear about what kind of role is being modeled. Is it an operational role, an architectural role, a security role, a data governance role, a legal accountability role, a platform role, or a temporary execution role? ArchiMate allows specialization profiles for this reason. A generic role may need specializations such as Accountable Role, Responsible Role, Policy Enforcement Point, System of Record, Data Owner, Remote Maintenance Provider, Control Authority, or Automated Assessor.
This should not be left to ad hoc naming. A repository should define a controlled role taxonomy. Otherwise, role becomes a vague label attached to everything. The power of generic role is that it can model purpose across domains. The danger is that without governance, it becomes an uncontrolled synonym for something involved.
The same applies to collaboration. A collaboration should have a reason to exist. It should represent collective behavior that is architecturally meaningful. Not every set of elements in the same diagram is a collaboration. If the elements are grouped only because they are shown together, use grouping. If they jointly perform behavior, use collaboration. If they are co located, use location. If they form a product or plateau, use those composite elements where appropriate. This distinction is important because collaboration has behavioral implications, while grouping is a more general collection mechanism.
The ArchiMate 4 Specification helps with this distinction. It defines grouping as a collection of concepts that belong together based on some common characteristic, while collaboration is a collection of active structures and roles that work together to perform collective behavior.64 A security zone, project scope, domain boundary, or diagram cluster may be a grouping. A SOC response team with tools and platforms performing incident triage is a collaboration. Confusing the two weakens the model.
A practical modeling rule follows: use collaboration only when the collective has behavioral significance. If a set of elements only shares ownership, location, lifecycle, security classification, or portfolio scope, grouping or location may be more appropriate. If the set jointly performs a process or function, or jointly provides a service, collaboration is appropriate. This rule becomes more important in ArchiMate 4 because collaboration is now powerful enough to cross all core domains.
The generic role and collaboration changes also influence view design. In an old layered view, a role might appear only in the business part of the diagram. In ArchiMate 4, roles may appear wherever purpose or responsibility must be clarified. A platform architecture view may use roles to distinguish policy decision point, policy enforcement point, data provider, consumer, broker, and orchestrator. An OT architecture view may use roles to distinguish controlled equipment, remote service endpoint, monitoring agent, operator workstation, and safety function. A data architecture view may use roles to distinguish data owner, data steward, system of record, data processor, and data consumer.
This creates more expressive views, but also requires better legends and conventions. Stakeholders may still associate role with human job roles. The architect must explain that in ArchiMate 4, role is broader. It represents purpose in behavior, not necessarily a job position. In diagrams intended for non architect stakeholders, specialized names and clear labels become essential.
Migration from ArchiMate 3.2 also needs care. Business role becomes generic role. Business collaboration, application collaboration, and technology collaboration become generic collaboration, possibly with specialization profiles if the old domain classification is still useful. A mechanical migration may technically work, but it may lose stakeholder readability if all familiar yellow, blue, and green collaboration types become a single generic visual category. The migration should decide whether to preserve legacy specializations, replace them with more meaningful enterprise specific specializations, or rely entirely on relationships and views.
For example, an old business collaboration representing a claims team may become a generic collaboration specialized as Business Collaboration or simply remain a collaboration aggregating business actors and roles. An old application collaboration representing a group of application components may become a collaboration specialized as Application Collaboration, or it may be replaced by a more precise label such as Claims Processing Application Ensemble. An old technology collaboration representing infrastructure components may become a collaboration specialized as Technology Collaboration, or perhaps as Hosting Platform, Security Stack, or Edge Control Cluster. The best migration depends on the repository’s analytical needs.
The general rule is that old layer specializations should be preserved only if they still add value. ArchiMate 4 gives organizations the opportunity to replace inherited layer labels with more meaningful architectural roles and collaborations. Instead of preserving application collaboration forever, it may be better to specialize collaborations by architectural pattern: platform collaboration, integration collaboration, control collaboration, data processing collaboration, human machine collaboration, remote operations collaboration, or incident response collaboration.
This is where ArchiMate 4 becomes more useful than ArchiMate 3.2. The old language gave fixed layer based categories. The new language gives generic constructs that organizations can specialize according to actual architecture concerns. That is more flexible, but only if the specialization layer is governed.
There is also an analytical benefit. Queries can now ask more meaningful questions. Which processes are performed by collaborations containing both business actors and application components? Which roles are fulfilled by non human active structures? Which services depend on collaborations crossing organizational boundaries? Which roles are fulfilled by external providers? Which collaborations include equipment or facilities? Which AI components fulfill decision making or assessment roles? These questions are more aligned with modern architecture governance than simple counts of business collaborations or application collaborations.
This is especially important for risk, security, and compliance. A role fulfilled by an application component may require controls. A role fulfilled by an external provider may require contractual obligations. A role fulfilled by an AI component may require human oversight, auditability, explainability, or regulatory review. A collaboration crossing internal and external actors may require access controls and evidence collection. Generic role and collaboration make these structures visible, but the repository must be able to query and govern them.
The change also helps clarify responsibility patterns such as RACI, although ArchiMate does not become a RACI language. Role can express responsibility for performing behavior. Specializations or attributes can distinguish responsible, accountable, consulted, and informed where needed. The white paper’s caution about responsibility versus accountability suggests that a mature architecture practice should not overload the generic role concept. If accountability matters, define it explicitly as a specialization or attribute and constrain who or what may fulfill it.
This becomes crucial with non human actors. A system may be responsible for executing a task in the operational sense, but a human or organization must remain accountable in the governance sense. For example, an automated pricing engine may perform price calculation, but the pricing manager or regulated entity may remain accountable for pricing policy. An AI screening service may perform document classification, but the compliance officer may remain accountable for acceptance criteria. A SCADA component may perform control logic, but the operator or plant owner may remain accountable for operational decisions. ArchiMate 4 can represent this if roles are modeled carefully.
The generic role also connects well with architecture patterns and reference architectures. A reference architecture often defines abstract roles before selecting concrete products: identity provider, message broker, API gateway, data catalog, policy decision point, policy enforcement point, observability collector, secrets manager, configuration repository, digital twin, edge gateway, remote access broker. In ArchiMate 4, these can be modeled as roles fulfilled by concrete components or nodes. This keeps the reference architecture separate from implementation choices.
That separation is valuable. It lets architects define the required architectural purposes first and then map them to actual components. The model can say that the architecture needs a policy enforcement point, and later show whether that role is fulfilled by an API gateway, service mesh, firewall, application component, or identity proxy. This is better than forcing the purpose directly into a product or component name.
The same applies to collaboration patterns. A reference architecture may define a Remote Maintenance Collaboration composed of vendor role, owner authorization role, jump host, monitoring service, firewall, asset management system, and target equipment. Different sites may realize that collaboration with different concrete components. The collaboration expresses the architectural pattern, while the assigned elements express implementation.
This is why the generalization of role and collaboration is not just a convenience. It strengthens abstraction. It allows architecture to describe purposes and collective structures independently from specific organizations or products, while still being able to assign concrete performers. This is close to the core purpose of enterprise architecture: separating stable intent from variable implementation.
There is one further point. Generic collaboration makes it easier to model temporary or informal operational structures. The specification notes that a collaboration is possibly temporary and need not have official permanent status, unlike a department.65 This is highly relevant for project teams, incident response groups, transformation squads, cross functional product teams, supplier task forces, crisis cells, and temporary integration teams. Enterprise architecture often struggles to represent these because they are real enough to affect behavior but not always formal enough to appear in the organizational chart.
ArchiMate 4 can now model such structures without forcing them into business organization hierarchy. A temporary collaboration may be assigned to a process or function, provide a service, aggregate interfaces, and contain active structures from different domains. This is closer to how transformation and operations actually happen.
The same is true for platform teams and product teams. A product team may include business roles, application components, repositories, cloud environments, data products, and operating responsibilities. It is not merely a business actor, not merely an application collaboration, and not merely a technology collaboration. It is a socio-technical collaboration. ArchiMate 4 gives the language a better primitive for that reality.
The price remains the same as in the other ArchiMate 4 changes: the generic concept must be governed. Role and collaboration are now more powerful, but also easier to misuse. A weak model may assign roles to everything without explaining behavior, or create collaborations for arbitrary diagram clusters. A strong model will use roles to express purpose, collaborations to express collective performance, assignments to connect active structure to behavior, and specializations to distinguish responsibility from accountability where needed.
In summary, generic role and generic collaboration are not secondary consequences of the behavior merger. They are part of the same architectural correction. Behavior is no longer tied to a layer. Therefore the performer of behavior cannot be tied to a layer either. Enterprise systems are increasingly composed of humans, software, infrastructure, devices, equipment, facilities, and external parties working together. ArchiMate 4 gives a cleaner way to model that collective execution.
This makes ArchiMate 4 better suited to modern enterprise architecture, especially where AI, automation, platforms, operational technology, outsourcing, and cyber-physical systems are involved. But it also raises the standard for modeling discipline. A generic role must not become a vague label. A generic collaboration must not become a decorative grouping. Used correctly, they make responsibility and collective execution explicit. Used lazily, they hide exactly the complexity they were introduced to clarify.
A common misreading of ArchiMate 4 is that the removal of several elements means that the corresponding architectural concepts are no longer important. That is not the case. ArchiMate 4 removes some concepts from the primitive vocabulary of the language, but it does not necessarily remove the architectural ideas behind them. This distinction is essential. A concept can be removed as a standard element because it is redundant, unclear, rarely used, or better represented by a more fundamental concept. The underlying real world concern may remain valid.
The ArchiMate 4 Specification lists the removed elements explicitly: business interaction, application interaction, technology interaction, constraint, contract, gap, and representation. It then gives conversion guidance for ArchiMate 3.2 models: constraint can be replaced by a specialization of requirement; contract by a specialization of business object; gap by a specialization of assessment or deliverable; representation by a specialization of data object, artifact, or material; and business, application, and technology interactions by specializations of function or process.66
The motivation white paper frames the decision as language cleanup. It says that the deprecated concepts were removed to reduce clutter for most users, because such concepts increase the cognitive load of learning the language and add complexity without sufficient return. At the same time, it stresses that conversion paths are provided so that information from ArchiMate 3.2 models does not have to be lost.67
This is the right way to understand the change: ArchiMate 4 is not saying that contracts, constraints, gaps, representations, or interactions no longer exist in enterprise architecture. It is saying that they do not need to be first class primitive elements in the standard language. They can be represented more economically through existing concepts and specialization profiles.
This is a metamodel decision, not an architecture decision. Enterprise architecture still needs to model contractual obligations, design constraints, gap analysis, forms of information representation, and collective behavior. The question is whether each of these deserves a separate core language element. ArchiMate 4 answers no for these cases.
This answer is consistent with the broader direction of the language. The previous sections showed that ArchiMate 4 moves from layer-specific concepts toward generic concepts plus relationships. The same logic applies here. Instead of preserving a separate concept for every frequent architectural word, ArchiMate 4 asks whether the word denotes a truly fundamental concept or a specialization of something more general. If it is a specialization, it should not necessarily be part of the kernel.
This matters because enterprise architects often confuse vocabulary with ontology. The fact that a word is common in architecture practice does not automatically mean it should be a primitive element in a modeling language. Contract, constraint, gap, and representation are all useful words. But a modeling language must ask a stricter question: is this concept structurally independent, or is it a special case of another concept already present in the language?
The first removed element to consider is constraint. In ArchiMate 3.2, constraint existed as a motivation element. In ArchiMate 4, the official conversion is to replace it by a specialization of requirement.68 The motivation white paper explains why: constraint was already defined as a specialization of requirement in the metamodel, and the semantic difference between the two was often unclear because both represent a boundary on the design or implementation space.69
This is a strong argument. A requirement is a statement of need defining a property that applies to a specific system as described by the architecture. A constraint is usually a limitation or boundary that restricts possible solutions. But a limitation can be modeled as a required property. Personal data shall remain in the EU, the solution shall use an approved identity provider, the system shall not expose direct internet access to OT assets, the platform shall comply with a given regulation, and data shall be retained for ten years are all constraints in ordinary language, but they can be modeled as requirements in ArchiMate.
The white paper gives the example of a legal regulation such as GDPR and asks whether applying it is better modeled as a constraint or as a requirement on the architecture.70 This is exactly the kind of distinction that can consume modeling time without improving the model. If two modelers disagree on whether something is a constraint or a requirement, and both agree that it restricts the architecture, then the language distinction is probably not carrying enough value.
There is a deeper point. Many organizations already use multiple specializations of requirement: feature, user story, use case, business rule, non functional requirement, control requirement, regulatory requirement, security requirement, architecture decision constraint, and so on. The white paper notes that predefining one specialization, especially an unclear one, is not helpful for all users. Specialization profiles allow organizations to add the requirement specializations they need without overburdening the core language.71
This is the correct governance approach. If an enterprise wants to distinguish legal constraint, technical constraint, architecture principle derived requirement, business rule, or security control requirement, it should do so through a controlled profile catalog. But the standard does not need a separate primitive element called constraint. The enterprise needs the distinction only if it uses it consistently and analytically.
For example, a cybersecurity architecture practice may define requirement specializations such as Control Measure, Security Requirement, Regulatory Requirement, and Architectural Constraint. A data governance practice may define Data Residency Requirement, Retention Requirement, or Quality Rule. A product organization may define Feature or User Story. These are all meaningful, but they are not universal primitives. They belong in the specialization layer.
The second removed element is contract. ArchiMate 4 replaces contract with a specialization of business object.72 The white paper explains that contract was already a specialization of business object in the metamodel, and that its main use was in the context of product, where it represented the agreement between provider and consumer.73
This is also defensible from first principles. A contract is a business relevant passive element. It does not perform behavior. It can be created, read, modified, approved, signed, stored, referenced, enforced, or terminated by behavior. It may be realized by data objects or artifacts. It may be associated with products, services, parties, obligations, service levels, rights, penalties, and lifecycle events. In ArchiMate terms, that makes it naturally close to business object.
Removing contract as a primitive does not reduce the importance of contracts in enterprise architecture. In some industries, contracts are central: insurance policies, energy supply contracts, outsourcing agreements, cloud service agreements, software licenses, financial instruments, procurement contracts, operating agreements, and data processing agreements. But the architectural nature of contract is still that of a specialized business object.
The benefit of this reclassification is consistency. If contract remains a business object specialization, then it can be handled through the same passive structure patterns as other business objects. It can be accessed by processes or functions, realized by data objects, represented by artifacts, associated with value, linked to products, and governed through attributes. The concept becomes less exceptional and more integrated.
However, this also creates a repository governance requirement. An organization that uses contracts heavily should not simply rename all contracts to generic business objects. It should define a Contract specialization of business object and preserve relevant attributes: contract type, parties, validity period, obligations, rights, renewal rules, service levels, penalties, governing law, confidentiality, data processing role, termination conditions, and related product or service. The standard removes the primitive element, but the enterprise should preserve the semantic richness if that richness matters.
The third removed element is representation. This is the most subtle of the removed passive concepts because it touches the boundary between business meaning, logical data, physical artifacts, and material form. ArchiMate 4 says representation can be replaced by a specialization of data object, artifact, or material.74 The motivation white paper explains that representation was a leftover from the first version of the ArchiMate Specification, originally used for things like paper forms and letters representing a business object. It later started to be used for electronic means such as email messages and PDF files, where data object would often have been a better choice. With the addition of material in ArchiMate 3.0, physical representations of information on paper could also be modeled as material.75
This is an important modeling clarification. Representation is not one thing. It can mean a logical form of information, a physical file, a document artifact, a message, a paper form, a screen, a printed certificate, a PDF, an email, a database record, or a physical object carrying information. Treating all of these as one primitive element hides differences that may matter.
The right target depends on the architectural concern. If the concern is logical information structured for automated processing, data object may be appropriate. If the concern is a deployed or produced file, message, document, script, database table, or model file in an IT system, artifact may be appropriate. If the concern is physical matter carrying information, such as printed forms, labels, physical documents, or material used in logistics, material may be appropriate. In some business contexts, a business object or specialization may also be the better abstraction.
This is more precise than a generic representation element. For example, an insurance policy as a legal business concept may be a business object. The policy data record in the policy administration system may be a data object. The generated PDF policy document may be an artifact. The printed paper copy sent to a customer may be material. All of these may carry related meaning, but they are not the same architectural object.
The removal of representation therefore pushes modelers to decide what they actually mean. Is the concern semantic, logical, digital, deployable, physical, or communicative? ArchiMate 4 does not remove the ability to model representations. It removes the ability to avoid that decision by using a broad, ambiguous element.
The fourth removed element is gap. ArchiMate 4 replaces gap by a specialization of assessment or deliverable.76 The white paper is quite direct on this point: gap has always been a rather odd concept. It represented a statement of difference between two plateaus, but the difference between two plateaus can already be seen and analyzed through their relationships with other elements. The paper also notes that gap appeared in the bottom 10% of the usage analysis.77
This is an example where the removed concept was close to a modeling convenience rather than a fundamental architecture concept. A plateau represents a relatively stable state of the architecture during a limited period of time. If two plateaus contain or aggregate different elements, the difference between them can be computed, inspected, or described. A separate gap element may be useful as a narrative marker, but it is not always necessary as a first class concept.
The official replacement is sensible because gap can mean two different things. If gap means the analytical result of comparing current and target states, then assessment is the better concept. An assessment represents the result of an analysis of the state of affairs of the enterprise with respect to some driver. A gap analysis is exactly a kind of assessment. If gap means the document, output, or artifact produced by a gap analysis activity, then deliverable is the better concept. A deliverable represents a result of a work package.78
This distinction is practical. In transformation programs, people often say the gap ambiguously. They may mean the missing capability, the difference between baseline and target, the analysis document, the remediation work, the project scope, or the backlog. ArchiMate 4 forces a clearer model. If it is an analytical finding, model it as assessment. If it is an output of work, model it as deliverable. If it is work to be performed, model it as work package. If it is a desired property, model it as requirement. If it is a future stable state, model it as plateau.
This is a net gain. It reduces a word that often hides multiple meanings and pushes the architect to classify the architectural object more precisely. The removed gap element is not lost. It is decomposed into more meaningful concepts.
The fifth group of removed elements is interaction, already discussed in the previous section. Business interaction, application interaction, and technology interaction can be replaced by specializations of function or process.79 The same principle applies: collective behavior still exists, but it is better represented through process or function plus collaboration, assignment, multiplicity, and specialization. Interaction was not fundamental enough to remain a primitive.
These removals show a consistent pattern. ArchiMate 4 removes concepts when they fail one or more tests. Are they already specializations of existing concepts? Are they rarely used? Are they semantically unclear? Can they be represented more cleanly through a combination of generic concepts and relationships? Do they add cognitive load for most users without proportional benefit? Constraint, contract, gap, representation, and interaction all fail enough of these tests to be removed from the core language.
The change also reveals the role of specialization in ArchiMate 4. Specialization is not an afterthought. It is the mechanism that allows the language to remain small without becoming too generic. The ArchiMate 4 Specification explains that concrete concepts can be specialized, that specialized elements inherit the properties of the elements they specialize, and that specialized relationships are also allowed.80 This means removed elements can continue to exist as specializations where needed.
This is why the phrase removed elements are not lost concepts is accurate. The primitive language is smaller, but the modeling practice can preserve distinctions that are still useful. The difference is governance. In ArchiMate 3.2, every modeler had the contract, constraint, gap, representation, and interaction elements available by default. In ArchiMate 4, an organization must decide whether to keep them as specializations, replace them with more precise concepts, or eliminate them from its modeling standard.
This decision should not be automatic. A mature architecture practice should examine each removed concept in its existing repository and classify it. Some uses were probably precise and should be preserved as specializations. Some were ambiguous and should be refactored. Some were historical clutter and should be removed.
For constraint, the migration question is: does the enterprise need to preserve a distinction between constraints and requirements? If yes, define a specialization of requirement with a clear rule. If no, convert constraints to requirements and possibly use attributes for source, type, priority, and binding force.
For contract, the question is: are contracts architecturally important enough to deserve a controlled specialization of business object? In industries such as finance, insurance, energy, telecom, public sector, and outsourcing heavy environments, the answer is probably yes. In other contexts, generic business object may be sufficient.
For representation, the question is: what was the modeler actually representing? A message, a file, a document, a physical form, a screen, a database table, a business concept, or a material item? The migration should map each case to data object, artifact, material, or business object according to intent. A single automatic replacement would be risky.
For gap, the question is: was the gap an analysis result, a document, a missing architecture element, a work item, or a transformation objective? The migration should map it to assessment, deliverable, work package, requirement, or another concept accordingly. The official guidance gives assessment or deliverable as the main replacements, but real repositories may require more nuanced cleanup.
For interaction, the question is: was the interaction intended as ordered behavior, grouped behavior, or collective execution? The migration should map it to process, function, collaboration plus assignment, or specialization accordingly.
A practical repository policy can be expressed as follows.
| Removed ArchiMate 3.2 element | ArchiMate 4 target | Semantic test before migration | Recommended governance action |
|---|---|---|---|
| Constraint | Requirement specialization | Is the element a boundary, restriction, rule, or required property of the architecture? | Define controlled requirement specializations such as legal constraint, security requirement, business rule, or architecture constraint |
| Contract | Business object specialization | Is the element a business relevant agreement, obligation structure, policy instrument, or product related agreement? | Preserve as Contract specialization if contracts are analytically relevant; attach attributes for parties, validity, obligations, and service levels |
| Gap | Assessment or deliverable specialization | Is the element an analytical finding or the output document of a gap analysis? | Use assessment for the finding; use deliverable for the document; avoid using gap as a vague placeholder for missing work |
| Representation | Data object, artifact, material, or business object specialization | Is the element logical data, deployed digital artifact, physical carrier, or business information concept? | Map according to intent; avoid one-size-fits-all conversion |
| Business interaction | Process or function specialization | Is the interaction sequential behavior, grouped behavior, or collective performance? | Use process for sequence, function for grouping, collaboration and assignment for collective performance |
| Application interaction | Process or function specialization | Does the model represent application orchestration, functional grouping, or ordered behavior? | Preserve only if specialization adds analytical value |
| Technology interaction | Process or function specialization | Does the model represent technology behavior, infrastructure function, or collective technical execution? | Model through generic behavior and explicit active structure assignment |
This table is not only a migration aid. It expresses the philosophy of ArchiMate 4. The language wants fewer built in categories and more precise use of generic categories.
There is a risk, however. When elements are removed from the standard and replaced by specializations, semantic consistency moves from the standard to the enterprise. If each project defines its own Contract, Constraint, Representation, Gap, or Interaction profile, the repository will fragment. The model will remain formally ArchiMate compliant, but semantic interoperability will decline. This is the same general risk that appears in profile based modeling languages: the kernel is shared, but meaning migrates into local dialects.
Therefore, organizations adopting ArchiMate 4 should define a profile catalog. The catalog should specify each specialization, its parent concept, definition, allowed attributes, allowed relationships where stricter than the parent concept, icon or notation if used, examples, anti examples, and migration rule from ArchiMate 3.2. Without this catalog, the removed elements may reappear as uncontrolled stereotypes, which would reintroduce the same conceptual debt ArchiMate 4 is trying to reduce.
This is particularly important for regulated industries. A bank, insurer, utility, public agency, healthcare organization, or energy operator may need precise distinctions among legal obligations, regulatory requirements, technical constraints, operational controls, contractual commitments, and risk treatments. ArchiMate 4 can support those distinctions, but they should be modeled as governed specializations and attributes, not as informal labels.
The removal of elements also affects tool behavior. Tools that import ArchiMate 3.2 repositories into ArchiMate 4 should not simply replace removed concepts with generic targets without preserving traceability. The motivation white paper notes, in the context of behavior conversion, that specialization profiles can preserve the originating ArchiMate 3.2 layer information, and that future support in the ArchiMate Model Exchange File Format was expected for exchanging specialization profiles.81 The same migration logic applies to removed concepts. If a contract becomes a business object, the repository should preserve that it was formerly a contract, at least during transition.
From an architecture governance perspective, this is not optional. Existing models may have been used for reporting, impact analysis, transformation planning, regulatory mapping, and stakeholder communication. If removed elements are flattened without preserving meaning, the migration may be syntactically successful but semantically destructive.
The right migration process should therefore include at least four passes. First, inventory all removed elements. Second, classify their actual usage patterns. Third, map each usage pattern to the appropriate ArchiMate 4 concept or specialization. Fourth, validate that key reports, viewpoints, and impact analyses still work after migration.
This last point is critical. The success criterion is not the model opens in an ArchiMate 4 tool. The success criterion is the model still answers the questions it previously answered, and preferably answers them more cleanly. If a contract report, gap analysis view, requirement traceability report, product composition view, or transformation roadmap loses meaning, the migration is incomplete.
There is also an opportunity here. The migration can remove historical misuse. Some constraints may have been requirements. Some gaps may have been work packages. Some representations may have been data objects or artifacts. Some contracts may have been generic business objects with no contract specific attributes. Some interactions may have been processes. ArchiMate 4 gives organizations a reason to clean these up.
This is why the removed elements section should not be read defensively. The question is not how do we keep every old element under a new name? The question is which old distinctions were architecturally valuable, and which were accidental complexity? A good migration preserves the former and removes the latter.
The broader architectural implication is that ArchiMate 4 pushes the language toward a smaller ontological core. It does not deny domain-specificity. It relocates domain-specificity into the specialization layer. This is a sensible design if, and only if, the specialization layer is governed. Otherwise, the standard becomes cleaner while organizational modeling becomes messier.
In practical terms, removed elements are not lost concepts. They are demoted concepts. They move from standard primitives to optional specializations or more precise combinations of existing primitives. That is a healthy direction for a language whose stated objective is communication and adoption. But it transfers responsibility to the enterprise architect. The architect must decide which distinctions deserve preservation, which should be refactored, and which should disappear.
The final lesson is simple. ArchiMate 4 removes boxes, not concerns. Contracts, constraints, gaps, representations, and interactions still matter. What changes is that they must now be modeled with greater semantic discipline. If the concept is a requirement, model it as a requirement. If it is a business object, model it as a business object. If it is an assessment, model it as an assessment. If it is a deliverable, model it as a deliverable. If it is data, artifact, or material, choose the right passive structure. If it is collective behavior, model the behavior and the collaboration explicitly.
That is the essence of the change. ArchiMate 4 is not making enterprise architecture less expressive. It is asking modelers to express meaning through better primitives.
The relocation of path into the Common Domain is less visible than the merger of behavior elements, but it is architecturally important. It shows that ArchiMate 4 is not only simplifying behavior. It is also generalizing the way the language represents exchange, connectivity, and logical dependency across the enterprise. A path is no longer mainly a technology oriented connector. It becomes a common concept that can connect active structures across business, application, technology, and physical contexts.
The ArchiMate 4 Specification lists this explicitly among the changes from ArchiMate 3.2: path is now part of the Common Domain, and aggregation from path to technology internal active structure element has been replaced by realization from active structure element to path.82 This is a compact sentence, but it contains two different changes. First, path is reclassified as common rather than technology specific. Second, the relation between a logical path and the structures that implement it is corrected: physical or active structures realize the path, rather than being aggregated by it.
The first principle is that a path is logical. It is not the same thing as a cable, a network, a railway, a road, a VPN, a firewall rule, a message broker, a fiber link, or a power line. Those may realize or support a path. The path itself represents the fact that two or more active structures are connected by a logical exchange relation. ArchiMate 4 defines path as a logical link between business actors, application components, nodes, devices, system software, equipment, facilities, roles, and collaborations, through which these elements can exchange information, data, energy, or material.83
%%{init: {"theme": "neo", "look": "forest"}}%%
flowchart LR
subgraph COMMON["Common Domain"]
P["Path<br/>logical link for exchange of<br/>information, data, energy, or material"]
end
subgraph ENDPOINTS["Active structures connected by the path"]
BA["Business Actor"]
R["Role"]
AC["Application Component"]
N["Node / Device / System Software"]
EQ["Equipment / Facility"]
COL["Collaboration"]
end
BA ---|"associated with"| P
R ---|"associated with"| P
AC ---|"associated with"| P
N ---|"associated with"| P
EQ ---|"associated with"| P
COL ---|"associated with"| P
subgraph REALIZATION["Realization of the logical path"]
CN["Communication Network<br/>IT structures for transmission,<br/>routing, and reception of data"]
DN["Distribution Network<br/>physical network for transporting<br/>material or energy"]
AS["Other active structure elements<br/>on which the path relies"]
end
CN -->|"realizes"| P
DN -->|"realizes"| P
AS -->|"realizes"| P
NOTE["Modeling rule:<br/>Path is the logical link.<br/>Communication and distribution networks<br/>are physical realizations of that path.<br/>Flow represents actual transfer."]
NOTE -. "clarifies" .-> P
This definition is broader than traditional IT connectivity. It includes information and data, but also energy and material. It connects not only devices and nodes, but also business actors, application components, equipment, facilities, roles, and collaborations. This is why moving path into the Common Domain is coherent with the rest of ArchiMate 4. Once the language recognizes that behavior, role, and collaboration can cut across domains, the logical exchange relation among active structures must also cut across domains.
The earlier technology centered reading of path was too narrow. In many enterprise models, a path was naturally interpreted as something close to a communication path or technology connectivity construct. That was understandable historically. The ArchiMate change history notes that in the transition to earlier versions, communication path had already been renamed to path and its meaning had been extended to integrate with physical elements.84 ArchiMate 4 completes this direction by placing path where it belongs: among common concepts.
This matters because enterprise architecture is full of logical exchange paths that are not purely technical networks. A remote maintenance path connects a service provider, an authorization role, a jump host, monitoring tools, plant systems, and controlled equipment. A customer onboarding path connects a customer, a mobile application, an identity service, a document processing component, a compliance role, and a core system. A logistics path connects suppliers, warehouses, transport providers, facilities, materials, and business processes. An energy dispatch path connects market operators, EMS platforms, control systems, batteries, grid connection assets, and external signals. Reducing all of these to technology communication loses architectural meaning.
The specification makes the logical versus physical distinction explicit in the Technology Domain. It says that path models the relation between two or more internal active structure elements through which they can exchange information, and that a path may be realized by one or more communication networks or distribution networks, and by other active structure elements that model the people and technology on which the path relies. A communication network is the physical communication medium between devices or networks, while a distribution network is a medium for the distribution or transportation of physical materials or energy, such as rail or road networks, water supply, power grid, or gas network.85
This is one of the most useful clarifications for architecture practice. The path is not the implementation. The path is the logical dependency. The communication network or distribution network is one possible physical realization. This distinction is exactly what enterprise architects need when they must separate stable architecture intent from variable implementation details.
For example, an enterprise may require a Remote Diagnostics Path between a vendor support collaboration and plant equipment. At one site, this path may be realized by an MPLS connection, a firewall, a jump host, and a site network. At another site, it may be realized by a private APN, LTE backup, VPN concentrator, and segmented OT network. At a third site, it may be temporarily unavailable or realized through an emergency access process. The logical path can be the same architectural need, while the realization differs across sites.
This is not only a notation issue. It is a governance issue. If the model confuses the path with its realization, then architecture governance becomes brittle. A change in physical technology appears to change the logical architecture, even when the logical dependency remains unchanged. Conversely, a logical access dependency may remain hidden because the model only shows physical devices. By separating path from its realization, ArchiMate 4 supports cleaner impact analysis.
The change from aggregation to realization is also important. In ArchiMate 3.2, if a path aggregated technology internal active structure elements, the visual implication could be that those active structures were parts of the path. That is often the wrong semantics. A firewall, router, switch, gateway, device, system software component, facility, or piece of equipment is not usually a part of the logical path in the same sense that a component is part of an aggregate. Rather, those structures implement, enable, or realize the logical exchange relation.
ArchiMate 4 therefore replaces aggregation from path to technology internal active structure element with realization from active structure element to path.86 This is a better abstraction. A concrete or active structure realizes a more abstract logical path. The logical path specifies the required exchange relation. The active structures make it possible.
This mirrors the broader ArchiMate distinction between abstract and concrete architecture. The specification explains that realization indicates that more tangible elements realize more abstract elements, and it is used to relate logical or abstract elements to concrete or physical elements in several domains.87 Applying realization to path is therefore semantically consistent. The path is the abstract logical connection. The active structures are the implementation mechanisms.
This is especially relevant in network and infrastructure architecture. Architects often need to distinguish several layers of connectivity: business communication dependency, application integration dependency, logical path, protocol endpoint, communication network, physical circuit, routing domain, security zone, firewall policy, and device topology. ArchiMate cannot and should not replace detailed network design tools, but it can represent the architectural dependency. The path concept is the right place to do that.
Consider a data exchange between an ERP system and a CMMS. At a technical level, there may be DNS resolution, TLS, SNI, reverse proxy routing, firewall rules, containers, certificates, SOAP endpoints, retry behavior, and monitoring. At the enterprise architecture level, the key fact may be that the ERP application component and the CMMS application component require a logical integration path. That path may be realized by application interfaces, system software, a communication network, and deployment infrastructure. If the model jumps directly to devices and protocols, it may obscure the architectural dependency. If it models only an application flow, it may hide the infrastructure realization. Path provides the intermediate abstraction.
The same applies to OT. In a plant architecture, a path may connect remote service roles, monitoring systems, DMZ components, jump hosts, SCADA systems, BMS, EMS, protection devices, and equipment. The physical realization may include communication networks, segmented VLANs, firewalls, serial gateways, radio links, LTE routers, fiber links, and distribution networks. The path expresses the permitted or required logical exchange. The realization expresses how it is built.
This is useful for cybersecurity because a path can be governed. A path can be authorized, forbidden, monitored, time bounded, segmented, inspected, logged, or associated with requirements. The architecture can state that a remote maintenance path exists only through an approved boundary, not directly to equipment. The implementation can then show which devices, software, and networks realize that path. If the realization changes, the path governance remains clear.
The same distinction helps with zero trust and policy based architectures. A business role, an application component, and a policy enforcement point may participate in a logical access path. The realization may involve identity providers, gateways, service mesh sidecars, network policies, device posture checks, and audit systems. Modeling only the technical components can lose the architectural intent. Modeling only the user journey can lose enforcement. A path plus realization structure connects the two.
Path also matters for physical and cyber-physical enterprises. The Technology Domain in ArchiMate 4 includes both information technology and operational or physical technology. Facilities, equipment, material, communication networks, and distribution networks all belong to this broader technological reality. The motivation white paper explains that the Technology Domain still looks relatively rich because it must cover both IT and physical technology, bits and atoms, and because physical technology concepts matter for operational resilience, Industry 4.0, robotization, digital twins, and sectors such as defense.88
In that context, path cannot be reduced to data communication. A logistics path may concern material. An energy path may concern electricity. A production path may concern semi finished goods. A control path may concern command and telemetry. A safety path may concern signals between equipment and control systems. A business path may concern information exchanged between roles. A path concept that supports data, energy, and material is much better aligned with cyber-physical architecture.
This also helps explain the distinction between path, communication network, and distribution network. A communication network represents a set of IT structures for transmission, routing, and reception of data. A distribution network represents a physical network used to transport materials or energy.89 A path is more abstract than both. It is the logical relation that can be realized by one or more communication or distribution networks, or by other active structures.
This is not merely a three level hierarchy. It is a separation of concerns. Path answers: which active structures need to exchange something? Communication network answers: what data transmission infrastructure realizes or supports that exchange? Distribution network answers: what physical distribution infrastructure realizes or supports the movement of material or energy? This separation is essential for mixed architectures where information, control, energy, and material flows interact.
For example, a smart grid architecture may include a logical path for dispatch instructions, a communication network for data transmission, and a distribution network for electricity. These are connected but not identical. A failure in the communication path may prevent control. A failure in the distribution network may prevent energy delivery. A failure in the business process may prevent valid dispatch instructions. Modeling everything as one network would hide the differences.
A manufacturing example shows the same point. A production cell may have a material path for components moving through equipment, a control path for commands from a PLC or MES, a data path for quality measurements, and a maintenance path for remote diagnostics. Some are realized by conveyors or physical equipment, some by industrial networks, some by applications, some by procedures and roles. ArchiMate 4’s path concept is broad enough to express these logical dependencies without forcing them into a single technical category.
The relocation of path into the Common Domain also affects viewpoint design. In older models, path may have appeared mainly in technology or infrastructure views. In ArchiMate 4, path can appear in business, application, technology, operational, security, supply chain, and cyber-physical views whenever logical exchange is central to the concern. This does not mean every diagram should include paths. It means that paths are no longer conceptually confined to infrastructure.
A capability dependency view may use paths to show logical exchange among organizational roles or collaborations. An application cooperation view may use paths to distinguish stable integration dependencies from individual flows. A physical view may use paths to show logical material or energy exchange between facilities and equipment. A security view may use paths to show permitted access routes across zones. An OT architecture view may use paths to show controlled conduits without prematurely specifying every device.
The distinction between path and flow is also important. A path is a structural relation, a logical link through which exchange can occur. A flow relationship represents transfer from one element to another.90 The path is the channel or logical connection. The flow is the transfer. In ordinary language, people often mix these. In architecture models, separating them is valuable. A path can exist even when no current transfer is being modeled. A flow can occur over or through a path, but the flow is dynamic while the path is structural.
For example, Customer Data Exchange Path may connect a CRM application and an analytics platform. A specific daily extract of customer records is a flow. A real time consent update is another flow. A data quality alert may be another flow. The path expresses the logical connectivity. The flows express transfers. This distinction helps avoid overloading arrows in diagrams.
There is also a distinction between path and serving. Serving expresses that an element provides its functionality to another element. Path expresses a logical link through which exchange can occur. A service may be provided over a path, but a path is not itself the service. An API gateway may provide an authentication service to an application. The communication path between the application and the gateway is a different concept. Confusing serving with path leads to diagrams where dependency, functionality, and connectivity are all represented by the same arrow. ArchiMate 4 gives distinct primitives for these concerns.
The migration implication is narrow but important. If an ArchiMate 3.2 model contains aggregation from path to technology internal active structure elements, ArchiMate 4 says this may be replaced by realization from the technology active structure element to the path.91 This should not be treated as a purely mechanical arrow reversal. The migration team should verify what the original model intended. Was the path meant as a logical communication path? Were the aggregated elements devices realizing it? Was the path being misused as a network container? Should some elements instead be part of a communication network or grouping?
This review matters because old models may have used path as a physical network placeholder. If so, migration is an opportunity to correct the abstraction. The physical network should be modeled as communication network or distribution network where appropriate. The path should be kept for the logical exchange relation. Devices, system software, equipment, or facilities may then realize or participate in the path according to the intended meaning.
The same rule applies to diagrams that use path as a visual connector between application components without specifying interfaces or services. A path may be valid, but architects should ask whether the relation is really a path, a flow, a serving relation, an association, or an interface based dependency. Path should not become the generic line for connected somehow. Its definition is specific: a logical link for exchange of information, data, energy, or material.
This is one of the main governance risks. Because path is generic, it may be overused. Modelers may draw paths whenever two things are connected. That would weaken the model. A path should be used when the logical exchange relation itself is architecturally relevant. If the relevant fact is service dependency, use serving. If the relevant fact is actual transfer, use flow. If the relevant fact is implementation or abstraction, use realization. If the relevant fact is containment, use aggregation or composition. If the relation is unspecified, use association, but recognize that association is weak.
A mature repository should define path usage rules. For example, a path should have an exchange type: information, data, energy, material, control, telemetry, logistics, or communication. A path should identify connected active structures. Where the realization matters, the model should show the communication network, distribution network, devices, system software, facilities, equipment, or other active structures realizing it. Where security matters, the path should be associated with requirements, controls, zones, or access policies. Where operational resilience matters, the path should have redundancy, availability, ownership, and monitoring attributes.
This is especially useful in multi site architectures. Suppose an enterprise has many plants, warehouses, data centers, branches, or cloud regions. A standard logical path can be defined once as part of a reference architecture, and each site can realize it differently. This lets the enterprise compare sites: which logical paths are required, which are implemented, which are missing, which have non standard realization, and which violate security rules. Path becomes a bridge between reference architecture and implementation evidence.
In architecture governance, this is much more powerful than a static network diagram. A network diagram may show devices and links. A path model shows why the connectivity exists and what enterprise dependency it supports. The two should be connected, not confused. ArchiMate 4’s path change supports that separation.
The relocation of path also supports analysis of forbidden paths. In security and resilience work, architecture is not only about what should connect. It is also about what should not connect. A model may define approved logical paths and then compare them against observed network flows, IAM relationships, API calls, or data lineage. Any observed exchange without an approved path becomes an architectural drift signal. This is where ArchiMate can connect to operational evidence: the model contains intended paths; telemetry shows actual paths.
This is one of the strongest future uses of the concept. Path can become a governance object, not merely a visual line. It can represent allowed remote access routes, approved data exchange patterns, sanctioned supplier connectivity, permitted OT conduits, authorized control paths, and required material or energy routes. If connected to evidence, it can support conformance checking.
The change also aligns with the broader move away from hierarchical layers. In a layered mindset, connectivity tends to run vertically: business uses application, application uses technology. In a domain mindset, exchange can run across many kinds of active structures. A business actor may exchange information with another business actor. An application component may exchange data with another application component. Equipment may exchange material with equipment or facilities. A node may exchange data with a device. A collaboration may exchange information with another collaboration. Path belongs in the Common Domain because exchange is not owned by one layer.
This is also why path and collaboration complement each other. Collaboration models active structures working together to perform collective behavior. Path models the logical link through which active structures exchange something. A collaboration may rely on paths. A path may connect participants in a collaboration. For example, a remote operations collaboration may include owner roles, vendor roles, applications, jump hosts, and equipment; paths show the permitted logical exchanges among them. The collaboration explains collective execution. The paths explain exchange topology.
Path and role also complement each other. A role may define a purpose such as Monitoring Agent, Remote Service Endpoint, Policy Enforcement Point, or Control System. A path may connect those roles or the active structures fulfilling them. This allows reference architectures to be modeled at a logical level before concrete technologies are selected. Later, devices, applications, networks, and facilities realize those paths.
In physical technology, path also helps avoid over modeling. The motivation white paper notes that technology architects often want more concrete concepts, while the language must strike a balance and remain abstract enough for broad use.92 Path supports that balance. It can represent the logical connection without requiring the modeler to list every switch, router, pipe, road, conveyor, feeder, or cable. Detailed engineering tools can handle that level. ArchiMate should represent the architectural dependency.
However, in critical infrastructure, the boundary between logical path and physical realization must be handled carefully. Sometimes the physical route is architecturally significant because of redundancy, safety, regulatory compliance, attack surface, or operational resilience. In those cases, the model should include communication networks, distribution networks, facilities, and equipment. Path should not be used to hide critical physical topology. It should be used to separate the logical dependency from the physical realization, not to erase the latter.
For example, in a BESS or utility plant, it may be insufficient to model only DSO Communication Path or Remote Service Path. The architecture may also need to show primary and secondary telecom links, routers, firewalls, jump hosts, RTUs, SCADA, EMS, BMS, protection systems, and site facilities. The path gives the logical intent. The realization shows the enforceable architecture. Both are needed when resilience and cybersecurity are central.
This is where the ArchiMate 4 change can improve OT modeling. In OT, conduits, zones, interfaces, and control paths are often more important than application inventories. A path can represent the logical conduit or exchange route, while technology elements realize it. This makes it easier to separate there is an authorized remote diagnostic path from this path is currently realized by these firewalls, routers, VPN concentrators, jump hosts, and network segments.
A similar principle applies to data architecture. A path can represent approved data exchange between data producers, data consumers, and processing components. It should not replace data lineage, but it can represent the architectural connectivity that data lineage instantiates. A data lineage tool may show actual flows at table, file, API, or pipeline level. ArchiMate can show the intended path at enterprise architecture level. The two can be compared.
This illustrates again the future role of ArchiMate. The model should not try to contain every runtime connection. It should define the intended logical exchange structure. Runtime telemetry, network flows, API logs, data lineage, and IAM graphs can then test whether reality conforms to that intended structure. The path concept is a natural anchor for this kind of comparison.
In conclusion, moving path into the Common Domain is not a minor editorial change. It is part of the same conceptual cleanup that drives ArchiMate 4 as a whole. It removes a technology bias from the idea of connectivity. It clarifies that exchange can concern information, data, energy, or material. It separates logical dependency from physical realization. It supports cyber-physical, OT, logistics, platform, data, security, and ecosystem modeling. It also improves migration from layer based thinking to domain based thinking.
The practical recommendation is to treat path as a logical architecture object. Do not use it as a generic connector. Do not confuse it with flow, serving, association, or communication network. Use it when the exchange relation itself matters. Then, where needed, show how active structures, communication networks, distribution networks, facilities, equipment, devices, or system software realize that path.
The value of the change is that ArchiMate 4 can now model enterprise connectivity without forcing it into a technology only frame. That is essential for modern enterprise architecture, where the most important paths often cross humans, applications, infrastructure, physical assets, suppliers, energy systems, materials, and governance controls.
Multiplicity is the most compact but perhaps the most structurally significant new feature introduced by ArchiMate 4. Unlike the changes discussed so far, it does not remove concepts, merge concepts, or move concepts into the Common Domain. It adds a new expressive capacity to the language. Relationships can now carry constraints about how many instances may participate at each end of the relationship.
The ArchiMate 4 Specification defines this in Section 5.6. All relationships can have, on each end, an attribute specifying how many instances are allowed at that end, except when the relationship is connected to a junction. The notation follows the familiar cardinality style: a single positive integer n means exactly n instances, * is equivalent to 0..*, and n..m means any number of instances from n to m. The specification also states that this notation can indicate whether participation is optional or mandatory.93
This looks simple. It is not. Multiplicity introduces a limited but important form of constraint modeling into ArchiMate relationships. Until now, ArchiMate relationships mostly said that two concepts were connected in a certain way: one element realizes another, serves another, accesses another, is assigned to another, aggregates another, triggers another, or flows to another. With multiplicity, a relationship can also say something about required, allowed, optional, or repeated participation.
This is a different kind of statement. A normal relationship says that a dependency exists. A multiplicity annotated relationship says that the dependency has a structural constraint. It is not only this service is realized by a process. It can become this service must be realized by at least one process. It is not only this cluster aggregates servers. It can become this cluster contains exactly three server instances or at least two server instances. It is not only this event triggers a process. It can become one event may start multiple process instances.
The Open Group motivation white paper calls multiplicity on relationships the most important new feature. It explains that the immediate motivation came mainly from Data Architects needing to model the structure and constraints of data models in more detail, but it also lists other use cases: multiple process instances started from a single triggering event, a specific number of servers being part of a cluster, and mandatory relationships such as every service being realized by at least one process.94
This is important because it shows that multiplicity was not introduced as a decorative feature. It answers a recurring gap in architectural modeling: many architectural rules are not about the existence of a relationship only, but about its cardinality. Enterprise architecture often needs to express minimums, maximums, optionality, redundancy, uniqueness, mandatory ownership, and required participation. Before ArchiMate 4, those rules were usually expressed informally in text, profiles, naming conventions, tables, or external governance documents. ArchiMate 4 allows some of them to be expressed directly on relationships.
The first principle is that multiplicity belongs to relationships, not to isolated elements. This is a critical point. A model element such as Application Component, Service, Data Object, Role, or Node does not have meaningful multiplicity by itself. Multiplicity appears when the element participates in a relation. The same data object may have exactly one accountable owner, one or more stewards, zero or more consuming applications, and many physical artifacts realizing it. The cardinality differs by relationship type and architectural concern.
This makes multiplicity more precise than a simple attribute on the element. If an attribute says critical application: redundant, the meaning is loose. If a realization, assignment, serving, or aggregation relationship says that at least two independent elements must participate, the model becomes structurally explicit. It can be validated, queried, and compared against implementation evidence more easily.
Multiplicity also sits at an interesting boundary in ArchiMate’s abstraction philosophy. The specification states that ArchiMate intentionally does not support a general distinction between types and instances. Enterprise architecture normally models types, categories, or exemplars rather than every individual runtime instance. However, the multiplicity section explicitly says that, even without a full type and instance distinction, the language can express constraints put on the instances of elements.95
This is a subtle but powerful compromise. ArchiMate does not become an instance modeling language. It does not try to enumerate every process execution, server, document, customer, event, or data record. But it can now express architectural constraints about possible or required instances. In other words, multiplicity lets the model remain at architecture level while still saying something about how many real world instances are allowed, required, or expected.
This is why the feature is especially useful for reference architectures. A reference architecture often does not name all concrete instances. It defines patterns and constraints. A critical service must have at least two independent realizations. A regulated data object must have exactly one accountable owner. A cluster must contain at least three nodes. A remote access path must pass through one controlled access point. A customer account may be associated with zero or more authorized users. A deployment unit may be assigned to one or more runtime environments. Multiplicity allows these statements to be made as part of the architectural model rather than as prose outside the model.
However, this also creates a risk. Multiplicity makes ArchiMate look more like UML or logical data modeling. The motivation white paper explicitly says that the notation takes basically the same form as in UML.96 That similarity is useful, because many architects and data modelers already understand cardinality notation. But it is also dangerous, because it may tempt modelers to use ArchiMate as if it were a UML class diagram, an entity relationship model, or a database schema notation.
That would be a mistake. ArchiMate remains an Enterprise Architecture language. Its purpose is not to replace detailed data modeling, software design, process execution modeling, or infrastructure engineering. Multiplicity should therefore be used where cardinality is architecturally relevant, not wherever cardinality exists. Almost every real system has cardinalities. Only some of them matter at enterprise architecture level.
A good test is this: would the cardinality change an architecture decision, governance rule, risk assessment, investment decision, migration plan, or compliance conclusion? If yes, it may belong in ArchiMate. If no, it probably belongs in a more detailed model or implementation artifact.
For data architecture, multiplicity is useful when it expresses enterprise level data constraints. For example, a business object such as Customer may be realized by one authoritative data object in a master data architecture. A regulated data object may require exactly one accountable data owner role and one or more steward roles. A data product may serve many consuming capabilities, but each consuming capability may require at least one approved data contract. These are enterprise governance facts. They are not merely table design details.
By contrast, the fact that a database table has one to many rows in a child table is usually not an ArchiMate concern. That belongs in a logical or physical data model. ArchiMate can point to the existence of the data object, its ownership, its realization, its use by applications, and its architectural constraints. It should not become the schema.
For application architecture, multiplicity can express architectural redundancy, dependency, and exposure rules. A critical application service may need to be realized by at least two application components or deployed in at least two locations. An application component may be required to expose exactly one approved external interface for a certain service. A legacy application may be served by zero or more integration adapters during transition, while the target application must be served by exactly one strategic integration platform. These are not implementation details if they influence resilience, standardization, or migration governance.
For technology architecture, multiplicity can express availability and capacity patterns. A logical cluster may aggregate exactly three server instances. A production environment may require at least two availability zones. A gateway pattern may require one active and one standby node. A critical network path may require two physically independent communication networks. A control system may require exactly one authoritative time synchronization service. Again, these are architectural constraints when they define target patterns, resilience requirements, or acceptance criteria.
For process architecture, multiplicity can express how behavior instances relate to triggers or participants. The motivation white paper explicitly mentions multiple process instances started from a single triggering event.97 A single order received event may trigger one or more fulfillment processes. A single incident detected event may trigger one triage process and zero or more containment processes. A single market signal may trigger many site level optimization processes. These statements can matter when the architecture needs to reason about scaling, orchestration, workload, or control behavior.
For responsibility modeling, multiplicity can make ownership rules explicit. A critical business object may have exactly one accountable owner role. A service may have exactly one service owner and one or more operational support roles. A process may require at least one assigned performer. A collaboration may aggregate two or more participants. These constraints are often hidden in governance documents, but they are fundamental for operating models. Multiplicity gives the architecture repository a way to express them structurally.
This is also connected to the removal of interaction elements. The motivation white paper explains that if interactions were process like, their only differentiating property was that they had to be performed by more than one active structure element. With multiplicity, this can be modeled more simply and flexibly, for example by requiring 2..* assigned active structure elements for a process.98 This is a good example of ArchiMate 4’s design philosophy: remove a weak primitive and replace its useful meaning with a more general mechanism.
Multiplicity also helps distinguish optionality from incompleteness. Without multiplicity, the absence of a relationship in a model can be ambiguous. Does it mean the relationship is optional? Unknown? Not yet modeled? Not applicable? With multiplicity, the model can express that zero or more consumers are allowed, exactly one owner is mandatory, or at least one realization must exist. This does not solve all incompleteness problems, but it gives architects a more precise language for architectural rules.
The difference between optional and mandatory participation is especially important. The specification states that multiplicity can indicate optional participation when the lower bound is zero, or mandatory participation when the lower bound is positive.99 This means that 0..1, 0..*, 1, 1..*, and 2..* are not just mathematical annotations. They express governance meaning. They say whether the architecture permits absence, requires presence, or requires multiple participants.
This can support validation. If an architecture standard says that every application service must be realized by at least one process or function, then a repository can check for services without realization. If every critical data object must have exactly one accountable owner, a repository can detect missing or multiple accountable owners. If every production application must be deployed in at least two locations, a repository can detect single location deployments. Multiplicity turns some architecture principles into checkable model constraints.
This is one of the reasons the feature matters beyond diagrams. It pushes ArchiMate repositories toward computational governance. A diagram can show multiplicity, but a repository can query it. A tool can validate it. A migration assessment can compare it with actual implementation evidence. An operational dashboard can report exceptions. A control framework can link multiplicity constraints to compliance checks.
This is where ArchiMate 4 becomes more relevant to future enterprise architecture. The article’s broader argument is that architecture cannot remain a set of static diagrams. It must become a governed semantic layer connected to operational evidence. Multiplicity supports this shift because it expresses constraints that can be checked. A model with typed relationships and multiplicity is closer to a knowledge graph with rules than to a drawing.
However, multiplicity is not enforcement. This distinction is essential. A multiplicity annotation says what the architecture model asserts or requires. It does not guarantee that the implemented system conforms. If a service is modeled as requiring at least two realizations, the runtime platform may still have only one. If a data object is modeled as having exactly one accountable owner, the organization may still have no real owner. If a remote access path is modeled as requiring one approved boundary, network flows may reveal bypass paths. Multiplicity expresses intent or constraint. Evidence must verify it.
This means multiplicity should be connected to controls. For example, an architectural multiplicity rule that critical services must have at least two independent realizations should be linked to deployment evidence, cloud inventory, resilience testing, or service catalog data. A rule that each regulated data object must have exactly one accountable owner should be linked to data governance tooling. A rule that every remote access path must be realized by approved boundary components should be linked to network inventory and flow monitoring. Without this connection, multiplicity remains a modeling assertion.
There is also a semantic danger in using multiplicity without defining what counts as an instance. ArchiMate intentionally avoids a full type and instance distinction. If a model says that a cluster has 3 servers, does it mean three physical servers, three virtual machines, three logical server roles, three nodes of a product type, or three instances in production? The answer depends on modeling conventions. Without conventions, multiplicity can create false precision.
Therefore, every use of multiplicity should be interpreted relative to the abstraction level of the model. If Server is modeled as a type, then 3 may mean three instances of that server type. If Server Cluster is modeled as an exemplar architecture pattern, 3 may mean the required cluster size. If the model is site specific, 3 may mean the actual number of deployed nodes. These are different meanings. The model must make the abstraction level clear.
This is especially important in cloud architecture. A multiplicity of 2..* on locations could mean two cloud regions, two availability zones, two edge sites, or two deployment environments. A multiplicity of 1..* on nodes could mean one or more logical runtime platforms, not necessarily individual virtual machines or containers. Since cloud resources are elastic and ephemeral, ArchiMate multiplicity should normally express architectural minimums, patterns, or constraints, not the live count of runtime instances unless the model is explicitly operational.
The same caution applies to processes. A single event may trigger many process instances, but ArchiMate is not an execution engine. If precise execution cardinality, branching, joining, token semantics, and runtime conditions matter, BPMN or another process execution notation is more appropriate. ArchiMate can express the enterprise level constraint, but it should not absorb detailed operational semantics.
Multiplicity also interacts with junctions. The specification explicitly excludes relationship ends connected to junctions from multiplicity.100 This is logical. Junctions already represent compound relationship logic such as and or or combinations. Adding cardinality to those ends could create confusing semantics. If the architect needs both logical combination and cardinality, the model should be refactored carefully, usually by making the participating elements or collaborations explicit rather than overloading a junction.
Another important point is that multiplicity applies to all relationships, but that does not mean it is equally useful on all relationship types. On structural relationships, it can express composition, aggregation, assignment, or realization constraints. On dependency relationships, it can express serving or access participation. On dynamic relationships, it can express possible process instance or event related cardinalities. On association, it may be less precise because association is already semantically weak. Adding multiplicity to an ambiguous association can create formal looking ambiguity. In general, multiplicity is most valuable when the relationship type itself is semantically strong.
For example, 1..* on realization can mean that at least one concrete element must realize an abstract one. 1 on assignment can mean exactly one active structure is assigned to a role or behavior, depending on the direction and modeling convention. 2..* on aggregation can mean a collaboration or cluster must aggregate at least two participants. 0..* on serving can mean optional consumers. These statements are useful only because the underlying relationship is meaningful.
Multiplicity should therefore not be used to compensate for weak relationship choice. If the relationship is really serving, do not use association with multiplicity. If the relation is assignment, do not use a vague association. If the relation is realization, use realization. Multiplicity adds precision to the selected relationship; it does not repair an imprecise relationship type.
There is also a relationship with derivation. ArchiMate has formal derivation rules for relationships, allowing indirect relationships to be derived from modeled relationships. Multiplicity, however, should be treated cautiously in derived views. A derived relationship may be valid as an abstraction, but its multiplicity may not be obvious or may depend on hidden intermediate structure. An architecture team should define whether multiplicities are propagated, suppressed, or recalculated in derived views and reports. Otherwise, a summary view may show cardinalities that appear precise but are not actually justified by the underlying model.
This is an area where tool behavior will matter. The standard introduces the notation, but repository tools must decide how to store, display, validate, import, export, and analyze multiplicity. A serious ArchiMate 4 tool should not treat multiplicity as visual text only. It should store it as structured relationship end metadata. It should allow queries such as find all mandatory relationships that are missing, find all services with zero realizations, find all critical applications with less than two deployment locations, or find all data objects with more than one accountable owner. Without that, the feature remains underused.
From a migration point of view, multiplicity is not primarily about translating ArchiMate 3.2 models. Since the feature did not exist before, old models will usually lack multiplicity. The question is not how to convert it, but where to enrich the model. This enrichment should be selective. Adding multiplicity everywhere would create noise and false rigor. Adding it to critical architecture rules can increase model value substantially.
A practical enrichment approach could start with five areas. First, ownership and accountability: exactly one accountable owner for critical business objects, data objects, services, or capabilities. Second, resilience: at least two realizations, locations, or nodes for critical services and platforms. Third, completeness: every service must have at least one realization and every process must have at least one assigned performer unless explicitly abstract. Fourth, data governance: mandatory relationships between data objects, data products, owners, stewards, and consuming capabilities. Fifth, security and access: approved paths and boundary controls with required realization patterns.
These are high value because they correspond to real governance questions. Who owns this? Is this resilient? Is this complete? Is this compliant? Is this properly controlled? Multiplicity is useful when it helps answer such questions.
The modeling policy should also specify notation restraint. Multiplicity annotations can clutter diagrams if used excessively. Not every relationship needs visible cardinality. Some multiplicities may be stored in the repository and shown only in specialized views, catalogs, matrices, or validation reports. For stakeholder communication diagrams, only cardinalities relevant to the concern should be displayed. This is consistent with ArchiMate’s viewpoint philosophy: a view should show what matters for the stakeholder concern, not every fact in the repository.
A data architect may need a view where many multiplicities are visible. A CIO may need only the exception report. A security architect may need multiplicity on approved paths and control relationships. An infrastructure architect may need multiplicity on deployment and redundancy patterns. A business stakeholder may need none of these details, unless ownership or accountability is the concern.
This reinforces the idea that multiplicity is not just a diagram annotation. It is repository level semantics that can be projected differently in different views.
There is also a broader theoretical significance. ArchiMate 4 simplifies the element vocabulary but adds constraint expressiveness to relationships. This is a good design move. Instead of adding many new concepts to represent special cases, the language adds a general mechanism that applies across relationship types. This is more elegant. It increases expressive power without inflating the metamodel with many new boxes.
This is consistent with the overall direction of ArchiMate 4. Removed concepts reduce vocabulary size. Merged behavior elements reduce redundancy. Generic role and collaboration increase composability. Path in the Common Domain generalizes exchange. Multiplicity on relationships adds precision where the architecture graph needs constraints. The result is a smaller language with a more expressive relational structure.
However, this makes relationship modeling even more central. If the modeler draws weak, ambiguous, or incorrect relationships, multiplicity will only make the weakness more formal. A wrong relationship with a cardinality is worse than a wrong relationship without one, because it appears more rigorous. Multiplicity should therefore be introduced together with stronger modeling review practices.
For enterprise architecture governance, the introduction of multiplicity suggests a new category of model quality checks. Does every cardinality have a clear interpretation at the model’s abstraction level? Is the relationship type correct? Is the lower bound meaningful? Is the upper bound realistic? Is the constraint architectural or merely implementation detail? Is it visible in the right viewpoints? Is there evidence that implementation conforms? Is there a repository validation rule linked to it?
These questions should become part of an ArchiMate 4 modeling standard.
The most important caution is that multiplicity should not create a false sense of mathematical completeness. ArchiMate is not a formal specification language for all enterprise behavior. It is a communication and analysis language. Multiplicity adds useful constraint semantics, but it does not turn the model into a complete formal system. Timing, conditions, runtime states, probabilistic behavior, security adversaries, exception handling, failure propagation, and detailed process semantics still require other modeling or evidence systems.
The correct role of multiplicity is narrower and more valuable: it lets the enterprise architect express architecturally significant cardinality constraints at the right abstraction level. Used well, it improves traceability, completeness, governance, and machine-assisted validation. Used badly, it imports the visual complexity of UML or data modeling without the precision of those disciplines.
In conclusion, multiplicity is a small notation with large implications. It gives ArchiMate 4 a way to express optionality, mandatory participation, redundancy, minimum realization, ownership uniqueness, instance constraints, and structural governance rules directly on relationships. It helps convert some architecture principles from prose into checkable model structure. It supports Data Architects, but it is not limited to data architecture. It is also relevant to process, application, infrastructure, security, resilience, and operating model design.
The practical recommendation is to use multiplicity sparingly but seriously. Apply it where cardinality is an architectural rule, not where it is merely a detail. Store it as repository semantics, not just diagram text. Validate it where possible against model completeness and implementation evidence. Above all, remember that multiplicity does not replace good modeling. It rewards it.
The simplification of ArchiMate 4 makes relationships more important, not less. This is a crucial point. If the language removes several primitive elements, merges behavior across domains, generalizes role and collaboration, and moves path into the Common Domain, then meaning can no longer be carried mainly by the name or color of a box. More meaning must be carried by the typed relationships between concepts.
This is not a side effect. It is one of the structural foundations of ArchiMate. The specification defines a relationship as a connection between a source and target concept, and classifies relationships as structural, dependency, dynamic, or other relationships.101 The language is therefore not merely a notation of elements. It is a graph language. Elements are nodes, relationships are typed edges, and much of the architecture is expressed by the pattern of those edges.
This matters because enterprise architecture is not only an inventory problem. It is not enough to list capabilities, applications, processes, nodes, data objects, facilities, and projects. The architectural value comes from knowing how these things depend on one another. Which capability is realized by which behavior? Which process is served by which service? Which application component accesses which data object? Which technology service supports which application component? WWhich requirements are realized by which architecture elements, work packages, or deliverables according to the allowed relationship table? Which plateau aggregates which target elements? Which path is realized by which active structures? These are relationship questions.
The ArchiMate 4 Specification makes relationships a conformance concern. A conforming implementation must support the language structure, relationships, domains, cross domain dependencies, and the relationships between elements specified in the normative Appendix B.102 This means that relationships are not decorative arrows. They are part of the formal language that tools are expected to support.
Chapter 5 of the specification divides relationships into four main families. Structural relationships describe static construction or composition. Dependency relationships describe how elements support or are used by other elements. Dynamic relationships describe the architecture of a system in motion. Other relationships cover cases such as specialization.103 This classification is essential because each family answers a different architectural question.
Structural relationships answer questions of composition, allocation, realization, and responsibility. Aggregation says that an element combines other concepts. Composition says that the existence of parts depends on the whole. Assignment says that responsibility, performance, storage, or execution is allocated. Realization says that a more concrete element plays a critical role in creating, achieving, sustaining, or operating a more abstract element. These are not interchangeable relationships.
Dependency relationships answer questions of use, support, access, influence, and loose association. Serving says that an element provides functionality to another. Access says that behavior or active structure observes or acts upon passive structure. Influence says that an element affects achievement or implementation of a motivation element. Association is deliberately weak: it represents an unspecified relation or one not represented by another ArchiMate relationship.104
Dynamic relationships answer questions of temporal, causal, or transfer behavior. Triggering represents temporal or causal precedence. Flow represents transfer from one element to another.105 These two are often confused in practice. If one behavior must occur before another, triggering is the relevant relation. If information, material, money, or another object is transferred, flow is the relevant relation. A model that uses flow when it means triggering, or triggering when it means flow, may remain visually readable but becomes analytically weak.
The practical consequence is that ArchiMate 4 requires more discipline in relationship selection. Because several element distinctions have been generalized, a weak relationship choice can now damage the model more than before. If everything becomes a generic process, service, role, or collaboration, then the relationship graph must explain what kind of architecture is actually being described. The modeler must not use association as a lazy substitute for assignment, serving, realization, access, flow, or triggering.
Association deserves special attention. It is useful because not every dependency is known at the beginning of modeling. In early architecture work, association can mark that two elements are related while the exact meaning is still being investigated. But association is semantically weak. A repository full of associations is not a mature architecture model. It is a sketch. It may support conversation, but it cannot support serious impact analysis, traceability, conformance checking, or automated reasoning.
This becomes especially important during migration. The ArchiMate 4 change guidance states that if a relationship between two elements in a model is no longer permitted according to Appendix B, it may be replaced by an association.106 This is a safe conformance fallback, but it should not be treated as a final semantic solution. Replacing an invalid relationship with association preserves connectivity, but it often weakens meaning.
A serious migration from ArchiMate 3.2 to ArchiMate 4 should therefore not stop at syntactic validity. If a relationship becomes invalid, the migration team should ask what the relationship was intended to mean. Was it really assignment? Was it serving? Was it realization? Was it a path realization? Was it access? Was it a flow? Was it a temporary association because the original model was already imprecise? The correct answer may differ from diagram to diagram.
The architectural danger is that migration can preserve shapes while degrading knowledge. A diagram can still look connected after invalid relationships are replaced by associations. But the repository may lose the ability to answer precise questions. Which services are realized? Which applications are assigned to behavior? Which data objects are accessed? Which requirements influence or constrain architecture elements? Which paths are realized by which active structures? If these relationships become generic associations, the model has lost analytical power.
This is one reason why derivation remains central. ArchiMate is not only a language of direct relationships. It also includes rules for deriving indirect relationships. The specification explains that derivation allows irrelevant intermediary elements to be abstracted away in order to present a model or view that supports impact analysis, and that the precise rules are specified in Appendix B.107 This is one of the most important features of ArchiMate as an enterprise architecture language.
Derivation matters because enterprise architecture works at multiple levels of detail. A detailed model may show an application component assigned to an application function, the function realizing a service, the service serving a business process, the process accessing a business object, and the business object being realized by a data object. A stakeholder view may not need all of those intermediate elements. It may need only the statement that an application component supports a business process or that a data object is relevant to a capability. Derivation provides a controlled way to create such summaries.
The specification states that derivation is intended as a way to create summaries of detailed models by removing details while still making valid statements. It also warns that derivation goes from more detail to less detail and cannot be used to infer more detail from an abstract relationship.108 This point is critical. A derived relationship is a valid abstraction of modeled detail. It is not a license to invent missing design detail.
For example, if a realization relationship is modeled from an application component to an application service, this may be a valid derived relationship. It implies that the required constituents may exist, such as a function realizing the service and assigned to the component, even if those constituents are not explicitly modeled in that view. But the reverse is not true. From the high-level realization alone, one cannot infer exactly which function realizes the service or which internal behavior is involved unless that detail is modeled explicitly.
This is the difference between abstraction and speculation. Abstraction removes detail while preserving a valid statement. Speculation invents detail that the model does not contain. ArchiMate derivation is an abstraction mechanism, not an inference engine for hidden implementation.
The normative Appendix B distinguishes valid derivations from potential derivations. Valid derivations are those that are true in any model where the rules apply. Potential derivations may be relevant but depend on the specifics of the model and may also be wrong.109 This distinction is important for architecture governance. Not every inferred relationship has the same confidence. A tool or architect should not treat all inferred edges as equally authoritative.
The valid derivation rules cover several cases. Specialization is transitive. Structural relationships can be chained, and the resulting relationship is the weakest structural relationship in the chain. Structural relationships can combine with dependency relationships so that the dependency can be abstracted across the structural chain. Structural relationships can also combine with dynamic relationships under defined conditions. Triggering relationships are transitive.110 These rules give ArchiMate a controlled form of graph abstraction.
The ordering of structural relationships is particularly important. The specification orders them by strength: realization as the weakest, then assignment, then aggregation, then composition as the strongest. When two structural relationships are joined in line, the derived relationship is the weaker of the two.111 This prevents the model from deriving a stronger claim than the detailed chain justifies. If one part of the chain only supports realization, the summary cannot honestly become composition.
This is a useful formal discipline. It prevents a common modeling error: collapsing a chain of relationships into a relationship that is too strong. If a node hosts an artifact and the artifact realizes an application component, it may be valid to derive that the node realizes the application component. But it would be wrong to say that the node composes the application component. Derivation preserves the weakest warranted claim.
Dependency derivation follows a related logic. The specification explains that a structural relationship and a dependency relationship can be combined under certain conditions and replaced by the dependency relationship. Informally, the beginning or endpoint of a dependency can be transferred backwards along a chain of structural relationships.112 This is what makes impact analysis possible across levels of detail.
For example, suppose an application service serves a process, and the service is realized by internal application behavior performed by an application component. A view may derive that the application component supports the process. The detailed model explains how. The derived view exposes the dependency that matters to a stakeholder.
Dynamic derivation is equally important but more delicate. Triggering and flow relationships represent different kinds of dynamic dependency. The specification states that triggering follows structural semantics, while flow follows dependency semantics.113 This means derived dynamic relationships must be interpreted carefully. A triggering relationship derived through a chain does not necessarily mean that every step of the source behavior completes before every step of the target behavior begins. The specification itself notes that a stronger interpretation could be imposed by a modeling group, but is not the default.
This is a useful caution for enterprise architects. ArchiMate is not a process execution language. It can show high-level dynamic dependencies, but it does not define full operational semantics like a workflow engine or BPMN execution model. If precise execution semantics matter, use a specialized notation. ArchiMate should show architectural relevance, not replace detailed process logic.
Potential derivation is even more sensitive. The specification gives potential rules for specialization, dependency chains, flow chains, structural and dynamic relationships, and grouping. It explicitly says that these potential derivations may be relevant but may also be wrong depending on the specifics of the model, and that it is up to the modeler to decide.114 This is a strong warning against blind automated inference.
This point is especially relevant in large repositories. A tool may be able to compute many possible relationships. But not every computed relation should be shown to users, used in impact analysis, or treated as architectural truth. Potential derivation should be used as an aid to discovery, not as a substitute for architectural judgment.
Grouping is a good example. A grouping element can collect arbitrary concepts based on a common characteristic. Relationships to or from a grouping may suggest relationships to or from its members. But the semantics are not always clean. The specification notes that grouping relationships may imply collective meaning, but this is not always easily expressed in simple derivable relationships.115 Therefore, grouping should be used carefully in analytical models. It is useful for structure, but it can create ambiguous implications if relationships are attached to the group without clarifying whether they apply to all members, some members, or the group as a collective.
This has practical consequences for architecture repositories. If a grouping represents a security zone, a product domain, a transition scope, a capability cluster, or an architectural building block, a relationship from the group to another element may be interpreted collectively. But does it mean every element in the group participates? Does it mean the group as a whole participates? Does it mean at least one element participates? The model should clarify this, or use explicit relationships from the relevant elements.
Junctions also require discipline. The specification states that a junction connects relationships of the same type, and that a chain through junctions is valid only if the corresponding direct relationship would also be valid. Junctions cannot be used to create relationships that the language otherwise forbids.116 This is another example of ArchiMate’s formal discipline. Junctions can simplify or clarify relationship logic, but they cannot bypass the metamodel.
This is important because modelers sometimes use junctions as visual routers. That is dangerous. A junction is not just a graphic convenience. It has semantics. All relationships connected to the same junction must be of the same type. The junction expresses and or or participation. If a model uses junctions only to make lines look cleaner, it risks creating invalid or misleading semantics.
The relationship rules are therefore not bureaucratic constraints. They protect the meaning of the model. If a tool allows arbitrary lines between arbitrary boxes, the diagram may be visually expressive but architecturally unreliable. Appendix B exists because an architecture model is not only a picture; it is a set of statements. Invalid relationships are invalid statements.
This becomes even more important after ArchiMate 4’s simplification. When the language has fewer primitive element types, relationships carry more semantic load. A generic process with a business actor assigned to it means one thing. The same process with an application component assigned to it means another. The same process realizing a service means another. The same process accessing a data object or being triggered by an event means another. The element alone is not enough. The relationship pattern is the architecture.
The move to the Common Domain makes this unavoidable. A service is now generic. A role is generic. A collaboration is generic. A process is generic. A function is generic. A path is generic. Therefore, the question what is this? can often be answered only by asking how is it related? Is the service realized by application behavior, exposed through a business interface, served to a role, or supported by technology? Is the role fulfilled by a business actor, application component, device, facility, or collaboration? Is the path realized by communication networks, distribution networks, equipment, or software? Relationships provide the answers.
This is why ArchiMate 4 is less tolerant of box based modeling. A diagram that places elements in approximate positions and relies on labels may be acceptable for informal communication, but it will not exploit the language. In ArchiMate 4, correct relationship modeling becomes the difference between an architecture model and a drawing.
There is also a governance implication. Architecture teams should define relationship usage rules, not only element usage rules. Many organizations have modeling standards that define when to use an application component, business object, data object, node, capability, or requirement. That is no longer enough. They must also define when to use serving versus realization, assignment versus access, flow versus triggering, aggregation versus composition, association versus a more specific relation, and path versus flow or communication network.
A useful rule is to ask what claim the relationship is making. Assignment claims that responsibility, performance, storage, or execution is allocated. Realization claims that something more concrete makes something more abstract real. Serving claims that functionality is provided. Access claims that passive structure is observed or acted upon. Triggering claims temporal or causal precedence. Flow claims transfer. Aggregation claims a whole and part relation without strict existence dependency. Composition claims a stronger existence dependency. Association claims only that a relation exists but is not otherwise specified.
This should be part of modeling review. Reviewers should not ask only whether the diagram is readable. They should ask whether each relationship says what the architect intends. If an application component is connected to a process, is it serving the process, assigned to the process, realizing a service used by the process, or merely associated? Each answer has different implications.
Relationship modeling also affects metrics and reports. If all dependencies are modeled as associations, the repository cannot distinguish service dependency from data access, realization, assignment, or dynamic flow. If serving is used incorrectly where access is intended, impact analysis may overstate functional dependency. If realization is used where assignment is intended, the model may confuse implementation with execution. If flow is used for service dependency, information movement and support dependency become mixed. These errors propagate into reports and decisions.
This is why derivation should be used only on high quality relationships. Derivation amplifies the underlying model. If the detailed relationships are correct, derivation can produce useful stakeholder views and impact analysis. If the detailed relationships are wrong, derivation produces plausible but false summaries. The more automated the repository becomes, the more important relationship quality becomes.
A mature ArchiMate 4 repository should therefore separate three kinds of relationships: asserted, derived, and potential. Asserted relationships are explicitly modeled by architects. Derived relationships are valid abstractions computed from asserted relationships according to the normative rules. Potential relationships are candidates suggested by the model structure but requiring validation. These categories should not be mixed silently.
This separation is especially useful for impact analysis. Suppose a technology node changes. A repository may derive that several application components, services, processes, capabilities, and outcomes are affected. Some dependencies may be certain because they follow valid derivation rules. Others may be potential because they depend on grouping, specialization, or uncertain dependency chains. A good tool should distinguish the confidence of these results. A good architect should not present potential impacts as certain impacts without review.
This also matters for architecture decision making. If a CIO asks which business capabilities depend on a legacy platform, the answer may be based on several derived chains: platform realizes application components, application components realize or serve services, services serve processes, processes realize capabilities. The usefulness of the answer depends entirely on relationship correctness and derivation discipline. If the model uses associations everywhere, the answer becomes weak. If the relationship graph is precise, the answer can support real decision making.
The same applies to cybersecurity and operational resilience. To understand whether a facility, communication network, identity provider, remote access path, or cloud region is critical, the architecture needs chains of dependency. Which services depend on this path? Which applications are served by this node? Which processes rely on this application? Which capabilities or outcomes are affected? Derivation turns detailed architecture into impact views. But only if the relationships are modeled correctly.
ArchiMate 4’s relationship rules also help avoid false hierarchy. The previous layer metaphor sometimes encouraged the idea that dependencies always point upward from technology to application to business. The new domain structure rejects that simple hierarchy. Relationships can now express more complex patterns, including same domain serving, cross domain realization, shared common behavior, and mixed collaborations. But this freedom increases the need for relationship discipline. Without the old visual hierarchy, relationships must explain the architecture explicitly.
This is a better model of reality. Modern enterprises contain circular dependencies, feedback loops, shared platforms, external providers, data products, event driven architectures, physical operations, AI services, and distributed ownership. A simple layer stack cannot represent this adequately. A typed graph can. But only if the graph is semantically governed.
There is one more practical point: derived relationships are useful for communication because not every stakeholder should see the same level of detail. The specification explains that the language distinguishes model concepts from notation and supports stakeholder oriented views.117 Derivation fits this principle. The repository may contain detailed relationships; a stakeholder view may show a smaller number of derived relationships that answer a specific concern.
For example, an executive view may show that a strategic capability depends on a critical application service. The detailed model may contain multiple intermediate relationships through processes, application components, data objects, nodes, and technology services. The executive does not need all of that. But the derived statement should be traceable to the detailed model. This is the difference between simplification and oversimplification. Derivation allows simplification without losing accountability to the underlying architecture.
This is also where ArchiMate can become a stronger semantic layer. A repository that stores explicit relationships and supports derivation can function as an architecture knowledge graph. It can answer questions, generate views, detect gaps, support migration planning, and compare target and baseline states. A repository that stores only diagrams cannot do this reliably. The difference is not the notation. It is the relationship semantics.
The introduction of multiplicity strengthens this further. Relationships can now carry cardinality constraints. Derivation and multiplicity together create new governance possibilities, but also new risks. If a derived relationship hides intermediate multiplicities, a high-level view may lose important constraints. For example, a service may be realized by at least two processes, each assigned to different components. A summary relationship may show only that an application component realizes a service, but not the redundancy rule. Architecture teams should decide when multiplicity is shown, propagated, or suppressed in derived views.
This is another reason why tool behavior matters. A conforming implementation must support relationships and Appendix B, but mature practice requires more than conformance. Tools should distinguish relationship types clearly, validate allowed relationships, support derivation, distinguish asserted from derived relations, expose potential derivations cautiously, preserve multiplicity, and allow relationship based queries. Otherwise, ArchiMate 4’s formal semantics remain underused.
The practical migration recommendation is to run a relationship audit. After element conversion, inspect all relationships affected by removed elements, merged behavior, generic roles, generic collaborations, and path relocation. Replace invalid relationships where necessary, but do not default to association unless the relationship is truly unspecified. Where associations are used temporarily, mark them for later semantic review. Where relationship derivation changes, validate key reports and viewpoints.
A relationship audit should ask several questions. Are services realized by behavior or active structures according to the intended abstraction? Are processes assigned to the right performers? Are data objects accessed rather than merely associated? Are requirements realized, influenced, or associated correctly? Are paths realized by active structures rather than aggregating them incorrectly? Are flows used only for transfer? Are triggering relationships used only for temporal or causal precedence? Are groupings carrying relationships that should belong to their members? Are derived views traceable to detailed relationships?
This is demanding, but it is where the value of the migration lies. ArchiMate 4 gives an opportunity to remove not only obsolete elements but also weak relationship habits. A model converted to ArchiMate 4 should not merely be valid. It should be more analyzable.
The deeper conclusion is that ArchiMate 4 shifts the language further from taxonomy toward graph semantics. The core vocabulary becomes smaller and more generic. The relationship structure becomes more important. The repository becomes more valuable if it can reason over that structure. This is aligned with the needs of modern enterprise architecture, where the main question is rarely what boxes exist? and more often what depends on what, under which assumptions, through which services, with which ownership, and with which impact if it changes?
Relationships and derivation remain central because they are the mechanism by which ArchiMate avoids becoming a static drawing language. They allow the same underlying model to support detailed engineering conversations, executive impact views, migration roadmaps, ownership analysis, resilience analysis, and strategic traceability. Without them, ArchiMate 4 would be only a simpler notation. With them, it can remain a disciplined architecture language.
The practical rule is simple: in ArchiMate 4, do not trust a box until its relationships are clear. The element name tells only part of the story. The architecture is in the graph.
ArchiMate 4 makes language customization more important because it deliberately makes the standard language smaller. This is not an accidental consequence. It is the other side of the simplification strategy. If the core language removes redundant concepts, merges behavior elements, generalizes role and collaboration, and relocates several distinctions into the Common Domain, then organizations that still need domain-specific precision must express that precision through profiles, attributes, specializations, viewpoints, and repository governance.
This is the key point: ArchiMate 4 simplifies the standard, not the enterprise. Contracts still exist. Constraints still exist. Business, application, and technology distinctions still matter in many models. AI accountability, security control ownership, data stewardship, operational responsibility, plant connectivity, supplier obligations, and regulatory requirements still need to be represented. But the standard no longer gives every such distinction a primitive box. It gives a smaller set of more general concepts and expects disciplined customization where additional precision is needed.
The ArchiMate 4 Specification provides the mechanisms for this in Chapter 14. It states that the language can be customized in several ways, including the addition of attributes through profiles and the specialization of concepts.118 These mechanisms are not cosmetic. They are now central to serious use of the language because ArchiMate 4 moves several previously explicit distinctions into the customization layer.
The first customization mechanism is the use of attributes. The specification explains that every ArchiMate concept can have attributes, and that attributes can be used to express additional properties of concepts and relationships.119 This is important because many architectural facts are not naturally represented by new element types. Criticality, owner, lifecycle state, confidentiality level, regulatory scope, technology standard, site, supplier, service level, resilience classification, and implementation status are often better represented as attributes than as separate concepts.
Attributes prevent the metamodel from becoming bloated. Without attributes, modelers tend to create new element types for every distinction. With attributes, a single concept can carry structured metadata. An application component can have attributes such as lifecycle state, hosting model, business criticality, cloud provider, technology owner, operational owner, and data classification. A process can have attributes such as automation level, criticality, regulatory relevance, frequency, and execution mode. A path can have attributes such as exchange type, security classification, allowed direction, monitoring requirement, and approved realization pattern.
This is a good design principle. A modeling language should not create a new primitive element when the difference is merely a property of an existing element. If two objects behave the same way in the metamodel but differ by classification, an attribute or specialization is often more appropriate than a new element.
However, attributes are useful only if they are governed. If every modeler invents attributes freely, the repository becomes semantically inconsistent. One team may use owner, another business owner, another service owner, another accountable party. One team may use criticality with values high, medium, low; another may use tier 1, tier 2, tier 3; another may use numerical scores. The model remains visually valid, but repository analysis becomes unreliable.
This is why profiles matter. The specification defines a profile as a set of attributes that can be coupled to ArchiMate concepts.120 A profile is a controlled way to attach structured metadata to a concept. It is not just a note field. It is a modeling convention that says: when an element belongs to this profile, it may or must have these attributes, with these meanings and possibly these allowed values.
Profiles are therefore the governance layer for attributes. A security profile may define attributes such as confidentiality, integrity, availability, trust zone, control owner, and audit requirement. A data governance profile may define attributes such as data owner, data steward, personal data category, retention period, residency requirement, authoritative source, and quality rule. A technology lifecycle profile may define attributes such as lifecycle status, vendor support end date, deployment model, standard status, and exception approval. A transformation profile may define attributes such as baseline state, target state, migration wave, dependency level, and funding status.
This is how ArchiMate 4 can remain small while still supporting complex enterprise practices. The standard language remains generic. The enterprise profile layer carries local semantics. The repository becomes useful because the profile layer is structured, queryable, and consistent.
The second customization mechanism is specialization. The specification explains that concrete ArchiMate concepts can be specialized, that specialized elements inherit the properties of the concepts they specialize, and that specialized relationships can also be defined.121 This is the main way to preserve distinctions that were removed from the core language or to introduce enterprise specific refinements.
Specialization is stronger than a free text label because it preserves the formal relation to the parent concept. If Contract is modeled as a specialization of business object, it remains a business object. It can participate in the relationships allowed for business objects. It inherits the semantics of business object but adds a more precise meaning. If Architectural Constraint is a specialization of requirement, it remains a requirement. If Policy Decision Point is a specialization of role, it remains a role. If Remote Maintenance Path is a specialization of path, it remains a path.
This inheritance is essential. It prevents customization from becoming an uncontrolled parallel language. A specialization should not break the ArchiMate metamodel. It should refine it. The specialized concept should answer the question: what more specific kind of this parent concept do we need?
This is exactly how ArchiMate 4 treats several removed concepts. The official conversion guidance says that constraint can be replaced by a specialization of requirement, contract by a specialization of business object, gap by a specialization of assessment or deliverable, representation by a specialization of data object, artifact, or material, and interaction by a specialization of function or process.122 This is not merely a migration trick. It is a design pattern for ArchiMate 4.
The motivation white paper makes the same point in the context of behavior conversion. When ArchiMate 3.2 layer-specific behavior concepts are converted into generic behavior concepts, there are two options. One is to convert them directly and infer their origin from assignment relationships where possible. The other is to assign specialization profiles to show from which ArchiMate 3.2 layer the new generic concept was converted, so that no information is lost.123
For large repositories, the second approach is often safer. If years of models distinguish business processes, application processes, and technology processes, that distinction may contain useful institutional knowledge. Some of it may be redundant and removable. Some of it may be needed for reporting, ownership, migration, or stakeholder communication. A blind conversion into generic processes may produce a formally valid model but erase meaningful classification. Specialization profiles allow the repository to preserve the distinction while still aligning with ArchiMate 4.
This creates a practical rule: simplification should be reversible during migration until semantic review is complete. Convert old concepts to ArchiMate 4 concepts, but preserve their origin through specialization or attributes. Then decide deliberately which distinctions remain useful and which should be retired. Do not let a tool conversion silently decide the architecture ontology.
The specification itself includes examples of specializations of Common Domain elements. It lists Business Role as a specialization of Role; Business/Application/Technology Collaboration as specializations of Collaboration; Business/Application/Technology Service as specializations of Service; Business/Application/Technology Process and Business/Application/Technology Interaction as specializations of Process; Business/Application/Technology Function as specializations of Function; and Business/Application/Technology Event, plus Implementation Event, as specializations of Event. It does not list Application Role or Technology Role as example specializations.124 This is important because it clarifies that ArchiMate 4 has not made these words forbidden. It has changed their status. They are no longer primitive elements that every modeler must carry. They become optional refinements that an organization may use if they add value.
This status change matters. A primitive concept belongs to the standard vocabulary. A specialization belongs to a governed modeling practice. The former imposes cognitive load on everyone. The latter should be used only where the enterprise has a reason. This is the core logic of ArchiMate 4 customization.
The practical challenge is that specialization can easily become a hidden source of complexity. If every project defines its own specializations, the repository fragments. One team creates Application Service Legacy, another creates Legacy App Service, another creates Deprecated Service, another creates Retired Interface, and reports cannot compare them. The model is technically ArchiMate, but the enterprise no longer has a common language.
This is the same danger that appeared historically in profile based modeling languages. A small formal kernel is useful only if the extension layer is governed. Otherwise, the kernel is shared in theory while real meaning moves into incompatible local dialects. ArchiMate 4 avoids language bloat at the standard level, but each enterprise must avoid bloat at the customization level.
A mature ArchiMate 4 practice therefore needs a profile catalog. The catalog should define every approved specialization and profile used in the repository. For each one, it should state the parent concept, definition, rationale, allowed attributes, required attributes, allowed values, notation rule if any, allowed relationship restrictions if stricter than the parent concept, examples, anti examples, ownership, lifecycle status, and migration mapping from ArchiMate 3.2 if relevant.
This catalog should be treated as architecture method content, not as tool configuration only. If the catalog exists only inside one modeling tool, it becomes tool specific knowledge. If it is documented as part of the enterprise architecture method, it can survive tool migration, onboarding, audit, and repository federation.
The same applies to naming conventions. Customization is not only profiles and attributes. It also includes how elements are named. If generic concepts become more common, names must become clearer. A generic process called Validation is too vague. A generic role called Owner is too vague. A generic path called Connection is too vague. The modeler should name elements according to the architectural meaning that is not otherwise visible. For example, Validate Customer Identity, Policy Decision Point, Remote Maintenance Path, Regulated Data Owner, or Plant Telemetry Exchange Path.
Good naming cannot replace formal profiles, but it improves readability. Profiles support machine analysis. Names support human interpretation. Both matter.
Language customization also affects notation. The ArchiMate specification separates concepts from their notation. It allows default iconography and visual conventions, but the semantic model is not identical to the diagram. The specification also notes that colors have no formal semantics, although they can be used as notational cues for domains.125 This becomes more important in ArchiMate 4 because many formerly colored layer-specific elements become generic Common Domain elements.
If all generic processes, services, roles, collaborations, and paths appear with the same visual style, some readers may feel that the model has lost domain information. There are several possible responses. One is to rely entirely on relationships and accept that the domain meaning is in the graph. Another is to use specialization profiles and notational cues to preserve readability. Another is to use viewpoint specific color conventions. The important point is that color must not become the only carrier of semantics. If the model loses meaning when printed in grayscale or exported to another tool, the semantics are not robust.
Customization must therefore distinguish between semantic customization and visual customization. A specialization profile is semantic. It says that an element is a specific kind of parent concept. An attribute is semantic. It adds structured information. A color or icon may help communication, but by itself it should not be treated as authoritative semantics unless the repository stores the corresponding profile or attribute.
This is especially important for exchange between tools. The motivation white paper notes that future support in the ArchiMate Model Exchange File Format was expected to add support for exchanging specialization profiles.126 The underlying issue is clear: customization only has enterprise value if it survives exchange. A model that depends on specializations, profiles, or visual conventions must be transferable without losing meaning. Otherwise, tool interoperability becomes formal but not semantic.
This leads to a strong governance principle: every customization that matters must be stored as model data, not only as diagram appearance. If Contract is important, it should be a specialization of business object, not just a business object colored differently. If Critical Service matters, criticality should be an attribute or profile value, not only a red border. If Remote Maintenance Path matters, it should be a specialization or tagged path, not just a line drawn in a special color.
The same principle applies to reports and queries. A repository should be able to answer questions based on customized semantics. Which requirements are regulatory constraints? Which business objects are contracts? Which paths are remote access paths? Which roles are accountable roles? Which application components fulfill policy enforcement roles? Which processes are AI assisted? Which services are critical? Which artifacts are SBOMs? If the customization is only visual or textual, these questions cannot be answered reliably.
A strong ArchiMate 4 customization strategy should be designed around use cases. Customization should not start with what specializations can we invent? It should start with what questions must the repository answer? If the architecture practice needs to answer cybersecurity questions, define security profiles. If it needs to answer data governance questions, define data profiles. If it needs to answer transformation planning questions, define lifecycle and roadmap profiles. If it needs to answer supplier risk questions, define supplier and contract related specializations. If it needs to answer operational resilience questions, define criticality, dependency, and redundancy attributes.
This prevents profile proliferation. Every customization should justify itself by a decision, report, control, analysis, or stakeholder concern. Otherwise it becomes conceptual decoration.
For example, an enterprise may define a Critical Service profile for services. The rationale is operational resilience. Required attributes may include criticality tier, maximum tolerable downtime, recovery time objective, recovery point objective, service owner, supporting capabilities, and evidence source. This profile is justified because it supports resilience analysis, continuity planning, and audit.
Another enterprise may define AI Assisted Process as a specialization or profile of process. The rationale is governance of AI participation in business behavior. Required attributes may include model provider, human oversight role, decision authority, explainability requirement, training data sensitivity, audit evidence, and fallback process. This profile is justified because generic process alone does not capture AI governance concerns.
Another may define Remote Maintenance Path as a specialization of path. The rationale is OT security. Required attributes may include approval owner, allowed source, allowed destination, access window, monitoring requirement, authentication method, boundary control, and logging evidence. This is justified because remote maintenance connectivity is both operationally useful and security sensitive.
Another may define Contract as a specialization of business object. The rationale is product, supplier, and service obligation modeling. Required attributes may include parties, validity period, service level, obligations, governing law, renewal condition, and termination condition. This is justified if contracts are used in product, outsourcing, service, or compliance architecture.
These examples show the right use of customization. The profile exists because the enterprise needs to reason about something. It is not created merely because a word exists in business language.
There is also a boundary between customization and misuse. If an organization creates specializations for every vendor product, cloud service, department acronym, project phase, or implementation detail, it will recreate the bloat that ArchiMate 4 is trying to avoid. Vendor products are usually better modeled as names, attributes, or concrete instances of existing concepts, not as new concept types. Project phases may be attributes of work packages or plateaus. Department names may be business actors or locations, not role specializations. The profile catalog should reject customizations that do not add metamodel value.
A useful test is inheritance. If the proposed specialization is truly a kind of the parent concept, and if that kind has distinctive modeling rules or analytical value, specialization may be justified. If the proposed specialization is merely a label, value, status, or vendor name, use an attribute instead. If it is only a visual distinction, use notation. If it is just a cluster for communication, use grouping or a view.
This distinction between specialization and attribute is important. Contract is a good specialization of business object because it is a specific kind of business object with distinctive meaning. Criticality = High is better as an attribute than as a specialization called High Criticality Application Component, because criticality is a property that can apply to many concept types and values. AWS Lambda is usually better as an attribute, product reference, artifact, or technology service pattern than as a new ArchiMate concept type, unless the enterprise has a controlled cloud metamodel extension outside ArchiMate.
Customization should also be layered. At the base there is the ArchiMate 4 standard. Above that there should be an enterprise wide profile catalog. Above that, domains such as security, data, cloud, OT, product, or transformation may define controlled extensions. Project specific extensions should be exceptional, temporary, and subject to promotion or retirement. Otherwise, local projects become dialect generators.
The governance body for customization should include both method owners and domain experts. Enterprise architects understand the metamodel. Security architects understand control semantics. Data architects understand data ownership and lineage. Technology architects understand platform and infrastructure patterns. Business architects understand operating model and capability semantics. A profile designed only by metamodel experts may be elegant but irrelevant. A profile designed only by domain experts may be useful but inconsistent with ArchiMate. Both views are needed.
The language customization layer should also have lifecycle management. Profiles may be proposed, experimental, approved, deprecated, or retired. Attributes may change. Allowed values may be refined. Old specializations may be merged. Migration scripts may be required. Versioning matters because a repository is a long lived asset. If the profile catalog changes without version control, historical models become hard to interpret.
This is particularly important during the ArchiMate 3.2 to ArchiMate 4 transition. Some specializations may be transitional. For example, Business Process, Application Process, and Technology Process may be preserved as specializations of process only to maintain traceability during migration. After semantic cleanup, the organization may decide to retire some of them or replace them with more useful profiles such as Manual Process, Automated Process, AI Assisted Process, Control Process, or Operational Process.
This would be a better outcome than simply recreating ArchiMate 3.2 inside ArchiMate 4. The objective should not be to restore every removed or merged element as a specialization forever. The objective should be to preserve information during migration, then design a better enterprise modeling language on top of ArchiMate 4.
There is a subtle but important difference between preserving compatibility and preserving old complexity. During migration, compatibility matters. Users need continuity, reports need to work, diagrams need to remain understandable, and old models need traceability. After migration, the architecture practice should ask which old distinctions still serve a purpose. If a specialization exists only because the old language had that element, it should be challenged.
This is where ArchiMate 4 can improve modeling quality. The forced review of removed and merged concepts creates an opportunity to clean the repository. Some old constraints may become regulatory requirements. Some old gaps may become assessments. Some old representations may become data objects or artifacts. Some old interactions may become processes assigned to collaborations. Some old business processes may become generic processes with explicit human and machine performers. Customization should support this cleanup, not block it.
Language customization also affects stakeholder communication. Different stakeholders may need different semantic detail. A business executive may not care whether a process is specialized as AI assisted, automated, or manual unless it affects risk, cost, or accountability. A security officer may care deeply. A data protection officer may care whether a data object has personal data attributes and residency requirements. A platform architect may care whether an application component fulfills a policy enforcement role. The profile catalog should support viewpoint design so that the right custom semantics appear in the right views.
This implies that profiles should not automatically appear everywhere. A model element may carry many attributes, but a view should show only those relevant to the concern. Otherwise, customization turns diagrams into metadata dumps. The repository can hold rich semantic information. The diagram should remain selective.
This is consistent with the ArchiMate principle that the language is designed primarily for communication among human users.127 Customization should not destroy communicability. If a view requires a legend longer than the diagram, the customization may be too dense for that stakeholder. Rich semantics should exist in the repository, while views should expose them selectively.
There is also a relationship between customization and conformance. A conforming implementation of ArchiMate must support the standard language and its relationship rules, but enterprise customization may impose stricter local rules. For example, ArchiMate may allow a relationship between certain concepts, but the enterprise method may forbid it in a specific profile. ArchiMate may allow a generic process without an assigned performer, but the enterprise may require every operational process to have at least one assigned role or active structure. ArchiMate may allow association, but the enterprise may require associations to be reviewed and replaced by stronger relationships where possible.
These local rules are not contradictions of the standard. They are governance rules on top of it. They make the language usable at enterprise scale.
The strongest customization practices will connect profiles to validation. If Critical Service requires at least one realization, one owner, and resilience attributes, the tool should detect missing values. If Remote Maintenance Path requires approved boundary controls, the repository should detect paths without realization by approved security components. If Regulatory Requirement must be associated with a regulation source and realized by controls or work packages, missing links should be reported. Customization is most valuable when it can be checked.
This moves enterprise architecture from diagramming toward semantic governance. A profile catalog plus validation rules turns models into structured knowledge. It allows architecture teams to detect incompleteness, inconsistency, and drift. It also makes the model more useful for audit, compliance, migration planning, and operational resilience.
However, validation must be used carefully. Too many mandatory attributes or rules can make modeling burdensome. If every element requires ten attributes before it can be saved, modelers will either avoid the tool or enter low quality values. The profile catalog should distinguish mandatory fields for governance critical elements from optional metadata for ordinary elements. Criticality should drive rigor.
A practical principle is progressive enrichment. Early architecture models may use generic concepts with minimal attributes. As elements become part of target architecture, implementation planning, risk review, or operational governance, profiles become more detailed. This allows the language to support early exploration without losing the ability to become rigorous later.
This principle fits ArchiMate 4 well. The language allows generic behavior first, then later refinement through assignment, realization, specialization, multiplicity, and attributes. Customization should follow the same lifecycle. Do not force full precision too early. But do not allow important architecture decisions to remain vague when they enter governance.
There is also a documentation requirement. Every profile and specialization should have examples and anti examples. Without examples, modelers will interpret definitions differently. A good profile definition should show how to model common cases, how not to model similar but different cases, and how the profile affects relationships and reports.
For instance, a Contract specialization should explain the difference between the legal agreement as business object, the PDF document as artifact, the policy data as data object, and the printed signed copy as material. A Remote Maintenance Path specialization should explain the difference between the logical path, the communication network realizing it, the firewall enforcing it, and the service provided over it. A Policy Decision Point role should explain which active structures may fulfill it and how it differs from a policy enforcement point. These examples prevent semantic drift.
Customization also changes training. ArchiMate 4 training should not stop at the standard concepts. It should include the enterprise profile catalog, relationship rules, migration rules, and viewpoint conventions. Otherwise, modelers will know ArchiMate but not the enterprise dialect. In a simplified language, the local dialect carries more meaning. It must therefore be taught explicitly.
This creates an organizational responsibility. The enterprise architecture function must own the language customization layer. It cannot be delegated entirely to tool administrators or individual projects. Tool administrators can implement profiles. Domain teams can propose them. But the enterprise architecture function must govern consistency across the repository.
This is also where ArchiMate 4 adoption intersects with architecture operating model. A central EA team may define the core profile catalog. Federated domain architects may maintain domain extensions. Governance boards may approve changes. Repository stewards may monitor compliance. Tool administrators may implement validation. This is a real operating model, not just notation management.
The cost is non trivial. But it is the price of a smaller standard language. ArchiMate 4 gives a cleaner kernel. The enterprise must build and govern the semantic layer that makes that kernel useful in its specific context.
In conclusion, language customization becomes more important because ArchiMate 4 shifts precision from the standard vocabulary to governed modeling practice. Profiles, attributes, and specializations are no longer optional refinements for advanced users. They are the mechanism by which organizations preserve necessary distinctions without reintroducing standard level bloat.
Used well, customization lets ArchiMate 4 remain simple while supporting complex enterprise realities: regulation, data governance, cybersecurity, AI, platforms, OT, physical assets, outsourcing, resilience, and transformation. Used badly, it creates uncontrolled dialects and restores the complexity that ArchiMate 4 intentionally removed.
The practical recommendation is clear. Treat the ArchiMate 4 profile catalog as a first class architecture asset. Define it deliberately. Version it. Govern it. Validate it. Teach it. Keep it small. Tie every customization to an architectural question, decision, control, report, or stakeholder concern. Otherwise, the language will be simpler only on paper, while the real complexity moves into unmanaged local conventions.
A migration from ArchiMate 3.2 to ArchiMate 4 should not be treated as a diagram conversion. It should be treated as a repository transformation. This distinction matters because ArchiMate models are not only drawings. In a mature architecture practice, they are a structured memory of decisions, responsibilities, dependencies, target states, transformation work, standards, exceptions, and stakeholder agreements. A migration that only replaces old symbols with new symbols may produce formally valid diagrams while damaging the semantic value of the repository.
The official ArchiMate 4 Specification makes the mechanical part of the migration look simple. Appendix E says that ArchiMate 3.2 models can be translated by replacing removed or changed concepts with their ArchiMate 4 equivalents: constraint with a specialization of requirement, contract with a specialization of business object, gap with a specialization of assessment or deliverable, representation with a specialization of data object, artifact, or material, interactions with a specialization of function or process, other layer-specific behavior elements with their generic counterparts, implementation event with the generic event element, invalid relationships with association, and aggregation from path to technology internal active structure with realization from the active structure element to path.128
Those transformations are necessary, but they are not sufficient. They tell us how to avoid using concepts that no longer exist in ArchiMate 4. They do not decide which meaning in the old repository was valuable, which meaning was redundant, which meaning was ambiguous, and which meaning was only a workaround created by the old language structure. That judgment cannot be delegated entirely to a tool.
The first principle of migration is therefore semantic preservation before simplification. Before collapsing old elements into new generic concepts, the architecture team should preserve enough information to reconstruct what the original model meant. Only after that should it decide which distinctions can be removed. In practical terms, this means that old ArchiMate 3.2 element types should usually be recorded during migration, either through specialization profiles, attributes, tags, or a temporary migration register.
The Open Group motivation paper describes exactly this problem for behavior elements. It gives two conversion options. The first is to turn each layer-specific concept into the corresponding generic concept and infer the originating layer from assignment relationships where possible. The second is to convert each layer-specific concept into the generic concept and also assign a specialization profile showing from which ArchiMate 3.2 layer the new generic concept came. The paper states that with this second option, no information is lost in the conversion, although it requires tool support for such concepts.129
For any serious repository, the second approach is safer. A business process, application process, and technology process may all become process in ArchiMate 4. But in the existing repository, those element types may have been used for reporting, ownership, filtering, viewpoints, review workflows, or stakeholder communication. If they are collapsed without preserving provenance, the migrated model may be cleaner in theory but poorer in practice.
This does not mean that the old distinctions should be preserved forever. It means that they should be preserved long enough to be evaluated. Some old distinctions will remain valuable as specializations. Some will be replaced by better ArchiMate 4 modeling patterns. Some will be deleted because they were redundant. A responsible migration keeps the choice explicit.
The second principle is that migration should be staged. A one pass conversion is attractive, but risky. A better migration has at least six stages: inventory, conversion, semantic review, relationship audit, view refactoring, and validation against use cases. Each stage answers a different question.
The inventory stage answers: what do we have? It should count all concepts affected by ArchiMate 4. This includes business interaction, application interaction, technology interaction, constraint, contract, gap, representation, business process, application process, technology process, business function, application function, technology function, business service, application service, technology service, business event, application event, technology event, implementation event, business role, business collaboration, application collaboration, technology collaboration, and path relationships affected by the new realization pattern.
The inventory should also count affected relationships. It should identify relationships that are no longer permitted according to the ArchiMate 4 normative relationship tables, aggregations from path to technology internal active structure, realization workarounds used to represent automation, associations used as generic links, and relationships connected to removed elements. The ArchiMate 4 Specification explicitly says that invalid relationships may be replaced by association, but this should be treated as a migration fallback, not as a semantic endpoint.130
The inventory should not only be quantitative. It should identify usage patterns. For example, some contracts may be used only as part of product models. Some constraints may represent legal obligations. Some representations may actually be data objects, while others may be artifacts or physical material. Some gaps may represent analysis results, while others may represent deliverables or missing work. Some interactions may represent process like behavior, while others may represent functional grouping or collective execution. The same element type may have been used differently by different teams.
This is why migration cannot be purely mechanical. If a repository used representation to mean PDF document, database record, paper form, and screen view, one replacement target is not enough. The official guidance gives data object, artifact, or material as alternatives because the right target depends on meaning.131 The migration process must therefore classify actual usage, not just element type.
%%{init: {"theme": "neo", "look": "forest"}}%%
flowchart LR
subgraph OLD["ArchiMate 3.2 source"]
O1["Layer-specific behavior<br/>business / application / technology<br/>service, process, function, event"]
O2["Implementation Event"]
O3["Business Role"]
O4["Business / Application / Technology<br/>Collaboration"]
O5["Business / Application / Technology<br/>Interaction"]
O6["Removed concepts<br/>constraint, contract,<br/>gap, representation"]
O7["Path aggregating<br/>technology internal active structure"]
O8["Relationship no longer permitted<br/>by ArchiMate 4 Appendix B"]
O9["Realization between services<br/>of different layers"]
end
subgraph NEW["ArchiMate 4 target"]
N1["Generic behavior<br/>Service, Process, Function, Event<br/>optionally specialized"]
N2["Generic Event<br/>optionally specialized"]
N3["Generic Role<br/>internal active structure elements<br/>may be assigned to it"]
N4["Generic Collaboration<br/>cross-domain collective behavior"]
N5["Process or Function<br/>optionally specialized<br/>as interaction"]
N6["Specialized parent concepts<br/>Constraint → Requirement<br/>Contract → Business Object<br/>Gap → Assessment or Deliverable<br/>Representation → Data Object, Artifact, or Material"]
N7["Path in Common Domain<br/>realized by the relevant technology<br/>active structure element"]
N8["Association fallback<br/>only when no stronger valid relationship<br/>is known during conversion"]
N9["Specialization or aggregation<br/>between services<br/>Specialization: realizing → realized<br/>Aggregation: realized → realizing"]
N10["Multiplicity enrichment<br/>optional, mandatory, exact,<br/>or ranged participation on relationships"]
end
subgraph GOV["Migration governance"]
G1["Preserve provenance<br/>profile, attribute, tag,<br/>or migration register"]
G2["Semantic review<br/>keep, refactor, or retire<br/>the old distinction"]
G3["Relationship audit<br/>replace weak associations<br/>where a stronger relation is intended"]
G4["Validate repository value<br/>views, reports, impact analysis,<br/>and stakeholder readability"]
end
O1 --> N1
O2 --> N2
O3 --> N3
O4 --> N4
O5 --> N5
O6 --> N6
O7 --> N7
O8 --> N8
O9 --> N9
N1 --> G1
N2 --> G1
N3 --> G1
N4 --> G1
N5 --> G1
N6 --> G1
N7 --> G3
N8 --> G3
N9 --> G3
N10 --> G4
G1 --> G2
G2 --> G3
G3 --> G4
N1 -. "selectively add relationship constraints" .-> N10
N3 -. "ownership / responsibility cardinality" .-> N10
N4 -. "minimum participants" .-> N10
N7 -. "required realization pattern" .-> N10
The conversion stage answers: what is the ArchiMate 4 compatible form? This is where the official mappings are applied. The following table gives a practical migration map.
| ArchiMate 3.2 item | ArchiMate 4 migration target | Migration note |
|---|---|---|
| Business process, application process, technology process | Process, optionally specialized | Preserve originating type during transition if reports or views depend on it |
| Business function, application function, technology function | Function, optionally specialized | Review whether the old element was truly functional grouping or should become process |
| Business service, application service, technology service | Service, optionally specialized | Express provider, realization, interface, and consumer through relationships |
| Business event, application event, technology event, implementation event | Event, optionally specialized | Review triggering relationships and event source |
| Business role | Role | Decide whether to preserve business role as specialization or replace with more precise role taxonomy |
| Business collaboration, application collaboration, technology collaboration | Collaboration, optionally specialized | Review whether the collaboration is truly collective behavior or only grouping |
| Business interaction, application interaction, technology interaction | Process or function, optionally specialized | Choose process if sequence matters; choose function if grouping matters; model collective performance through collaboration or multiplicity |
| Constraint | Requirement specialization | Define requirement profiles for legal, technical, security, architecture, and operational constraints if useful |
| Contract | Business object specialization | Preserve contract attributes if contracts are architecturally relevant |
| Gap | Assessment or deliverable specialization | Use assessment for analytical finding; use deliverable for document or output |
| Representation | Data object, artifact, material, or specialization | Map according to whether the concern is logical data, deployable artifact, physical carrier, or business meaning |
| Path aggregating technology active structure | Path realized by active structure | Separate logical path from physical or technical realization |
| Invalid relationship | Association as temporary fallback | Replace with a stronger relationship where the intended meaning is known |
The semantic review stage answers: did the conversion preserve the architecture? This is where the model is inspected for meaning, not only conformance. A converted model may validate under ArchiMate 4 and still be weak. For example, a generic process without an assigned performer may be formally acceptable in some abstract contexts, but operationally incomplete if the original model showed that it was an application process. A generic service without realization may be visually acceptable, but analytically incomplete if it is supposed to support impact analysis. A business object converted from contract may lose important contract semantics if no specialization or attributes are preserved.
The review should focus first on the concepts most likely to lose meaning. Removed elements deserve priority. Constraints, contracts, gaps, representations, and interactions were removed because they can be represented more cleanly, but existing models may have used them for specific governance purposes. Those purposes should be preserved where valid.
Behavior elements are the second priority. The motivation paper argues that no meaning is lost when layer-specific behavior concepts are merged into a generic set, because a business actor assigned to a business process has the same basic meaning as a business actor assigned to a generic process: some actor performs some work.132 That argument is valid at the metamodel level. At repository level, however, old element types may have carried reporting or stakeholder meaning. The migration should preserve that meaning where needed, then gradually replace it with better relationships and profiles.
The relationship audit stage answers: are the arrows still meaningful? This is probably the most important stage after concept conversion. ArchiMate 4 makes relationships more important because many elements are now more generic. If behavior, role, collaboration, service, and path are generic, then assignment, realization, serving, access, triggering, flow, aggregation, composition, specialization, and association must be used carefully.
The audit should start with invalid relationships. The specification allows replacing invalid relationships with association, but association is weak. It only says that some relation exists. If a migration tool changes many relationships into associations, the repository may lose analytical strength. Every replaced relationship should therefore be reviewed and classified: was the intended meaning serving, assignment, realization, access, flow, triggering, aggregation, composition, path realization, or genuinely unspecified association?
The audit should also examine automation patterns inherited from ArchiMate 3.2. The motivation paper explains that ArchiMate 3.2 often required a duplicated pattern to show partial automation: a business process, an application process realizing it, and an application component assigned to the application process. ArchiMate 4 can model this more directly as a generic process assigned to the relevant performers.133 Migration is an opportunity to remove such artificial duplication. The target should not always be a one-to-one element replacement. Sometimes the correct target is a simpler graph.
Path relationships need a specific audit. In ArchiMate 4, path belongs to the Common Domain, and the old aggregation from path to technology internal active structure is replaced by realization from active structure element to path.134 This is a semantic correction. The migration team should not merely reverse a connector. It should ask whether the old path represented a logical exchange relation, a physical communication network, a distribution network, or a diagrammatic container. The converted model should separate logical path from physical realization.
The view refactoring stage answers: do stakeholders still understand the architecture? ArchiMate 4 changes not only the metamodel but also the visual grammar. The term layer is replaced by domain, the old matrix representation is replaced by the ArchiMate Hexagonion, and generic concepts appear in the Common Domain. Existing diagrams may therefore remain technically valid but become harder to read if they rely on old color conventions and layer-specific element names.
View refactoring should be done by stakeholder concern. Executive views may need little change beyond updated terminology. Architecture governance views may need explicit profile legends. Application cooperation views may need to show assignment and realization more clearly because services and functions are now generic. Security and OT views may benefit from path as a logical exchange element and from explicit realization by boundary components. Data views may benefit from relationship multiplicity, but only where cardinality is architecturally meaningful.
Refactoring should not overload diagrams with every migration detail. The repository may preserve old element provenance through profiles or attributes, but not every view must show it. A migration view for architects may display specializations and old to new mappings. A stakeholder view may show only the cleaned architecture. This separation is important. Migration metadata belongs in the repository; stakeholder diagrams should remain readable.
The validation stage answers: does the migrated repository still serve its purposes? This is the test that matters. A migrated repository should be checked against real use cases. Can it still answer which applications support which business capabilities? Can it still show which processes depend on which services? Can it still trace requirements to architecture elements and deliverables? Can it still identify services without realization? Can it still support product, contract, and obligation views if those existed? Can it still compare baseline and target plateaus? Can it still support impact analysis when an application, node, path, data object, supplier, or facility changes?
If the answer is no, the migration has preserved notation but lost architecture knowledge.
A practical validation checklist should include at least the following areas.
| Validation area | Question |
|---|---|
| Semantic preservation | Were old meanings preserved through profiles, attributes, or explicit refactoring? |
| Relationship quality | Were invalid relationships reviewed rather than blindly converted to association? |
| Behavior clarity | Are generic processes, functions, services, and events connected to performers, realizations, consumers, and triggers where needed? |
| Role clarity | Are roles defined as purposes or responsibilities, not merely labels? |
| Collaboration clarity | Do collaborations represent collective behavior, not arbitrary groupings? |
| Removed element cleanup | Were constraints, contracts, gaps, representations, and interactions mapped according to actual intent? |
| Path correctness | Are logical paths separated from communication or distribution networks and their realizations? |
| View readability | Do stakeholder views remain intelligible after domain and Common Domain changes? |
| Report continuity | Do critical reports and dashboards still work? |
| Tool exchange | Are profiles, attributes, specializations, relationships, and multiplicity preserved across export and import? |
Tooling deserves separate attention. A migration will depend heavily on tool support for ArchiMate 4, specialization profiles, attributes, relationship validation, multiplicity, and exchange. The motivation paper notes that conversion with specialization profiles requires tool support, and that a future version of the ArchiMate Model Exchange File Format was expected to add support for exchanging specialization profiles.135 This matters because a migration strategy that works in one tool may lose meaning in another if profiles or custom metadata are not exchanged reliably.
Therefore, tool validation should include import and export tests. Create a representative test package with migrated behavior elements, removed concept specializations, profiles, attributes, multiplicity, path realization, and relationship derivations. Export it. Import it into the same tool and, if relevant, into another tool. Check whether the semantics survive. If profiles become plain labels, colors, or lost metadata, the enterprise should not rely on them for critical governance until the tool chain is corrected.
The migration should also include a governance decision on specialization. ArchiMate 4 allows organizations to preserve old distinctions as specializations, but not every old distinction should become a permanent specialization. For example, preserving Business Process, Application Process, and Technology Process as specializations of process may be useful during migration. But after review, the enterprise may prefer new profiles such as Manual Process, Automated Process, AI Assisted Process, Operational Process, or Control Process. These may correspond better to actual governance concerns than the old layer distinction.
The same applies to role and collaboration. Instead of mechanically preserving Business Role or inventing Application Role and Technology Role by analogy, an organization may define roles such as Accountable Role, Responsible Role, Policy Decision Point, Policy Enforcement Point, System of Record, Data Owner, Remote Service Provider, Control Authority, and Automated Assessor. The point is not to reproduce ArchiMate 3.2 inside ArchiMate 4. The point is to use ArchiMate 4 to create a cleaner enterprise modeling practice.
Multiplicity should be treated as an enrichment step, not as a mandatory migration step. ArchiMate 3.2 models generally will not contain multiplicity because the feature was introduced in ArchiMate 4. The motivation paper identifies multiplicity as the most important new feature and gives use cases such as data model constraints, multiple process instances, server clusters, and mandatory realization of services.136 A migration can therefore add multiplicity selectively where it improves governance.
Good candidates include ownership rules, resilience rules, completeness rules, and mandatory realization rules. For example, every critical service must be realized by at least one process or function. Every regulated data object must have exactly one accountable owner. Every critical application service must be deployed in at least two locations. Every remote maintenance path must be realized by approved boundary components. These are architecture rules, not decorative cardinalities.
However, multiplicity should not be added everywhere. If the migration team tries to annotate every possible relationship, the repository will become noisy and harder to maintain. Multiplicity should be used where cardinality affects decisions, controls, compliance, resilience, ownership, or architecture validation.
There should also be a baseline freeze before migration. A repository migration changes the language of record. Before conversion, export the ArchiMate 3.2 repository, archive the tool version, capture key reports, and preserve reference diagrams. This is not bureaucracy. It is the only way to verify whether the migrated repository preserves meaning. Without a baseline, the team cannot compare before and after.
A parallel run is also useful. For a period, maintain the old repository as read only and conduct migration in a separate branch or environment. Use representative models first: one business architecture model, one application cooperation model, one technology or infrastructure model, one transformation roadmap, one product or service model, one security or resilience model, and one complex cross domain model. These test cases will expose most migration problems before the full repository is converted.
The migration should also include stakeholder communication. Users familiar with ArchiMate 3.2 may be confused when business process, application process, and technology process all become process, or when business role becomes role, or when interaction disappears. They may think meaning has been lost. The migration should explain that the meaning is now expressed through assignment, realization, specialization, attributes, and relationships. This is a conceptual change, not only a tool upgrade.
Training should therefore focus less on what changed in the menu and more on how to model correctly in the new language. Modelers should learn how to express human and machine execution through assignment, how to model mixed collaboration, how to distinguish process from function, how to represent old contracts and constraints through specializations, how to use path as logical exchange, how to avoid association overuse, and how to apply profiles.
A migration governance board or working group should be created for significant repositories. It should include enterprise architects, repository administrators, tool experts, domain architects, and representative users. Its role is to approve mapping rules, profile definitions, validation rules, migration exceptions, and deprecation decisions. This avoids local teams inventing incompatible migration patterns.
One of the hardest questions is how much old modeling style to preserve. There are three possible strategies.
The conservative strategy preserves old distinctions as specializations. This reduces disruption and protects existing reports, but it may carry old conceptual debt into ArchiMate 4.
The radical strategy converts everything to generic concepts and removes old distinctions. This creates a clean ArchiMate 4 repository, but it risks losing meaning and confusing users.
The disciplined strategy preserves old distinctions temporarily, reviews them, and then either retires them or replaces them with better enterprise profiles. This is the best strategy for most organizations. It uses specialization profiles as a transition mechanism, not as a museum of old language constructs.
The migration should also classify diagrams and models by criticality. Not every diagram deserves the same effort. Some diagrams are archival or illustrative. Some support governance, investment decisions, regulatory analysis, operational resilience, or transformation planning. High value models should be semantically reviewed. Low value diagrams may be converted mechanically or retired. Migration is an opportunity to reduce repository clutter.
This is important because many architecture repositories contain obsolete or low quality models. A migration project should not spend equal effort on every artifact. It should first identify models that are actively used, referenced by governance processes, linked to strategic decisions, or consumed by stakeholders. Those models deserve careful migration. Unused models may be archived before conversion.
The migration should therefore include repository hygiene. Remove duplicate elements. Merge inconsistent concepts. Fix naming. Replace vague associations. Correct old workarounds. Retire obsolete views. Reconcile elements representing the same application, process, service, or data object. Add missing relationships where critical. ArchiMate 4 is a good moment for cleanup because the language change already requires review.
The relationship with other modeling languages should also be reviewed. The motivation paper emphasizes that ArchiMate is designed for communication and should collaborate with specialized languages rather than absorb their scope. It explicitly compares ArchiMate with BPMN and UML in the context of behavior modeling.137 Migration is therefore a good moment to decide where ArchiMate stops. Detailed process execution should remain in BPMN or process tools. Detailed software design should remain in UML, code, API specifications, or service catalogs. Detailed data modeling should remain in data modeling tools. ArchiMate should provide the enterprise level semantic map and links to those detailed sources.
This is particularly relevant because ArchiMate 4’s generic behavior concepts may make it easier to map to BPMN or UML. But easier mapping does not mean duplication. The enterprise should define traceability rules: which ArchiMate processes link to BPMN models, which application components link to service catalogs or repositories, which data objects link to data catalogs, which technology elements link to CMDB or cloud inventory, and which requirements link to control frameworks. This turns migration into a step toward a richer architecture knowledge base.
There is also an evidence dimension. After migration, the repository should not remain purely manual. Many ArchiMate elements should be linked to operational sources of truth: application portfolio, CMDB, cloud inventory, IAM, API catalog, data catalog, deployment pipeline, vulnerability scanner, contract repository, project portfolio, and observability data. ArchiMate 4’s simplification makes this more important because the model is increasingly a semantic layer rather than a complete detailed description. The model says what the architecture intends. Evidence systems say what is actually implemented.
Path is a good example. The migrated repository may define approved logical paths. Network flow data, firewall policy, IAM logs, API gateway logs, or OT access logs can verify whether actual connectivity conforms. Services are another example. The model may define mandatory realization. Application and service catalogs can verify whether the service is implemented. Data ownership is another. The model may define exactly one owner. Data governance tooling can verify whether ownership exists.
This is beyond basic migration, but it is where the migrated repository gains strategic value. A migrated ArchiMate 4 model should not only be prettier. It should be more governable.
A practical migration roadmap could look like this.
| Phase | Objective | Main output |
|---|---|---|
| 1. Baseline freeze | Preserve the ArchiMate 3.2 repository before conversion | Archived repository, tool version, key diagrams, key reports |
| 2. Impact inventory | Identify affected concepts, relationships, views, reports, and integrations | Migration impact register |
| 3. Mapping design | Define official ArchiMate 4 mapping rules and enterprise specific refinements | Migration mapping table and profile catalog draft |
| 4. Pilot conversion | Convert representative models and test tool behavior | Pilot repository and issue log |
| 5. Semantic review | Validate meaning, relationships, specializations, and stakeholder readability | Approved modeling patterns and cleanup rules |
| 6. Repository conversion | Apply conversion to active repository scope | Migrated ArchiMate 4 repository |
| 7. Relationship audit | Replace weak fallback associations and validate path, behavior, role, and collaboration semantics | Relationship quality report |
| 8. View refactoring | Update diagrams, legends, viewpoints, and stakeholder views | Refactored view library |
| 9. Validation | Rebuild reports and test key use cases | Acceptance report |
| 10. Governance rollout | Train users and enforce new modeling rules | Updated method, training, validation rules |
This sequence is deliberately more demanding than a tool upgrade. That is because the migration is not only technical. It changes the semantics of the architecture language. The cost of doing it superficially is not a failed import. The cost is a repository that looks compliant but no longer supports serious architecture work.
The final acceptance criteria should therefore be architectural, not only technical. The migration is successful when the repository can still answer the questions it was meant to answer, when old meanings have either been preserved or consciously retired, when relationships are stronger rather than weaker, when stakeholder views remain readable, when customization is governed, when reports still work, and when the new ArchiMate 4 constructs are used to reduce artificial duplication.
In short, the practical migration from ArchiMate 3.2 to ArchiMate 4 should be understood as a controlled semantic refactoring. The official transformations provide the minimum path to conformance. A mature enterprise architecture practice should go further: preserve provenance, review meaning, clean old modeling workarounds, define profiles, audit relationships, refactor views, validate reports, and connect the repository to evidence.
The objective is not merely to make ArchiMate 3.2 diagrams legal in ArchiMate 4. The objective is to use the migration to improve the semantic quality of the architecture repository.
The architectural impact of ArchiMate 4 is deeper than the number of changed concepts suggests. It is not only that some boxes disappear, some boxes become generic, and some arrows receive multiplicity. The real impact is that ArchiMate 4 changes where meaning is expected to live in an architecture model. Less meaning is carried by layer-specific element names. More meaning is carried by relationships, assignments, realization structures, profiles, attributes, viewpoints, and repository rules.
This is the most important practical consequence for enterprise architects. ArchiMate 4 gives the modeler fewer primitive choices, but it also removes several shortcuts. In ArchiMate 3.2, a modeler could say this is an application process because the element type said so. In ArchiMate 4, the element is a process. The model must show why it is application related. Is it assigned to an application component? Does it realize or expose a service? Does it access a data object? Is it part of an application cooperation view? Does it carry a specialization profile inherited from the old application process concept? The answer must be in the model, not only in the label.
This is a significant shift. The standard becomes more compact, but the modeling act becomes more explicit. The architect must express the reason for a classification rather than relying on the element type to carry it implicitly. This is more rigorous, but it also exposes weak modeling habits. A repository that was built mainly as a set of colored boxes may become less informative after migration. A repository built as a typed semantic graph will become stronger.
The Open Group motivation paper states the intended benefits directly. The reduced number of concepts should make the language easier to understand for new users. The resulting models should be smaller and less complex. Mapping between ArchiMate processes and more detailed BPMN or UML activity models should become more natural. The decision about whether behavior is manual, automated, or mixed can be postponed to a later design stage. The new structure supports collaborative execution across domains, including human and machine combinations. It also allows non human actors to be assigned to roles, which the paper explicitly connects to the age of AI.138
Those benefits are real. They correspond to practical problems in contemporary architecture work. Many enterprise processes are not purely manual or purely automated. Many capabilities are delivered by hybrid structures made of people, applications, platforms, data, infrastructure, equipment, suppliers, and AI services. Many architectural decisions are made before the exact execution mode is known. A language that forces the architect to decide too early whether behavior is business, application, or technology behavior adds artificial precision. ArchiMate 4 removes part of that artificial precision.
The architectural gain is delayed commitment. An architect can model that a process exists before deciding whether it is performed by a human role, an application component, a robot, a control system, a supplier, an AI assistant, or a collaboration of several of these. That is closer to how architecture should work. Early architecture should preserve option space. Later design should allocate execution. A language that supports this sequence is better aligned with real transformation work.
This is especially important for digital transformation. In many programs, the initial question is not which application process realizes this business process? The initial question is what behavior must the enterprise be able to perform? Only after that come questions about automation, outsourcing, platform reuse, data availability, control, and operating model. ArchiMate 4 lets the architecture model follow that reasoning order more cleanly.
The second impact is that ArchiMate 4 makes hybrid execution easier to model. The motivation paper gives the example of an AI-powered application for analyzing insurance claims that collaborates with human employees in a claim handling process. The automated claims assessor may adjudicate standard claims, while high risk claims require a senior legal specialist.139 This example is simple, but it represents a broad class of modern architectures. Humans and machines no longer sit in separate layers. They perform behavior together, under rules, exceptions, and accountability constraints.
In ArchiMate 3.2, such a case could be modeled, but often with awkward duplication. ArchiMate 4 gives a cleaner structure: one generic process, roles fulfilled by human and non human active structures, collaboration where collective execution matters, and explicit relationships to services, data, requirements, and accountability specializations. The model becomes less like a layer diagram and more like a semantic description of work.
The same pattern applies outside AI. A manufacturing process may be performed by workers, robots, MES, ERP, PLCs, sensors, and equipment. A remote maintenance process may be performed by field technicians, remote service providers, diagnostic tools, jump hosts, network components, and physical assets. A cybersecurity incident process may involve analysts, SIEM, SOAR, identity systems, endpoint agents, network controls, and external responders. A supply chain process may involve business actors, application components, facilities, distribution networks, materials, and suppliers. ArchiMate 4 is structurally better suited to these cases because role, collaboration, behavior, and path are no longer trapped inside old layer boundaries.
The third impact is a stronger distinction between responsibility and accountability. Generic role allows non human active structures to fulfill roles. That is useful, but potentially dangerous if misread. The motivation paper explicitly warns that assigning non human actors to roles does not imply that machines become legally accountable. Roles can model responsibility for performing tasks, while responsibility and accountability are different notions.140
This is more than a note on AI ethics. It has direct modeling consequences. A process may be performed by an AI component, but accountability may remain with a business actor or organizational role. A policy decision point may be implemented by an application component, but the accountable policy owner may be a human or organizational unit. A control system may execute a safety action, but operational accountability may remain with the plant operator or owner. ArchiMate 4 can model these distinctions if the architecture practice defines clear role specializations and relationship rules. If it does not, generic role may create ambiguity.
The fourth impact is that relationship quality becomes the primary determinant of model quality. Since behavior elements are generic, role is generic, collaboration is generic, path is common, and removed concepts move into specializations, the model’s truth increasingly depends on its relationships. The ArchiMate 4 Specification defines the language as an integrated approach across domains and dependencies, with serving and realization relationships playing central roles between domains, and with stakeholder oriented views over an underlying model.141
This means the modeler must be precise. Assignment is not serving. Serving is not realization. Flow is not triggering. Path is not communication network. Grouping is not collaboration. Association is not a substitute for every uncertain relationship. If relationships are chosen badly, the model may still look acceptable, but analysis will be unreliable.
This is one of the largest architectural impacts of the new version. ArchiMate 4 will punish weak repository practice more visibly. A generic process without assignment, realization, trigger, accessed object, or service relation says little. A generic role without a fulfilling active structure says little. A path without connected structures or realization says little. A collaboration without participants says little. The new language is simpler, but it expects the model graph to do more work.
The fifth impact is that architecture repositories must become more governed. ArchiMate 4 gives fewer standard primitives and relies more heavily on customization mechanisms. The specification explicitly supports language customization through attributes, profiles, and specialization of concrete concepts, while preserving the underlying definition of the generalized concepts.142 This is the mechanism that prevents simplification from becoming loss of precision. But it only works if the enterprise governs it.
A repository without a profile catalog will drift. One team may model contracts as business objects with names. Another may use a Contract specialization. Another may use artifacts. One team may use AI Assisted Process, another Automated Process, another only generic process. One team may model accountability as a role, another as an attribute, another as a requirement. The standard remains clean, but the enterprise model becomes inconsistent.
Therefore, ArchiMate 4 increases the importance of local modeling standards. The enterprise architecture function must define which specializations are approved, which attributes are mandatory, which relationships are allowed in local practice, which viewpoints expose which profile information, and how migration from ArchiMate 3.2 is handled. The language is smaller, but governance cannot be smaller.
The sixth impact is that architecture analysis can become more powerful if the repository is managed correctly. Generic concepts plus typed relationships are well suited to queries. Instead of asking for all application processes, the repository can ask for all processes assigned to application components. Instead of asking for all business services, it can ask for all services provided by business actors or roles. Instead of asking for all technology interactions, it can ask for all processes or functions assigned to collaborations containing technology active structures. This is analytically cleaner because it follows the semantics of the model rather than a fixed taxonomy.
The same applies to impact analysis. Which capabilities are affected by this application component? Which services depend on this path? Which data objects are accessed by processes performed by external providers? Which roles are fulfilled by non human actors? Which critical services lack mandatory realization? Which remote maintenance paths are not realized through approved boundary components? These are graph queries. ArchiMate 4 is better positioned for this type of query if the relationships and profiles are modeled consistently.
Multiplicity strengthens this analytical direction. It allows relationships to express optionality, mandatory participation, minimum redundancy, maximum participation, and uniqueness. The motivation paper identifies multiplicity as an important new feature, initially motivated by data architecture but also useful for process instances, server clusters, and mandatory service realization.143 In practice, this allows the repository to move from descriptive diagrams toward checkable architectural rules.
For example, a model can express that every critical service must be realized by at least one process or function, that every regulated data object must have exactly one accountable owner, that a critical platform must be deployed in at least two locations, or that a remote access process must involve at least two roles. These are not only diagram annotations. If stored and governed as model semantics, they become validation rules.
The seventh impact is that ArchiMate 4 makes the boundary between architecture model and operational evidence more important. A model can express intent. It cannot by itself prove that the implemented enterprise conforms to that intent. If a model says that a service has two realizations, the deployment environment must confirm it. If a model says that a data object has one accountable owner, the data governance system must confirm it. If a model says that a remote maintenance path is realized through an approved boundary, network flows, firewall rules, identity logs, and access records must confirm it.
This is where enterprise architecture can evolve. ArchiMate 4 should not be used only to produce diagrams. It should be used as a semantic layer over implementation evidence. The model states what the enterprise believes, intends, or requires. Operational repositories show what actually exists. The gap between them is a governance signal.
The eighth impact is that viewpoint design must change. In ArchiMate 3.2, many views could rely on layer-specific element types and colors. In ArchiMate 4, a view may contain several Common Domain elements whose domain relevance is shown through relationships or profiles. This means diagrams may need clearer legends, better naming, explicit relationships, and selective display of specializations or attributes.
The ArchiMate 4 Specification distinguishes model concepts from notation and supports stakeholder oriented views.144 This becomes more important under the new language. The underlying repository may contain rich profile and relationship semantics, but each view must expose only what matters for the stakeholder concern. An executive view may not need to show whether a process originated from business process or application process. A migration view may need exactly that. A security view may need to show role specializations, path realization, and multiplicity constraints. A data governance view may need ownership attributes and realization chains.
Thus, ArchiMate 4 pushes architecture practice toward a clearer separation between repository semantics and diagram communication. The repository can be rich. The diagram must be selective. This is healthy. It prevents diagrams from becoming overloaded while still preserving analysis capability.
The ninth impact is on migration and model quality. ArchiMate 4 should not be seen merely as a new syntax to which old models must conform. It is an opportunity to remove conceptual debt. The motivation paper says that without housekeeping, legacy and conceptual debt would be dragged forward indefinitely, burdening users with more baggage.145 Migration should therefore be used to review whether old models contained artificial duplication, weak interactions, vague gaps, unclear constraints, inappropriate representations, or overuse of association.
This is a useful forcing function. Many repositories contain historical modeling compromises. Some business processes exist only because the old language required a place for automated behavior before it could be connected to applications. Some gaps represent documents, others findings, others missing work. Some representations are really data objects or artifacts. Some interactions are really processes or functions. ArchiMate 4 forces these distinctions to be revisited.
The tenth impact is on the role of the enterprise architect. The architect becomes less a selector of predefined boxes and more a designer of semantic structure. The work shifts from choosing business process versus application process toward modeling behavior, performers, services, roles, paths, accountability, requirements, evidence, and transformations explicitly. This is a better use of architectural skill.
The modeler must now ask harder questions. What behavior exists independently of current automation? Which active structures perform it? Which services expose it? Which paths support its exchange? Which roles are operational responsibilities and which are accountability roles? Which distinctions are important enough to preserve through profiles? Which relationships are asserted and which are derived? Which cardinalities are architectural constraints? Which parts of the model are intentional, and which are evidence based?
These questions are closer to real architecture work than simply deciding which colored element to draw.
The eleventh impact is that ArchiMate 4 is better aligned with complex, distributed, and cyber-physical systems, but it still does not solve their complexity by itself. The motivation paper explains that the Technology Domain remains rich because it must cover both information technology and physical technology, bits and atoms, and because physical concepts are important for use cases such as operational resilience, Industry 4.0, robotization, digital twins, and defense.146 This is important. ArchiMate 4 does not abandon physical architecture. It simplifies where redundancy existed, but keeps concepts needed for physical and operational reality.
This balance matters. A language that becomes too abstract would be useless for OT, energy, manufacturing, logistics, defense, healthcare, and infrastructure. A language that models every technical detail would become unusable. ArchiMate 4 tries to stay in the middle: enough physical and technology vocabulary to represent enterprise level dependencies, but not enough to replace engineering tools.
The twelfth impact is that ArchiMate 4 makes the risk of false simplicity more visible. Because the language is cleaner, models can look cleaner. But a cleaner model is not automatically a truer model. If the simplification hides execution allocation, accountability, realization, data access, security boundaries, or supplier responsibility, it is harmful. If the simplification removes redundant elements while strengthening relationships and governance, it is beneficial.
This is the practical test for ArchiMate 4 adoption. Does the new model answer more architecture questions with less clutter? Or does it answer fewer questions with fewer boxes? The first is simplification. The second is loss.
The architectural impact can therefore be summarized as a tradeoff. ArchiMate 4 reduces cognitive load and redundancy at the language level. It increases the importance of modeling discipline at the practice level. It lowers the barrier to entry for new users, but raises the standard for repository governance if the organization wants serious analysis. It makes early architecture more flexible, but requires later refinement through assignment, realization, specialization, multiplicity, and evidence. It supports cross domain human and machine execution, but requires explicit responsibility and accountability modeling.
For organizations that use ArchiMate mainly for occasional communication diagrams, the impact will be moderate. They will see fewer concepts, new terminology, a new visual structure, and some migration work. For organizations that use ArchiMate as an architecture repository, the impact is much larger. They must redesign modeling standards, migration rules, profile catalogs, validation rules, viewpoint conventions, reports, and possibly tool integrations.
The final judgment is that ArchiMate 4 is architecturally healthy if it is adopted as a semantic refactoring, not as a cosmetic update. The language becomes smaller because several distinctions were better expressed through relationships, profiles, and context. But the enterprise still needs those distinctions where they matter. The model must become more relational, more governed, and more connected to evidence.
In that sense, the main architectural impact of ArchiMate 4 is not simplification alone. It is a transfer of responsibility. The standard removes conceptual debt from the shared language. The enterprise architecture practice must now prevent that debt from reappearing as uncontrolled local profiles, vague generic elements, weak associations, and diagrams detached from implementation evidence.
Used well, ArchiMate 4 can produce smaller models with higher semantic quality. Used poorly, it can produce cleaner diagrams with less architectural content. The difference will not be in the specification. It will be in the discipline of the architecture practice.
The changes in ArchiMate 4 are significant, but they should not be misread as a change in the identity of the language. ArchiMate 4 is still ArchiMate. It remains a visual modeling language for Enterprise Architecture, intended to describe, analyze, and communicate architectures across stakeholders, domains, and transformation states. The new specification simplifies and normalizes parts of the metamodel, but it does not turn ArchiMate into a different kind of language.
This point matters because a release that removes elements, merges behavior concepts, replaces layers with domains, introduces the Common Domain, and adds multiplicity may appear more radical than it is. The deepest continuity is purpose. ArchiMate remains a language for communicating architecture. The ArchiMate 4 Specification continues to present it as a language for representing Architecture Descriptions, supporting stakeholder oriented views, and distinguishing the conceptual model from its visual notation.147
The Open Group motivation paper makes the same continuity explicit through the ArchiMate Manifesto. The language is still guided by simplicity over comprehensiveness, needs of the many over wants of the few, collaboration over coverage, people over tools, and communicating architecture over other use cases.148 ArchiMate 4 does not abandon those principles. It enforces them more strictly. The cleanup is not a departure from the language’s purpose. It is an attempt to return to it.
The most important thing that did not change is that ArchiMate is not a detailed design language. It does not become BPMN, UML, SysML, a data modeling notation, a cloud architecture DSL, a process execution language, a network engineering tool, or a simulation environment. It remains an enterprise architecture language. Its abstraction level is deliberately higher. It is meant to show architecturally relevant structures, behaviors, motivations, dependencies, and transformation elements, not every implementation detail.
This is exactly why the principle of collaboration over coverage remains important. The motivation paper states that if a need is already sufficiently covered by another modeling language, the preferred approach is to map to that language rather than absorb those features into ArchiMate. It explicitly mentions detailed software design in UML as an example.149 This is not a minor methodological preference. It is one of the reasons ArchiMate 4 can simplify. The language does not need to become universal because it can coexist with more specialized languages.
The same logic applies to process modeling. ArchiMate 4 makes it easier to map a high-level process to BPMN, because process is now generic rather than divided into business, application, and technology variants. But ArchiMate still does not replace BPMN. The ArchiMate 4 Specification explicitly notes that a process element can depict high-level processes, end-to-end processes, macro flows, workflows, and automated processes, while detailed activity flows are typically modeled in BPMN.150 The boundary remains: ArchiMate models architecture level behavior; BPMN can model detailed process logic.
The same applies to software architecture. ArchiMate application components, services, interfaces, data objects, and collaborations can describe enterprise level application structure and cooperation. They do not replace code, API specifications, UML class diagrams, sequence diagrams, deployment descriptors, service meshes, or software architecture decision records. ArchiMate can link to these artifacts, but it should not absorb their level of detail.
The second major continuity is the aspect grammar of the language. ArchiMate 4 still uses the fundamental distinction between active structure, behavior, and passive structure. The specification still explains these aspects through a natural language analogy: active structure elements are like subjects, behavior elements are like verbs, and passive structure elements are like objects.151 This is one of the conceptual anchors of ArchiMate, and it remains intact.
What changes is not the grammar itself, but how some vocabulary is organized inside it. Behavior is now more generic. Role and collaboration are now common. Path is now common. Some specializations are removed from the primitive language. But the basic architectural sentence remains: something active performs behavior on or with something passive, under motivations, through relationships, and across domains.
This continuity is important because it prevents a common misunderstanding. ArchiMate 4 does not dissolve the language into generic boxes. It still has a structured ontology. Active structure elements still represent entities capable of performing behavior. Behavior elements still represent what happens or is done. Passive structure elements still represent objects on which behavior is performed. Motivation elements still express why the architecture exists or changes. Implementation and Migration elements still express transformation. Relationships still define how everything connects.
The third continuity is that relationships remain central. ArchiMate 4 simplifies the element vocabulary, but it does not simplify relationship semantics away. On the contrary, the language still depends on structural, dependency, dynamic, and other relationships. A conforming implementation must still support relationships, domains, cross domain dependencies, and the normative relationship tables in Appendix B.152 The model remains a typed graph, not a free drawing.
This means that the architectural discipline of ArchiMate does not disappear. Assignment still means that active structure is assigned to behavior, storage, or responsibility. Realization still relates more concrete elements to more abstract elements. Serving still represents functionality provided to another element. Access still concerns behavior or active structure acting on passive structure. Triggering still represents temporal or causal precedence. Flow still represents transfer. Aggregation and composition still represent whole and part structures. Specialization still represents a more specific concept inheriting from a more general one.
ArchiMate 4 therefore does not reduce the need to understand relationship semantics. It increases it. But the underlying relationship model remains one of the language’s continuities.
The fourth continuity is that ArchiMate still supports multiple architecture domains and cross domain modeling. The word layer changes to domain, and the new Hexagonion replaces the old layered matrix as the main depiction. But the language still covers business, application, technology, motivation, strategy, and implementation concerns. The ArchiMate 4 Specification defines the core language as Common, Business, Application, and Technology Domains, with Motivation, Strategy, and Implementation and Migration extending the full language.153
This means that ArchiMate remains an integrated enterprise architecture language. It still connects strategic intent to capabilities, capabilities to behavior, behavior to services, services to applications and technologies, technologies to physical structures, and transformation work to target states. The vocabulary is reorganized, but the architecture scope remains broad.
The fifth continuity is that ArchiMate remains compatible with TOGAF without becoming TOGAF. TOGAF and ArchiMate remain complementary. TOGAF provides an architecture framework, method, governance approach, and content structure. ArchiMate provides a modeling language. The ArchiMate 4 Specification continues to use the TOGAF definition of enterprise and still positions ArchiMate as a language for describing Enterprise Architectures, not as a replacement for the architecture method itself.154
This matters because ArchiMate 4’s move from layers to domains could be misread as a stronger alignment with TOGAF domains. There is alignment, but not identity. The motivation paper notes that TOGAF uses architecture domain in a similar way, but ArchiMate has its own domain structure: it matches Business and Technology, combines application and data concerns in the Application Domain, and adds Common, Motivation, Strategy, and Implementation and Migration Domains.155 ArchiMate remains its own language.
The sixth continuity is that ArchiMate still does not define a separate Data Domain. This is worth stating because multiplicity was introduced partly because Data Architects needed more cardinality expressiveness, and because the move from layers to domains may invite comparison with TOGAF’s data domain. The ArchiMate 4 Specification still says that it does not define a specific information or data domain. Instead, information modeling is supported through passive structure elements across domains, including business objects, data objects, and artifacts.156
This does not mean data is unimportant. It means ArchiMate treats data and information through their architectural context rather than as a separate domain in the language structure. Business meaning can be modeled through business objects. Logical or application level information can be modeled through data objects. Deployable or physical IT realizations can be modeled through artifacts. This remains the ArchiMate approach.
The seventh continuity is that technology remains broader than IT infrastructure alone. ArchiMate 4 still supports both information technology and physical technology. The motivation paper explains that the Technology Domain still includes both bits and atoms and that physical technology concepts remain important for operational resilience, Industry 4.0, robotization, digital twins, defense, and other physical enterprise contexts.157 This continuity is important because it confirms that ArchiMate 4 is not retreating into abstract business and application modeling. It still supports cyber-physical architecture.
The eighth continuity is that language customization remains part of the standard. ArchiMate 4 makes customization more important, but customization itself is not new in spirit. The specification continues to support attributes, profiles, and specialization of concepts.158 What changes is the practical weight of these mechanisms. Because some primitive concepts have been removed or merged, profiles and specializations now carry more responsibility. But the language still provides formal mechanisms for controlled extension.
The ninth continuity is that ArchiMate still separates the model from its notation. A concept is not identical to its icon, color, or diagram placement. The specification still allows visual conventions, but colors do not have formal semantics.159 This is particularly relevant in ArchiMate 4 because many Common Domain elements may be displayed differently depending on view and profile. The semantic model must remain stronger than the diagram appearance.
This is a crucial point for migration. If an organization relied heavily on color to distinguish business, application, and technology behavior, ArchiMate 4 may feel like it removes meaning. But color was never the formal source of meaning. The model should carry meaning through concepts, relationships, attributes, and profiles. The diagram should communicate that meaning selectively.
The tenth continuity is that ArchiMate still supports abstraction through relationships and views, not through a simplistic vertical hierarchy. The motivation paper stresses that the old layers were not abstraction layers, and that abstraction in ArchiMate is handled through relationships such as realization, assignment, composition, and aggregation.160 ArchiMate 4 makes this clearer by replacing layers with domains, but the principle was already present. The new version corrects the visual metaphor more than the fundamental semantics.
This is important because some users had long used the old Business, Application, and Technology Layers as if they were conceptual, logical, and physical abstraction layers. The motivation paper explicitly rejects that interpretation. A business actor is not realized by an application component. A business process is not automatically a conceptual abstraction of an application process. ArchiMate 4 makes this misunderstanding harder to maintain, but the underlying principle did not suddenly appear in version 4.
The eleventh continuity is that ArchiMate still requires viewpoint discipline. The language is designed to support different stakeholders and concerns through views. ArchiMate 4 does not change the fact that a single model can support many views, each selecting the relevant concepts and relationships for a concern. The cleaner metamodel does not remove the need to design views carefully. If anything, it reinforces it.
A CIO, security architect, business architect, data architect, platform architect, OT architect, product owner, and transformation manager do not need the same diagram. The underlying repository may be shared, but the view must be shaped by the concern. This remains central to ArchiMate.
The twelfth continuity is that ArchiMate still does not model reality completely. It remains a selective abstraction. It can describe architecture intent, dependencies, structure, behavior, motivation, and transformation. It cannot by itself prove that the implemented enterprise conforms. That was true in ArchiMate 3.2, and it remains true in ArchiMate 4.
This matters because the cleaner language may create a false sense of control. A model can state that a path is approved, that a service is realized, that a process is assigned, or that a data object has an owner. Operational evidence must still confirm whether this is true in reality. ArchiMate remains an architecture model, not an automatic inventory, runtime telemetry system, compliance engine, or digital twin.
The thirteenth continuity is that ArchiMate remains a communication language before being a technical execution language. The motivation paper explicitly says that understandability is key and that the language was designed for communication among human users rather than technical usage.161 ArchiMate 4 does not change this. Even with multiplicity and stronger relationship semantics, it remains primarily a human scale architecture language.
This is a strength and a limit. It is a strength because enterprise architecture needs shared understanding across heterogeneous stakeholders. It is a limit because complex systems cannot be governed by diagrams alone. ArchiMate should be connected to other evidence sources and specialized models, but it should not pretend to replace them.
The fourteenth continuity is that ArchiMate still needs governance. No version of the language can guarantee good models by itself. A standard can define concepts, relationships, notation, customization mechanisms, and conformance requirements. It cannot ensure that an organization uses them consistently. ArchiMate 4 reduces some conceptual debt in the standard, but local modeling discipline remains necessary.
This is why the practical implications of ArchiMate 4 are not only technical. A repository still needs naming conventions, relationship rules, profile governance, viewpoint standards, migration controls, review processes, and tool validation. That was true before, and it remains true now. The difference is that ArchiMate 4 makes some governance needs more visible.
The fifteenth continuity is that ArchiMate remains useful only when it is tied to architectural questions. The purpose is not to model everything that exists. The purpose is to model what must be understood, governed, changed, analyzed, communicated, or decided. ArchiMate 4 does not change that. A smaller metamodel does not mean every enterprise object should be modeled. It means the architecture practice should choose more carefully which objects, relationships, and views matter.
This is especially important in large organizations. A repository can become unusable not only because the language is too large, but because the organization models too much without a clear question. ArchiMate 4 helps reduce language complexity, but it does not solve scope discipline. Model only what supports decisions, traceability, governance, communication, and analysis.
In summary, ArchiMate 4 changes the structure of the language, but not its architectural vocation. It remains an Enterprise Architecture modeling language. It remains stakeholder oriented. It remains graph based. It remains structured around active structure, behavior, passive structure, motivation, and transformation. It remains complementary to TOGAF, BPMN, UML, data modeling, software design, security modeling, cloud inventories, CMDBs, and operational evidence. It remains a language for communicating architecture, not a universal formal model of the enterprise.
The correct reading is therefore balanced. ArchiMate 4 simplifies and normalizes the language, but it does not change what ArchiMate is for. It removes some misleading or redundant constructs, but it does not remove the need to model contracts, constraints, data, processes, services, responsibilities, physical technology, transformation, or dependencies where those concerns matter. It changes the grammar of expression, not the existence of the architectural concerns.
The stable principle is this: ArchiMate is still a map, not the terrain. Version 4 improves the map legend. It does not eliminate the need to know what territory is being mapped, why it is being mapped, and what other instruments are needed to observe the terrain.
ArchiMate 4 should be read as a semantic refactoring of the ArchiMate language, not as a new language and not as a merely cosmetic revision. Its main contribution is not the addition of a large set of new modeling features. Its main contribution is the removal, merger, relocation, and normalization of concepts that had made the language heavier than necessary for many users. The result is a smaller language kernel, a clearer Common Domain, a more generic treatment of behavior, role, collaboration, and path, and a stronger reliance on relationships, profiles, attributes, multiplicity, and repository governance.
This is why the change from ArchiMate 3.2 to ArchiMate 4 should not be summarized only as a list of renamed elements. The official change guidance does list concrete transformations: interactions are removed, constraint becomes a specialization of requirement, contract becomes a specialization of business object, gap becomes a specialization of assessment or deliverable, representation becomes a specialization of data object, artifact, or material, layer-specific behavior elements become generic behavior elements, implementation event becomes event, and path moves into the Common Domain with a corrected realization pattern.162 But these transformations are symptoms of a deeper design decision. ArchiMate 4 wants fewer primitive concepts and more explicit semantic structure.
The logic is coherent. A business process, an application process, and a technology process are all processes. A business function, application function, and technology function are all functions. A business service, application service, and technology service are all services. What differs is not the abstract nature of the behavior, but the performer, the realization, the exposed service, the accessed object, the path of exchange, the viewpoint, and the domain context. ArchiMate 4 therefore moves the meaning away from layer-specific labels and toward relationships and specialization.
This is a more rigorous architecture posture. In a mature model, a process should not be considered business relevant only because its box is yellow or because its element type says business process. It should be business relevant because the model shows that it is performed by business actors or roles, realizes business services, participates in a value stream, accesses business objects, or contributes to business outcomes. The same applies to application and technology relevance. The relationship graph must explain the classification.
This is also why the move from layers to domains is fundamental. The old layered visualization suggested a hierarchy. It encouraged the intuition that business was above application, application above technology, and technology below everything else. That picture was useful for simple communication, but it was never a complete ontology of the enterprise. The Open Group motivation paper explicitly explains that ArchiMate layers were not abstraction layers and that abstraction is handled through relationships such as realization, assignment, aggregation, and composition.163 ArchiMate 4 makes that principle more visible by replacing the layered matrix with the Hexagonion and the term layer with domain.
This matters because enterprises are not vertical stacks. They are socio-technical systems. They include people, organizations, applications, data, infrastructure, physical assets, equipment, facilities, suppliers, regulators, markets, AI services, operational technology, and transformation programs. These elements do not interact only from top to bottom. They form networks of behavior, responsibility, dependency, exchange, control, and evidence. A domain based language is better suited to such systems than a layer based metaphor.
The Common Domain is the structural answer to this problem. Role, collaboration, path, service, process, function, event, grouping, and location become shared concepts. They are not owned by business, application, or technology. They are the connective tissue of the architecture. The Common Domain allows the modeler to represent behavior before execution is fully allocated, to represent roles fulfilled by human or non human structures, to represent collaborations across domains, and to represent logical paths of information, data, energy, or material exchange. This is essential for modern architectures in which humans, machines, software, infrastructure, and physical assets jointly perform work.
The merger of behavior elements is therefore not only a simplification. It is a correction of premature classification. At early architecture stages, the important question is often what behavior the enterprise must perform. The question of whether that behavior will be manual, automated, AI assisted, outsourced, robotic, or physically executed may come later. ArchiMate 4 allows that design commitment to be postponed. This supports better architecture reasoning because it separates the existence of behavior from the allocation of that behavior to performers.
The motivation paper makes this benefit explicit. It says that the new structure reduces the number of concepts, reduces model complexity, makes mapping to BPMN and UML more natural, allows implementation decisions to be taken later, supports cross domain collaborative execution, and permits non human actors to be assigned to roles, which becomes increasingly relevant in the age of AI.164 These are not minor usability improvements. They respond to real patterns in contemporary enterprise architecture: human and machine collaboration, partial automation, AI assisted work, cyber-physical systems, and mixed operating models.
At the same time, ArchiMate 4 does not make modeling easier in every respect. It makes the language easier to learn, but it makes semantic discipline more important. If the modeler uses generic process, generic service, generic role, generic collaboration, and generic path without explicit relationships, the model becomes weaker, not stronger. The simplified language requires stronger modeling practice. The less meaning is encoded in the element type, the more meaning must be encoded in assignments, realizations, serving relationships, access relationships, flows, triggers, multiplicities, profiles, and attributes.
This is the main practical warning. ArchiMate 4 can produce smaller models with higher semantic quality, but it can also produce cleaner diagrams with less architectural meaning. The difference depends on the architecture practice. A repository governed as a semantic graph will benefit. A repository used as a drawing library may lose precision.
The removal of concepts should be understood in the same way. Contracts, constraints, gaps, representations, and interactions do not disappear from architecture work. They disappear as primitive elements. If they still matter, they should be represented through better parent concepts and governed specializations. A contract is a specialized business object. A constraint is a specialized requirement. A gap is an assessment or deliverable depending on meaning. A representation may be a data object, artifact, material, or business object depending on what is being modeled. An interaction is usually a process or function performed collectively by a collaboration. The concern remains, but the modeling grammar becomes more precise.
This is healthy only if the specialization layer is governed. ArchiMate 4 removes conceptual debt from the standard, but that debt can reappear inside organizations as uncontrolled profiles, local stereotypes, vague attributes, and inconsistent naming. A smaller standard language does not automatically create a cleaner enterprise repository. It creates the conditions for one. The enterprise architecture function must still define a profile catalog, attribute rules, viewpoint standards, relationship policies, migration rules, validation checks, and tool exchange controls. The ArchiMate 4 Specification provides language customization mechanisms such as attributes, profiles, and specialization, but it is the organization that must govern their use.165
Multiplicity is the main new expressive feature and should be treated as an opportunity to strengthen architecture governance. It allows relationships to express optionality, mandatory participation, minimum or maximum participation, redundancy, uniqueness, and structural constraints. This can turn some architecture principles from prose into checkable model statements. An organization may state, as a model governance rule, that a critical service must be realized by at least one process or function. A regulated data object must have exactly one accountable owner. A resilient platform must be deployed across at least two locations. A collaboration may require two or more participants. These are architecture rules, not just diagram annotations.166
But multiplicity also introduces the risk of false precision. ArchiMate remains an enterprise architecture language, not a database schema language or an executable process language. Cardinalities should be used where they affect architectural decisions, governance, resilience, ownership, compliance, or validation. They should not be spread across every relationship merely because the notation allows it. The right use of multiplicity is selective and linked to architecture questions.
The same principle applies to derivation. Relationships and derivation remain central because they allow the same underlying model to support detailed analysis and simplified stakeholder views. ArchiMate can abstract away intermediary elements and derive valid higher level relations where the rules permit it. This is powerful for impact analysis, capability traceability, service dependency analysis, and transformation planning. But derivation is only as reliable as the underlying relationship graph. If the base model uses weak associations or incorrect relationships, derived views will amplify the weakness.167
The practical conclusion for migration is therefore clear. Moving from ArchiMate 3.2 to ArchiMate 4 should be treated as controlled semantic refactoring, not as automatic symbol conversion. The official mappings are the starting point. A serious migration should inventory affected concepts, preserve provenance, define specialization profiles, review removed concepts semantically, audit relationships, refactor views, validate reports, test tool exchange, and train modelers in the new logic. The objective is not to make old diagrams legal under the new specification. The objective is to improve the semantic quality of the architecture repository.
This distinction is important because ArchiMate 4 will expose the maturity of the architecture practice using it. Organizations with weak repository governance may experience the new version as a loss of precision. Organizations with strong semantic governance may experience it as a cleanup that reduces duplication and improves analysis. The specification alone does not determine the outcome.
The broader architectural lesson is that modeling languages cannot scale by endlessly adding concepts. The Open Group motivation paper explicitly warns against standards bloat, conceptual debt, and the tendency of advanced users to push standards toward advanced use cases while increasing the burden on regular and prospective users.168 ArchiMate 4 chooses the opposite direction. It reduces the language where concepts were redundant, unclear, rarely used, or better expressed as specializations.
That choice is correct, but it has a cost. As the language core becomes smaller, more of the real enterprise meaning moves into profiles, relationships, attributes, viewpoints, tool behavior, repository rules, and links to evidence. This is not a defect. It is the unavoidable consequence of using a human-readable language to model systems that are becoming more distributed, dynamic, automated, regulated, and cyber-physical.
This means that ArchiMate should not be treated as the complete model of the enterprise. It should be treated as the intentional semantic map of the enterprise. It can describe what the enterprise believes, intends, requires, plans, and governs. It can show capabilities, services, behavior, applications, technologies, roles, collaborations, paths, requirements, plateaus, and transformation work. But it cannot by itself prove that the actual implemented enterprise conforms to the model.
For that, ArchiMate must be connected to operational evidence: application portfolios, CMDBs, cloud inventories, identity systems, API catalogs, data catalogs, process mining tools, deployment pipelines, vulnerability scanners, SBOMs, SIEM data, network flows, contract repositories, and observability platforms. The model states the intended architecture. Evidence shows the actual system. The difference between the two is where governance becomes real.
This is the future direction implied by ArchiMate 4. A simpler language is useful if it becomes the stable semantic layer above more volatile implementation evidence. It is not useful if it becomes only a cleaner diagramming notation detached from reality. The enterprise architecture repository should become an addressable, queryable, governed knowledge base that links architectural intent to operational facts.
Therefore, the final judgment is balanced. ArchiMate 4 is a positive evolution because it removes redundancy, clarifies the language structure, supports hybrid human and machine behavior, strengthens the Common Domain, introduces relationship multiplicity, and makes the language more approachable. But its success depends on disciplined adoption. Without profile governance, relationship quality, migration control, viewpoint discipline, and evidence integration, the simplification can become semantic loss.
The best way to adopt ArchiMate 4 is not to recreate ArchiMate 3.2 through specializations. It is also not to flatten everything into undifferentiated generic concepts. The best approach is to preserve old meaning during migration, review which distinctions still matter, retire accidental complexity, define a small and governed profile catalog, strengthen relationships, and use the repository to answer real architecture questions.
ArchiMate 4 does not reduce the complexity of enterprises. It reduces some complexity in the language used to describe them. That is valuable, but only if the architecture practice absorbs the responsibility that the standard deliberately leaves outside the core language. The new version gives enterprise architects a cleaner instrument. It does not remove the need for judgment.
The real conclusion is therefore this: ArchiMate 4 is not an endpoint. It is a correction. It reminds us that enterprise architecture should not be a proliferation of symbols, nor a collection of attractive diagrams. It should be a governed semantic discipline connecting organizational intent, system structure, transformation choices, and operational evidence. ArchiMate 4 improves the language for that purpose. The rest depends on how rigorously it is used.
The changes introduced by ArchiMate 4 can be read in two ways. The practical reading is that the language has been simplified: several concepts have been removed, behavior elements have been merged across domains, role and collaboration have become generic, path has moved into the Common Domain, and relationships can now express multiplicity. The official specification states this explicitly in its change list from version 3.2 to version 4.169
The theoretical reading is more interesting. ArchiMate 4 is evidence of a structural tension in enterprise architecture: enterprise systems are becoming more complex, but the modeling languages used to describe them are being pushed toward smaller and more generic vocabularies. This is not accidental. It is a consequence of the limits of human cognition, tool interoperability, semantic consistency, and organizational adoption.
From first principles, a model is not the system. A model is a lossy representation of a system, built for a purpose. It selects some states, entities, relations, constraints, and transformations, and ignores the rest. A modeling language is therefore not a neutral mirror of reality. It is a compression scheme. It defines what distinctions are cheap to express, what distinctions are expensive to express, and what distinctions are impossible to express without leaving the language.
ArchiMate 4 makes this compression more explicit. The specification says that the language is intentionally designed to be as small as possible while remaining usable for most enterprise architecture modeling tasks. It also states that understandability and communication among people are primary design goals, not exhaustive technical representation.170 This is a rational design choice, but it exposes the central bottleneck: the limiting resource is not only the expressiveness of the language, but the ability of organizations to create, maintain, validate, and use models whose complexity grows with the systems they describe.
A naive view would say that enterprise architecture tools need more symbols. If systems become more complex, the language should add more concepts. More kinds of service. More kinds of component. More kinds of event. More kinds of interface. More kinds of data object. More kinds of risk, control, contract, policy, platform, product, environment, deployment unit, agent, and dependency.
This view fails because it confuses expressiveness with usability.
A language with more primitive constructs can encode more distinctions directly, but it also increases classification ambiguity. Each new primitive concept creates a boundary problem. The modeler must decide whether something is one concept or another. The reader must infer why that choice was made. The tool must validate allowed relationships. The repository must preserve semantic consistency across teams. The training program must teach the distinction. The governance function must enforce it.
The bottleneck is therefore semantic coordination at scale. In formal terms, the problem is not merely the cardinality of the symbol set. It is the consistency of symbol interpretation across many modelers, many viewpoints, many tools, many projects, and many time horizons.
This explains why ArchiMate 4 moves in the opposite direction from system complexity. It does not try to match complexity by adding many more concepts. It reduces the primitive vocabulary and pushes domain precision into specialization, profiles, attributes, relationships, and viewpoints. This is consistent with the specification’s stated preference for simplicity, broad usability, and collaboration with other modeling languages rather than full coverage.171
The price is that some meaning becomes less visible in the base notation. The benefit is that the core language becomes more stable.
Enterprise systems are no longer only collections of business processes supported by applications running on infrastructure. They are distributed, adaptive, regulated, cyber-physical, data intensive, and increasingly agentic systems.
A modern enterprise architecture may contain human organizations, software platforms, cloud services, APIs, event brokers, machine learning models, data products, identity fabrics, operational technology, edge devices, digital twins, market interfaces, regulatory controls, supply chain dependencies, outsourced service providers, and autonomous or semi autonomous agents. These elements are not merely arranged in layers. They interact through feedback loops.
From a theoretical point of view, this matters because feedback changes the nature of the modeled object. A layered dependency graph can often be understood as a relatively static structure. A feedback system has dynamics. Its behavior depends not only on what components exist, but on timing, state, control loops, incentives, failures, adversaries, and adaptation.
A static enterprise architecture model can show that a capability is realized by processes, supported by applications, served by infrastructure, constrained by requirements, and delivered through work packages. That is useful. But it does not fully describe runtime behavior, emergent failure, cascading risk, performance under load, security adversariality, or organizational learning.
ArchiMate explicitly remains an enterprise architecture language. It intentionally does not model individual instances as a core distinction, because at enterprise architecture level it is more common to model types or exemplars rather than individual executions or instances.172 This is coherent. But it also means that a large part of the real system complexity lies below or outside the language’s native abstraction boundary.
The gap is therefore structural. Enterprise architecture models operate mainly at the level of types, dependencies, services, responsibilities, and transformation states. The systems being built increasingly exhibit complexity at the level of runtime instances, event streams, control policies, data distributions, agent decisions, failure propagation, and emergent behavior.
Every architecture model compresses reality. The question is whether the compression preserves the properties that matter.
A lossless model of a large enterprise system is impossible in practice. Even if such a model could be written, it would be unusable by humans and probably obsolete before completion. Therefore enterprise architecture uses lossy compression. It keeps distinctions that support governance, decision making, communication, and impact analysis. It discards operational detail.
The danger appears when the discarded detail contains the real source of architectural risk.
For example, a model may show that an application service serves a business process. That is true but insufficient if the actual business risk depends on queue latency, retry behavior, data freshness, identity propagation, cryptographic trust anchors, deployment topology, API rate limits, model drift, or a third-party operational dependency.
Likewise, a model may show that a technology service supports an application component. That is true but insufficient if the relevant failure mode depends on shared control planes, common storage, blast radius, credential inheritance, side channel connectivity, or unmanaged software dependencies.
The theoretical bottleneck is not that ArchiMate lacks one more symbol for these cases. The bottleneck is that the architecture model is a finite abstraction over a system whose operational state space is enormous.
If a system has n components and each component has even a small number of possible states, the global state space grows multiplicatively. Interactions grow combinatorially. Dependencies can be hidden, conditional, probabilistic, temporal, or adversarial. A human-readable notation cannot scale linearly with this growth unless it deliberately abstracts away most of it.
ArchiMate 4 accepts this implicitly. It simplifies the language and relies on generic elements, relationships, profiles, and views. That is a pragmatic response to the compression problem. But it also confirms that enterprise architecture cannot rely on diagrammatic modeling alone.
A smaller language is not necessarily weaker. In formal systems, smaller primitive vocabularies can be more elegant and more analyzable. Lambda calculus, relational algebra, process calculi, graph grammars, and type systems show that small formal cores can express rich structures when combined compositionally.
ArchiMate 4 moves in that direction. It removes several special case concepts and replaces them with more general concepts plus specialization. Behavior becomes service, process, function, and event. Role becomes generic. Collaboration becomes generic. Removed elements such as contract, constraint, gap, and representation are mapped to specializations of more fundamental concepts.173
This is theoretically sound. It reduces ontology duplication. It makes the metamodel more orthogonal. It shifts the language from a broad vocabulary of named cases toward a smaller set of composable constructs.
However, enterprise architecture differs from formal mathematics in one essential respect. In mathematics, the interpreter is trained to preserve formal meaning. In enterprise architecture, the interpreter is often a human stakeholder with partial context, limited time, and local incentives.
A simpler language can therefore become either more rigorous or more ambiguous.
It becomes more rigorous when the enterprise defines strict modeling conventions, profiles, naming rules, relationship rules, viewpoints, repository controls, and validation checks. It becomes more ambiguous when generic concepts are used without governance. A generic process can be business, application, technology, operational, organizational, automated, manual, or mixed. The model must now express that meaning through context and relationships.
ArchiMate 4 therefore increases the importance of modeling discipline. The formal language becomes smaller, but the enterprise specific modeling method must become stronger.
Systems scale by decomposition, automation, replication, and runtime execution. A cloud platform can run thousands of services because machines execute the details. A message broker can handle millions of events because protocols and infrastructure automate transmission. A CI/CD platform can deploy hundreds of components because pipelines encode repeatable action.
Human centered modeling languages scale differently. They must remain readable. They must support shared understanding. They must be teachable. They must survive organizational turnover. They must support decision making under uncertainty. They cannot expose every operational detail without collapsing into an unreadable graph.
This creates a scaling asymmetry.
The system can grow by adding executable complexity. The architecture model cannot grow at the same rate because its primary executor is still human cognition.
This asymmetry is the real bottleneck. Enterprise architecture is asked to govern systems whose complexity is increasingly machine managed, while using models whose comprehension is human bounded.
The consequence is that the future of enterprise architecture cannot be only better diagrams. It must be a coupling between human interpretable models and machine analyzable evidence.
A static repository of diagrams is insufficient for future enterprise architecture. The repository must become a computational object.
That means an enterprise model should not only be drawn. It should be queryable, validated, simulated where possible, compared over time, connected to runtime evidence, and checked against policies.
In this direction, ArchiMate 4’s simplification can be interpreted positively. A smaller metamodel is easier to validate and map to other evidence sources. Generic concepts can act as stable anchors, while profiles and attributes carry local semantics. Relationships and multiplicity can support constraint checking. Viewpoints can remain human-readable while the underlying repository supports machine queries.
The likely future is a two level architecture discipline.
At the first level, there is a human communicative model. This is where ArchiMate is strongest. It explains concerns, capabilities, dependencies, transformations, and responsibilities.
At the second level, there is a machine-assisted model of evidence. This includes CMDB data, cloud inventories, identity graphs, API catalogs, data lineage, event logs, deployment manifests, SBOMs, network flows, security findings, policy controls, and operational telemetry.
The enterprise architect’s task will be to connect these two levels. The architecture model says what the enterprise believes is true. The evidence layer says what appears to be true in the implemented system. The difference between them becomes a governance signal.
The gap between system complexity and modeling language simplicity has several consequences.
First, architecture models will become less useful if treated as complete descriptions. They must be treated as intentional abstractions. A model is valid only relative to a concern. A business capability map, a security zone model, a service dependency view, and a deployment topology are all partial projections. None is the system.
Second, model quality will depend less on diagram aesthetics and more on semantic traceability. The value of a model will be measured by whether it can answer impact questions. What breaks if this application is retired? Which capabilities depend on this data object? Which services are exposed through this interface? Which requirements constrain this platform? Which transformation work packages realize this target plateau?
Third, enterprise architecture will need stronger connections with formal and semi formal analysis. Not every enterprise model must become a theorem, but some parts of architecture governance require checkable constraints. Examples include segregation of duties, data residency, security zone isolation, redundancy, ownership, critical service dependencies, and lifecycle state consistency.
Fourth, EA tools will need to evolve from drawing tools into reasoning environments. A drawing tool records shapes. A reasoning environment understands concepts, relationships, constraints, derivations, versions, evidence, and uncertainty.
Fifth, the role of the enterprise architect will shift. The architect will not be the person who draws the most complete diagram. The architect will be the person who defines the right abstractions, manages semantic consistency, connects architecture intent to implementation evidence, and identifies where hidden complexity creates unacceptable risk.
The modeling gap does not only affect documentation. It affects the systems themselves.
Systems are built partly from models. Even when architecture diagrams are informal, they influence procurement, integration, security design, organizational responsibility, data governance, and implementation sequencing. If the model hides complexity, the built system may inherit unmanaged complexity.
A simplified modeling language can help if it forces architects to identify the essential structure. But it can harm if it makes architects underrepresent critical distinctions. For example, treating several operational behaviors as generic processes may be acceptable at portfolio level, but dangerous if the distinction between manual, automated, safety critical, adversarial, and externally delegated behavior is architecturally relevant.
The future risk is not that systems become complex. Complex systems are unavoidable. The risk is that organizations build complex systems whose architectural models are too weak to govern them.
This leads to a practical principle: the complexity omitted from the model must be governed somewhere else.
If ArchiMate does not model runtime behavior in detail, that behavior must be governed through observability, formal interface contracts, operational runbooks, simulations, test evidence, SLOs, safety cases, threat models, and automated compliance checks. If ArchiMate does not distinguish all domain-specific concepts natively, the enterprise must define profiles and repository rules. If ArchiMate does not model instances, the enterprise must connect type level architecture to runtime inventories and telemetry.
The modeling language does not need to contain every detail. But the architecture practice must know exactly where each omitted detail is controlled.
From a theoretical computer science perspective, ArchiMate 4 is a reasonable move toward a smaller and more compositional metamodel. It reduces redundant primitives and makes the language more orthogonal. This is defensible.
But it also sharpens the central contradiction of enterprise architecture. Systems are becoming more dynamic, distributed, cyber-physical, data driven, and partially autonomous, while human centered modeling languages must remain small enough to be understood. The gap cannot be closed by adding symbols. It can only be managed by combining simpler human models with stronger machine-assisted validation, runtime evidence, formal constraints, and disciplined specialization.
The future of enterprise architecture is therefore not a larger diagramming language. It is architecture as a governed semantic layer between organizational intent and computational reality.
ArchiMate 4 is a useful step in that direction, but only if enterprises do not mistake simplification for sufficiency.
The comparison with UML and MOF is useful because both are official OMG modeling standards: UML defines a graphical language for visualizing, specifying, constructing, and documenting software and system artifacts, while MOF provides a metamodeling foundation for defining modeling languages and managing models.174175 The comparison must be used as a warning rather than as a simple accusation. I do not read ArchiMate 4 as a repetition of the UML story at the same scale. ArchiMate is smaller, more constrained, and more explicitly oriented toward enterprise architecture communication. However, the same structural tension is visible: when systems become more complex, modeling languages are forced either to expand until they become too heavy to use, or to simplify until much of the real semantics moves outside the core language.
UML largely followed the first path. ArchiMate 4 appears to follow the second.
UML did not become problematic because diagrams were useless. The problem was more subtle. UML tried to occupy too many positions at once. It wanted to be a communication notation, a software design language, a behavioral specification language, a structural modeling language, a basis for code generation, a tool exchange language, and part of a wider metamodeling infrastructure. MOF extended that ambition by treating modeling languages themselves as objects of formal description. This was intellectually powerful, but it created a practical problem. The formal stack became richer than most organizations could use consistently.176
The result was predictable. In ordinary software practice, most UML usage collapsed into a small informal subset: class diagrams, sequence diagrams, use case diagrams, activity diagrams, and occasionally component or deployment diagrams. The richer formal machinery did not disappear, but it became the concern of tool vendors, standards experts, methodologists, and model driven engineering specialists. The daily practice kept what was communicable and discarded what was too heavy.
ArchiMate starts from a more modest premise. The ArchiMate 4 specification explicitly defines the language as a visual language for describing, analyzing, and communicating enterprise architectures, and it emphasizes stakeholder oriented views rather than executable completeness.177 It also states a design principle of collaboration over coverage: if a need is already sufficiently covered by another modeling language, the preferred approach is to map to that language rather than absorb its features. The specification even gives detailed software design in UML as an example of something better handled by a specialized language.178
This is an important difference. ArchiMate is not trying to become the executable model of the enterprise. It is trying to remain a communicative language for enterprise architecture. That is its strength. But this strength also reveals its limit.
The change from ArchiMate 3.2 to ArchiMate 4 simplifies the language significantly. The specification lists the removal of business interaction, application interaction, technology interaction, constraint, contract, gap, and representation. It also states that behavior elements have been merged across layers into a single set of service, process, function, and event; that business, application, and technology collaborations have been merged into a single collaboration element; that business role has been replaced by a generic role; that the term layer has been replaced by domain; that the Generic Metamodel chapter has been replaced by the Common Domain; that path has moved into the Common Domain; and that relationships can now express multiplicity.179
This is a classic metamodel normalization. Several specialized elements disappear as primitive constructs and are replaced by more general concepts. A contract becomes a specialization of business object. A constraint becomes a specialization of requirement. A gap becomes a specialization of assessment or deliverable. A representation becomes a specialization of data object, artifact, or material. Interactions become specializations of function or process. The specification itself presents these transformations as the migration path from ArchiMate 3.2 models to ArchiMate 4.180
The theoretical point is that simplification does not eliminate complexity. It relocates complexity.
In ArchiMate 3.2, some distinctions were embedded directly in the language. In ArchiMate 4, more distinctions are pushed into profiles, specializations, attributes, naming conventions, viewpoints, relationships, and repository governance. This is not necessarily wrong. A smaller language can be more elegant, more stable, and easier to teach. But the price is that the enterprise must govern the semantic layer above the standard with much greater discipline.
This is where the analogy with UML and MOF becomes important. UML profiles and stereotypes allowed organizations to extend the language without changing the core standard: a UML profile defines a limited set of extensions to the reference metamodel, and stereotypes are one of the main extension mechanisms applied through profiles.181 That mechanism was powerful, but it also enabled semantic fragmentation. Two teams could both use UML and still mean different things by their stereotypes, profiles, and tool conventions. Formal compliance did not guarantee semantic interoperability.182
ArchiMate 4 faces a smaller but similar risk. The specification supports customization through attributes, profiles, and specialization of concepts. It states that every ArchiMate concept can have attributes and that profiles can be used to enrich concepts with supplementary information. It also explains that specialization lets organizations define refined concepts while remaining inside the boundaries of the language.183 Specialized elements inherit the properties of the concepts they specialize, and specialized relationships are also allowed.184
This mechanism is necessary. Without it, ArchiMate 4 would be too generic for many real enterprise contexts. But it also means that the hard problem moves from the standard to the architecture practice. Which profiles are allowed? Who defines them? Are they mandatory? Are they exchanged between tools? Are they queryable? Are they versioned? Are they validated? Are they understood by stakeholders? Are they preserved during repository migration? Are they still meaningful after reorganizations, mergers, outsourcing, platform changes, and tool changes?
If these questions are not answered, ArchiMate 4 may become formally simpler but operationally more ambiguous.
This is the metamodeling trap: believing that a clean metamodel solves the modeling problem. It does not. A clean metamodel solves only part of the problem. It reduces redundancy and improves formal consistency. It does not automatically preserve meaning across people, projects, tools, time, and organizational boundaries.
The fundamental bottleneck is semantic coordination at scale.
A modern enterprise is not only a hierarchy of business processes, applications, and infrastructure. It is a distributed socio-technical system. It includes human roles, suppliers, contracts, cloud services, identity systems, APIs, data products, AI models, operational technology, cybersecurity controls, regulatory obligations, deployment pipelines, observability platforms, and increasingly autonomous agents. These elements do not simply sit in layers. They interact through feedback loops, runtime states, exceptions, incidents, and changing operational conditions.
A human-readable modeling language cannot scale at the same speed as that reality. The system grows through automation, replication, runtime execution, event streams, infrastructure as code, cloud APIs, data pipelines, and machine generated configuration. The model grows through human comprehension. These are different scaling laws.
This is the real lesson from UML. UML did not disappear because software no longer needed structure. It lost centrality because code, tests, continuous integration, package managers, deployment manifests, infrastructure as code, and runtime telemetry became more authoritative than manually maintained diagrams. The living system moved faster than the model.
Enterprise architecture faces the same risk. Cloud inventories, IAM graphs, CMDBs, API gateways, data catalogs, lineage tools, SIEM platforms, vulnerability scanners, SBOMs, deployment pipelines, service meshes, and observability systems increasingly contain fresher facts about the enterprise than architecture diagrams do. If ArchiMate repositories are not connected to these evidence sources, they risk becoming interpretive documentation rather than governing models.
The conclusion is not that ArchiMate is useless. The conclusion is that ArchiMate must not be treated as the complete model of the enterprise. That would repeat the excessive ambition of universal modeling. ArchiMate should instead be treated as the intentional semantic map of the enterprise. It should express why the enterprise is structured as it is, what capabilities matter, which services are exposed, which responsibilities exist, which dependencies are architecturally significant, which transformation states are planned, and which stakeholder concerns are being addressed.
The actual enterprise must be observed through additional layers of evidence. Detailed processes may live in BPMN models, process mining tools, or workflow engines. Software structure may live in source repositories, service catalogs, API specifications, and runtime dependency maps. Infrastructure truth may live in cloud inventories and infrastructure as code. Security truth may live in IAM systems, network flows, threat models, SIEM data, vulnerability scanners, and control repositories. Data truth may live in catalogs, lineage systems, data contracts, and quality rules. Transformation truth may live in portfolio systems, delivery pipelines, and release evidence.
The architecture repository should become the semantic index across these domains.
This is where ArchiMate 4 can still be valuable. Its simplification may be useful precisely because the core language does not try to describe everything. A smaller ArchiMate can provide the human scale abstraction layer, while detailed and volatile evidence remains in specialized systems. But that only works if the links are governed. A capability should be traceable to services, applications, data, infrastructure, controls, projects, and evidence. A model element should not be a drawing artifact only. It should be an addressable semantic object connected to other sources of truth.
Therefore, the warning is not that ArchiMate 4 is becoming UML. The warning is that ArchiMate 4 may repeat one of UML’s deeper failure modes if it becomes detached from the real systems it claims to describe.
The lesson is precise. Do not solve enterprise complexity by inflating the language. UML already showed the limits of that path. But also do not solve enterprise complexity by simplifying the notation and leaving semantics unmanaged. That path produces elegant diagrams and weak governance.
The future of enterprise architecture requires a different architecture of modeling itself: a small stable human-readable language, a governed specialization layer, a machine readable repository, and continuous connection to implementation evidence.
In that sense, ArchiMate 4 is not the end state. It is one layer in a larger epistemic system: a way to express enterprise intent, not a substitute for observing and validating enterprise reality.
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026.↩︎
The Open Group, ArchiMate® 3.2 Specification, Document C226, October 2022.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Executive Summary and Motivation for Changes.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Motivation for Changes. The paper lists the ArchiMate Manifesto principles, including simplicity over comprehensiveness, people over tools, and communicating architecture over other use cases.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Merging Behavior Elements in the ArchiMate Core Metamodel, Solution, and Advantages.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Merging Behavior Elements in the ArchiMate Core Metamodel, Solution, and Advantages.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Why Not Simplify More?.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, New Language Structure Depiction.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Merging Behavior Elements in the ArchiMate Core Metamodel. The paper states that ArchiMate layers are not abstraction layers and that abstraction is handled through relationships such as realization, assignment, and aggregation or composition.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, pages 7 and 8. The paper explains that ArchiMate 3.2 often required duplicated behavior elements to represent partially automated processes and that ArchiMate 4 collapses the layer-specific behavior concepts into generic ones.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 2.1, 2.2, 2.13, and 3.2.1. The specification defines the ArchiMate Core Language as containing the Common, Business, Application, and Technology Domains, and defines domain as a subset of the language for modeling specific characteristics of an enterprise and its architecture.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, New Language Structure Depiction. The white paper explains the alignment and difference between TOGAF architecture domains and ArchiMate domains.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.2.1, Domains of the ArchiMate Language. The specification states that ArchiMate does not define a specific information or data domain and instead supports information modeling through passive structure elements across domains.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 2.1, 2.2, and 3.2.1. The specification defines the ArchiMate Core Language as including Common, Business, Application, and Technology, and the full language as adding Motivation, Strategy, and Implementation and Migration.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Chapter 4 and Table 4-1. The Common Domain contains role, collaboration, path, service, process, function, event, grouping, and location.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Merging Behavior Elements in the ArchiMate Core Metamodel and Solution. The white paper explains that layer-specific behavior concepts are collapsed into a single generic set and that assignment decides execution.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Advantages. The white paper discusses cross domain execution, human and machine collaboration, assignment of non human actors to roles, and the distinction between responsibility and legal accountability.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, pages 7 and 8. The paper explains how ArchiMate 3.2 could require duplicated business and application behavior elements to model partial automation.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Chapter 4, Section 4.2.1. Service is defined as explicitly defined behavior provided to the environment by business actors, application components, nodes, devices, system software, equipment, facilities, roles, or collaborations.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.1.1, Role. The specification defines role as the position or purpose that a business actor, application component, node, device, system software, equipment, facility, or collaboration has in performing specific behavior, and gives examples such as Requester, Approver, Policy Enforcement Point, and Policy Decision Point.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Advantages. The white paper discusses cross domain execution, human and machine collaboration, assignment of non human actors to roles, and the distinction between responsibility and legal accountability.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.1.2, Collaboration. The specification defines collaboration as a collection of business actors, application components, nodes, devices, system software, equipment, facilities, roles, and other collaborations that work together to perform collective behavior, and notes that collaborations may be temporary.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.1.3, Path. The specification defines path as a logical link between business actors, application components, nodes, devices, system software, equipment, facilities, roles, and collaborations through which these elements can exchange information, data, energy, or material.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 4.3.1 and 4.3.2. Grouping collects concepts that belong together based on a common characteristic, while location represents a place or position where structure elements can be located or behavior can be performed.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Conversion. The paper describes conversion without specialization profiles and conversion with specialization profiles to preserve the originating ArchiMate 3.2 layer information.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.2.2. The specification describes active structure, behavior, and passive structure through a natural language analogy of subject, verb, and object.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.8. The specification explains that colors have no formal semantics in ArchiMate models, but may be used as notational cues for domains, including warm gray for the Common Domain.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Merging Behavior Elements in the ArchiMate Core Metamodel. The paper compares ArchiMate behavior modeling with BPMN and UML, where behavior concepts are not subdivided by the performer’s layer in the same way.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Merging Behavior Elements in the ArchiMate Core Metamodel. The paper states that the behavior elements in the Business, Application, and Technology Layers were basically identical and that business process, application process, and technology process all model causal or temporal sequences of behavior.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.2.2, Aspects of the ArchiMate Language. The specification defines the Behavior Aspect as behavior performed by actors, with structural elements assigned to behavioral elements to show who or what displays the behavior.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, page 7. The paper explains that modeling partial automation in ArchiMate 3.2 often required duplicating behavior as an application process realizing a business process.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Solution. The paper states that the update collapses the three sets of behavior concepts into one and that assignment decides execution.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, pages 7 to 8. The paper says ArchiMate 3.2 could not easily define a process performed by active structure elements from different layers, such as a factory worker plus a robot or an office worker plus an AI assistant.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Merging Behavior Elements in the ArchiMate Core Metamodel. The paper compares ArchiMate 3.2 behavior concepts with BPMN tasks and UML activity actions, which are not divided by performer layer.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.2.2, Process. The specification states that high-level business, end-to-end, macro flow, workflow, and automated processes can all be expressed with the same process element, while detailed activity flow is typically modeled in BPMN.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 4.2.2 and 4.2.3. The specification defines process as a sequence of behaviors that achieves a specific result and function as a collection of behavior based on a chosen set of criteria.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.2.1, Service. The specification defines service as explicitly defined behavior provided to the environment by active structure elements, roles, or collaborations, and explains that services are accessible through interfaces.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.2.4, Event. The specification defines event as something that happens or occurs inside or outside the enterprise, such as a state change.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, page 7. The paper notes that the earlier workaround with realization relationships may have reinforced the mistaken impression that the Business Layer is an abstraction of the Application Layer.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, pages 9 to 10. The paper describes an AI-powered claims assessor collaborating with human employees in claim handling.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Advantages. The paper distinguishes responsibility for performing tasks from legal accountability when non human actors fulfill roles.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Conversion. The paper describes conversion with and without specialization profiles to preserve information from ArchiMate 3.2 models.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification states that business interaction, application interaction, and technology interaction have been removed and may be replaced by a specialization of function or process.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Deprecated Concepts, Interactions, and Appendix A: ArchiMate Concept Usage Statistics. The Interactions subsection states that business, application, and technology interactions are hardly used and appear in the lower part of the usage list; Appendix A states that the data was collected across 17 medium to large organizations and includes over 600,000 elements and nearly 1,000,000 relationships.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Deprecated Concepts, Interactions, and Appendix A: ArchiMate Concept Usage Statistics. The Interactions subsection states that business, application, and technology interactions are hardly used and appear in the lower part of the usage list; Appendix A states that the data was collected across 17 medium to large organizations and includes over 600,000 elements and nearly 1,000,000 relationships.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Interactions. The paper states that the meaning of interactions was not clear or well understood and discusses whether they are sequence like or function like.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Interactions. The paper explains that if interactions are process like, the requirement that they be performed by more than one active structure element can now be represented through multiplicity such as 2..* on assignment.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 14.2.1, Examples of Specializations of Common Domain Elements. The specification lists business interaction, application interaction, and technology interaction as example specializations of process.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.1.2, Collaboration. The specification defines collaboration as a collection of active structure elements, roles, or collaborations that work together to perform collective behavior.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, pages 9 to 10. The paper describes an AI-powered claims assessor collaborating with human employees and the restriction of high risk claims to a senior legal specialist.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification states that business interaction, application interaction, and technology interaction have been removed and may be replaced by a specialization of function or process.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification states that business, application, and technology collaborations have been merged into a single collaboration element, and that business role has been replaced by a generic role element to which any internal active structure element can be assigned.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Solution. The paper states that a single collaboration concept replaces layer-specific collaboration concepts and that a generic role concept replaces business role.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.1.1, Role. The specification defines role as the position or purpose that a business actor, application component, node, device, system software, equipment, facility, or collaboration has in performing specific behavior, and gives examples such as Requester, Approver, Policy Enforcement Point, and Policy Decision Point.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Advantages. The paper notes that non human actors can be assigned to roles, but that this does not make machines legally accountable because responsibility and accountability are different notions.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.1.1, Role. The specification defines role as the position or purpose that a business actor, application component, node, device, system software, equipment, facility, or collaboration has in performing specific behavior, and gives examples such as Requester, Approver, Policy Enforcement Point, and Policy Decision Point.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 8.2.1, Business Actor. The specification explains that a business actor can depict an organizational entity, while a role depicts a responsibility carried by an actor.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.1.2, Collaboration. The specification defines collaboration as a collection of business actors, application components, nodes, devices, system software, equipment, facilities, roles, and other collaborations that work together to perform collective behavior, and notes that collaborations may be temporary.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, pages 7 to 9. The paper explains that ArchiMate 3.2 could not easily model a process performed by active structure elements from different layers, such as a factory worker plus a robot or an office worker plus an AI assistant, and that ArchiMate 4 supports collaborative execution across layers.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, pages 9 to 10. The paper describes an AI-powered claims assessor collaborating with human employees in claim handling, where standard claims may be adjudicated by automation while high risk claims require a senior legal specialist.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 1.2, Overview. The specification follows the TOGAF definition of enterprise and notes that an enterprise may span multiple organizations, ecosystems, or federations.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 4.1.2 and 4.3.1. Collaboration represents active structures working together to perform collective behavior, while grouping represents concepts that belong together based on a common characteristic.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.1.2, Collaboration. The specification defines collaboration as a collection of business actors, application components, nodes, devices, system software, equipment, facilities, roles, and other collaborations that work together to perform collective behavior, and notes that collaborations may be temporary.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the removed concepts and provides conversion guidance for constraint, contract, gap, representation, interactions, other behavior elements, implementation event, and invalid relationships.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Deprecated Concepts. The paper explains that the goal is to remove clutter that increases cognitive load and that conversion paths retain information from ArchiMate 3.2 models.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the removed concepts and provides conversion guidance for constraint, contract, gap, representation, interactions, other behavior elements, implementation event, and invalid relationships.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Constraint. The paper explains that constraint was already a specialization of requirement and that the distinction between constraint and requirement was often unclear.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Constraint. The paper explains that constraint was already a specialization of requirement and that the distinction between constraint and requirement was often unclear.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Constraint. The paper explains that constraint was already a specialization of requirement and that the distinction between constraint and requirement was often unclear.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the removed concepts and provides conversion guidance for constraint, contract, gap, representation, interactions, other behavior elements, implementation event, and invalid relationships.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Contract. The paper states that contract was already a specialization of business object and mainly used in the product context.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the removed concepts and provides conversion guidance for constraint, contract, gap, representation, interactions, other behavior elements, implementation event, and invalid relationships.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Representation. The paper describes representation as a leftover from the first version of ArchiMate and explains alternatives using data object, material, business object, or specializations.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the removed concepts and provides conversion guidance for constraint, contract, gap, representation, interactions, other behavior elements, implementation event, and invalid relationships.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Gap. The paper describes gap as an odd concept, notes its low usage, and recommends assessment or deliverable depending on whether the model represents the analysis result or the document produced.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Gap. The paper describes gap as an odd concept, notes its low usage, and recommends assessment or deliverable depending on whether the model represents the analysis result or the document produced.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the removed concepts and provides conversion guidance for constraint, contract, gap, representation, interactions, other behavior elements, implementation event, and invalid relationships.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 14.2, Specialization of Concepts. The specification explains that concrete concepts can be specialized, that specialized elements inherit properties of their parent concepts, and that specialized relationships are allowed.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Conversion. The paper explains conversion using specialization profiles and notes expected future support for exchanging specialization profiles in the ArchiMate Model Exchange File Format.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification states that path is now part of the Common Domain and that aggregation from path to technology internal active structure element has been replaced by realization from active structure element to path.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.1.3, Path. The specification defines path as a logical link between business actors, application components, nodes, devices, system software, equipment, facilities, roles, and collaborations through which these elements can exchange information, data, energy, or material.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.1, Changes from Version 2.1 to Version 3.0.1. The change history notes that communication path was renamed to path and that its meaning was extended to integrate with the physical elements.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 10.2, Active Structure Elements. The specification states that path models the relation between internal active structure elements, while the physical realization of a path is modeled with communication network or distribution network.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification states that path is now part of the Common Domain and that aggregation from path to technology internal active structure element has been replaced by realization from active structure element to path.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.1.4, Realization Relationship. The specification defines realization as the relation by which more concrete or tangible elements realize more abstract elements.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Why Not Simplify More?. The paper explains that the Technology Domain covers both IT and physical technology, bits and atoms, and that physical technology concepts matter for operational resilience, Industry 4.0, digital twins, and defense use cases.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 10.2.7 and 10.2.8. Communication network represents IT structures for transmission, routing, and reception of data, while distribution network represents a physical network used to transport materials or energy.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.3.2, Flow Relationship. The specification defines flow as transfer from one element to another and distinguishes it from causal triggering.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification states that path is now part of the Common Domain and that aggregation from path to technology internal active structure element has been replaced by realization from active structure element to path.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Why Not Simplify More?. The paper explains that the Technology Domain covers both IT and physical technology, bits and atoms, and that physical technology concepts matter for operational resilience, Industry 4.0, digital twins, and defense use cases.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.6, Multiplicity. The specification states that all relationships can have multiplicity attributes on each end, except when connected to a junction, and defines the notation n, *, and n..m.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Multiplicity on Relationships. The paper describes multiplicity as an important new feature and gives examples involving data constraints, process instances, server clusters, and mandatory service realization.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 3.5 and 5.6. The specification states that ArchiMate intentionally does not support a general distinction between types and instances, while multiplicity can express constraints on instances of elements.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Multiplicity on Relationships. The paper describes multiplicity as an important new feature and gives examples involving data constraints, process instances, server clusters, and mandatory service realization.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Multiplicity on Relationships. The paper describes multiplicity as an important new feature and gives examples involving data constraints, process instances, server clusters, and mandatory service realization.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Interactions. The paper explains that if interactions are process like, the requirement that they be performed by more than one active structure element can now be represented through multiplicity such as 2..* on assignment.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.6, Multiplicity. The specification states that all relationships can have multiplicity attributes on each end, except when connected to a junction, and defines the notation n, *, and n..m.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.6, Multiplicity. The specification states that all relationships can have multiplicity attributes on each end, except when connected to a junction, and defines the notation n, *, and n..m.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 2.16, Relationship. The specification defines relationship as a connection between source and target concepts and classifies relationships as structural, dependency, dynamic, or other.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 1.3, Conformance. The specification states that conforming implementations shall support the language structure, relationships, domains, cross domain dependencies, and the relationships specified in Appendix B.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Chapter 5, Relationships and Junctions. The specification classifies relationships into structural, dependency, dynamic, and other relationships.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 5.2.1 to 5.2.4. The specification defines serving, access, influence, and association relationships.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 5.3.1 and 5.3.2. The specification defines triggering as temporal or causal relationship and flow as transfer from one element to another.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4. The specification states that when a relationship between two elements is no longer permitted according to Appendix B, it may be replaced by an association.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.8, Derivation of Relationships, and Appendix B. The specification explains that derivation supports abstraction from intermediate elements and that Appendix B provides the formal rules.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.8, Derivation of Relationships. The specification states that derivation creates summaries of detailed models, goes from more detail to less detail, and cannot be used to infer more detail.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix B. The specification distinguishes derivations that are certainly true from potential derivations that depend on the specifics of the model.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix B.2, Derivation Rules for Valid Relationships. The specification defines derivation rules for specialization, structural relationships, dependency relationships, dynamic relationships, and triggering.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix B.2.2. The specification orders structural relationships by strength as realization, assignment, aggregation, and composition, and derives the weakest relationship in a valid structural chain.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix B.2.3. The specification explains derivation between structural and dependency relationships and the transfer of dependency endpoints along structural chains.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.3.3, Semantics of Dynamic Relationships. The specification distinguishes triggering semantics from flow semantics.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix B.3, Derivation Rules for Potential Relationships. The specification states that potential derivations may be relevant but may also be wrong depending on the model, and that the modeler must decide.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.3.1, Grouping, and Appendix B.3.5. The specification discusses grouping semantics and potential derivation with elements aggregated in a grouping element.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.5.1, Junction. The specification states that junctions connect relationships of the same type and cannot create relationships that would otherwise not be allowed.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 1.2 and 13.3. The specification explains that ArchiMate distinguishes concepts from notation and supports stakeholder oriented architecture views.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Chapter 14, Language Customization Mechanisms. The specification describes customization through attributes, profiles, and specialization of concepts.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 14.1, Adding Attributes to ArchiMate Concepts. The specification explains that ArchiMate concepts can have attributes and that profiles define sets of attributes that can be coupled to concepts.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 14.1, Adding Attributes to ArchiMate Concepts. The specification explains that ArchiMate concepts can have attributes and that profiles define sets of attributes that can be coupled to concepts.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 14.2, Specialization of Concepts. The specification explains that concrete concepts can be specialized, that specialized elements inherit the properties of the elements they specialize, and that specialized relationships are also supported.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the removed concepts and provides conversion guidance for constraint, contract, gap, representation, interactions, other behavior elements, implementation event, and invalid relationships.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Conversion. The paper explains conversion with specialization profiles and notes expected future support for exchanging specialization profiles in the ArchiMate Model Exchange File Format.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 14.2.1, Examples of Specializations of Common Domain Elements. The informative examples list Business Role as a specialization of Role; Business, Application, and Technology Collaboration as specializations of Collaboration; Business, Application, and Technology Service as specializations of Service; Business, Application, and Technology Process and Business, Application, and Technology Interaction as specializations of Process; Business, Application, and Technology Function as specializations of Function; and Business, Application, Technology, and Implementation Event as specializations of Event. The section does not list Application Role or Technology Role as examples.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.8, Use of Colors. The specification states that colors have no formal semantics, but may be used as notational cues for domains.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Conversion. The paper explains conversion with specialization profiles and notes expected future support for exchanging specialization profiles in the ArchiMate Model Exchange File Format.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Motivation for Changes. The paper lists the ArchiMate Manifesto principles, including simplicity over comprehensiveness, people over tools, and communicating architecture over other use cases.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the main changes and gives translation guidance for removed concepts, merged behavior elements, implementation event, invalid relationships, and path aggregation.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Conversion. The paper describes conversion without and with specialization profiles and notes that future model exchange support was expected for specialization profiles.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the main changes and gives translation guidance for removed concepts, merged behavior elements, implementation event, invalid relationships, and path aggregation.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the main changes and gives translation guidance for removed concepts, merged behavior elements, implementation event, invalid relationships, and path aggregation.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Advantages, page 10. The paper explains that a business actor assigned to a business process has the same basic meaning as a business actor assigned to a generic process, and that the old layer-specific behavior element introduced redundancy.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Conversion. The paper describes conversion without and with specialization profiles and notes that future model exchange support was expected for specialization profiles.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the main changes and gives translation guidance for removed concepts, merged behavior elements, implementation event, invalid relationships, and path aggregation.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Conversion. The paper describes conversion without and with specialization profiles and notes that future model exchange support was expected for specialization profiles.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Multiplicity on Relationships. The paper describes multiplicity as an important new feature and gives examples involving data constraints, process instances, server clusters, and mandatory service realization.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Conversion. The paper describes conversion without and with specialization profiles and notes that future model exchange support was expected for specialization profiles.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Advantages. The paper lists reduced concept count, reduced model complexity, more natural mapping to BPMN and UML, postponed implementation decisions, cross domain execution, and assignment of non human actors to roles as advantages of the new structure.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, pages 9 to 10. The paper describes an AI-powered claims assessor collaborating with human employees in claim handling, with high risk claims requiring a senior legal specialist.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Advantages. The paper states that assigning non human actors to roles does not imply machine accountability, because responsibility and accountability are different notions.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 1.2, 1.3, 2.16, and 3.2.1. The specification describes ArchiMate as a language for stakeholder oriented architecture views, defines relationships as typed connections, specifies conformance requirements for relationships and domains, and defines the core domains including the Common Domain.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Chapter 14, Language Customization Mechanisms. The specification explains specialization of concrete concepts, inheritance of properties, specialization of relationships, and profile based customization while preserving the underlying definitions.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Multiplicity on Relationships. The paper explains that multiplicity supports data constraints, multiple process instances, server cluster sizing, and mandatory service realization.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 1.2, 1.3, 2.16, and 3.2.1. The specification describes ArchiMate as a language for stakeholder oriented architecture views, defines relationships as typed connections, specifies conformance requirements for relationships and domains, and defines the core domains including the Common Domain.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Motivation for Changes. The paper states that without housekeeping, legacy and conceptual debt would be carried forward indefinitely and burden users with increasing baggage.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Why Not Simplify More?. The paper explains that the Technology Domain still covers both information technology and physical technology and that physical technology concepts matter for operational resilience, Industry 4.0, digital twins, defense, and similar use cases.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 1.1, 1.2, and 13.3. Section 1.1 identifies ArchiMate as a visual Enterprise Architecture modeling language and states that the standard provides concepts and iconography for the representation of Architecture Descriptions. Section 1.2 explains that ArchiMate supports stakeholder-oriented depictions of architecture information. Section 13.3 defines architecture views and viewpoints, including views as parts of an Architecture Description addressing stakeholder concerns.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Motivation for Changes. The paper lists the ArchiMate Manifesto principles, including simplicity over comprehensiveness, collaboration over coverage, people over tools, and communicating architecture over other use cases.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Motivation for Changes. The paper lists the ArchiMate Manifesto principles, including simplicity over comprehensiveness, collaboration over coverage, people over tools, and communicating architecture over other use cases.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 4.2.2, Process. The specification states that high-level business, end-to-end, macro flow, workflow, and automated processes can be expressed with process, while detailed activity flow is typically modeled in BPMN.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.2.2, Aspects of the ArchiMate Language. The specification explains active structure, behavior, and passive structure through the natural language analogy of subject, verb, and object.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 1.3, 2.16, and Chapter 5. The specification defines relationships as typed connections, classifies them into structural, dependency, dynamic, and other relationships, and requires conforming implementations to support the normative relationship rules.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 2.1, 2.2, and 3.2.1. The specification defines the ArchiMate Core Language as Common, Business, Application, and Technology, and the full language as adding Motivation, Strategy, and Implementation and Migration.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 1.2, Overview. The specification follows the TOGAF definition of enterprise and positions ArchiMate as a language for describing Enterprise Architectures.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, New Language Structure Depiction. The paper explains the relation between TOGAF architecture domains and ArchiMate domains.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.2.1, Domains of the ArchiMate Language. The specification states that ArchiMate does not define a specific information or data domain and instead supports information modeling through passive structure elements across domains.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Why Not Simplify More?. The paper explains why the Technology Domain still includes both information technology and physical technology, and why physical concepts remain important.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Chapter 14, Language Customization Mechanisms. The specification describes attributes, profiles, and specialization of concepts as customization mechanisms.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.8, Use of Colors. The specification states that colors have no formal semantics, although they may be used as notational cues.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Merging Behavior Elements in the ArchiMate Core Metamodel. The paper states that the old layers were not abstraction layers and that abstraction is handled through relationships such as realization, assignment, and composition or aggregation.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Motivation for Changes. The paper lists the ArchiMate Manifesto principles, including simplicity over comprehensiveness, collaboration over coverage, people over tools, and communicating architecture over other use cases.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the removed concepts, merged behavior elements, implementation event conversion, invalid relationship conversion, path change, and other migration guidance.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Merging Behavior Elements in the ArchiMate Core Metamodel and New Language Structure Depiction. The paper states that ArchiMate layers were not abstraction layers and explains the move from layered matrix to domain based Hexagonion.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Advantages. The paper lists reduced concept count, reduced model complexity, more natural mapping to BPMN and UML, delayed implementation decisions, cross domain execution, and assignment of non human actors to roles.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Chapter 14, Language Customization Mechanisms. The specification describes attributes, profiles, and specialization of concepts as mechanisms for customizing the language.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.6, Multiplicity. The specification defines multiplicity on relationship ends and explains the notation for exact, optional, unbounded, and ranged participation.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 5.8 and Appendix B. The specification explains relationship derivation, valid derivation rules, and the distinction between valid and potential derivations.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Motivation for Changes. The paper explains standards inertia, conceptual debt, bloat, and the ArchiMate Manifesto principles behind the version 4 cleanup.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists the removed concepts, merged behavior elements, implementation event conversion, invalid relationship conversion, path change, and other migration guidance.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.1, Language Design Considerations. The specification describes simplicity, understandability, and communication among people as central design considerations.↩︎
Marc Lankhorst and Jean-Baptiste Sarrodie, The Motivation for Changes in the ArchiMate® 4 Specification, The Open Group White Paper W262, April 2026, Motivation for Changes. The paper lists the ArchiMate Manifesto principles, including simplicity over comprehensiveness, collaboration over coverage, people over tools, and communicating architecture over other use cases.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.5, Abstraction in the ArchiMate Language, and Section 5.6, Multiplicity. The specification states that ArchiMate intentionally does not support a general distinction between types and instances, while multiplicity can express constraints on instances of elements.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification maps removed elements such as constraint, contract, gap, representation, and interactions to specializations of more fundamental concepts.↩︎
Object Management Group, Unified Modeling Language (UML), Version 2.5.1, specification metadata page. OMG describes UML as a specification defining a graphical language for visualizing, specifying, constructing, and documenting the artifacts of distributed object systems. The page also identifies UML 2.5.1 as a formal specification published in December 2017 and links to the normative PDF and machine-readable documents.↩︎
Object Management Group, MetaObject Facility (MOF) official page. OMG describes MOF as the foundation of its model management environment for exporting, importing, transporting, storing, retrieving, rendering, transforming, and using models for code generation.↩︎
Object Management Group, Meta Object Facility (MOF) Core Specification, Version 2.5.1, Section 1, Scope. The specification states that MOF provides the basis for metamodel definition in OMG’s family of Model Driven Architecture languages and is based on a simplification of UML 2 class modeling capabilities.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Sections 1.1, 1.2, and 13.3. Section 1.1 identifies ArchiMate as a visual Enterprise Architecture modeling language and states that the standard provides concepts and iconography for the representation of Architecture Descriptions. Section 1.2 explains that ArchiMate supports stakeholder-oriented depictions of architecture information. Section 13.3 defines architecture views and viewpoints, including views as parts of an Architecture Description addressing stakeholder concerns.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 3.1, Language Design Considerations. The specification states the design principle of collaboration over coverage and gives detailed software design with UML as an example of a need better covered by another language.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification lists removed concepts, merged behavior elements, the generic role and collaboration changes, the domain terminology change, the Common Domain, the path change, and multiplicity.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Appendix E.4, Changes from Version 3.2 to This Document. The specification gives migration guidance for constraint, contract, gap, representation, interactions, other behavior elements, implementation event, invalid relationships, and path aggregation.↩︎
Object Management Group, Unified Modeling Language, Version 2.5.1, Section 12, Profiles, including the sections on profiles and stereotypes. The UML specification defines profiles as limited extensions to the UML metamodel and stereotypes as profile-defined extensions of UML metaclasses.↩︎
Object Management Group, Unified Modeling Language, Version 2.5.1, specification metadata page. OMG identifies UML 2.5.1 as the formal Unified Modeling Language specification and provides the normative PDF and machine readable specification documents.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 14.1, Adding Attributes to ArchiMate Concepts. The specification explains that ArchiMate concepts can have attributes and that profiles define sets of attributes that can be coupled to concepts.↩︎
The Open Group, ArchiMate® 4 Specification, Document C260, April 2026, Section 14.2, Specialization of Concepts. The specification explains that concrete concepts can be specialized, that specialized elements inherit the properties of the elements they specialize, and that specialized relationships are also supported.↩︎
@online{montano2026,
author = {Montano, Antonio},
title = {ArchiMate 4 and the {Cartography} of {Complexity}},
date = {2026-05-02},
url = {https://antomon.github.io/longforms/archimate_4_and_the_cartography_of_complexity/},
langid = {en}
}