Classification of ArchiMate 4.0 elements by domain and by aspect, and of its relationships by category, with the order of strength the derivation rules apply and the order in which a modelling tool proposes them.
ArchiMate 4.0 Concept Scheme
▼Element by Domain
Classification of ArchiMate 4.0 elements by their architectural domain — the primary organizational grouping in the ArchiMate 4.0 framework (replacing layers from 3.x).
Editorial Note: Each domain concept's skos:narrower list must match the concrete OWL classes in archimate4-onto.ttl that have the corresponding DomainElement as a superclass.
Generic, cross-domain elements shared across Business, Application, and Technology. New in ArchiMate 4.0, the Common Domain contains behavior elements (Process, Function, Event, Service) that were previously duplicated per layer, plus generic active structure elements (Role, Collaboration, Path) and composite elements (Grouping, Location).
Scope Note: The Common Domain is the major structural change in ArchiMate 4.0. Process, Function, Event, and Service are now single cross-domain elements — use domain-specific assignment to indicate which domain they belong to in a given context. Role and Collaboration are also generic. When migrating from 3.2, map BusinessProcess/ApplicationProcess/TechnologyProcess to Process, and similarly for Function, Event, and Service.
Editorial Note: This is the largest domain. When adding elements, verify they are genuinely cross-domain. Domain-specific elements belong in their respective domain concepts.
Change Note: 4.0: New domain. Merges per-layer behavior elements into cross-domain concepts: BusinessProcess/ApplicationProcess/TechnologyProcess → Process, BusinessFunction/ApplicationFunction/TechnologyFunction → Function, BusinessEvent/ApplicationEvent/TechnologyEvent/ImplementationEvent → Event, BusinessService/ApplicationService/TechnologyService → Service. Merges per-layer active structure: BusinessRole → Role, BusinessCollaboration/ApplicationCollaboration/TechnologyCollaboration → Collaboration. Path moved here from Technology Layer. Grouping and Location moved here from generic metamodel.
Elements specific to the business domain: actors, interfaces, objects, and products. In ArchiMate 4.0, behavior elements previously in the Business layer (BusinessProcess, BusinessFunction, etc.) have been merged into the Common Domain.
Scope Note: In 4.0, the Business Domain retains only domain-specific active and passive structure: actors (who performs), interfaces (channels), objects (information), and products (offerings). Behavior is modeled using Common Domain elements (Process, Function, Service) assigned to business actors.
Change Note: 4.0: BusinessRole, BusinessCollaboration moved to Common Domain as generic Role and Collaboration. BusinessProcess, BusinessFunction, BusinessInteraction, BusinessEvent, BusinessService moved to Common Domain as generic elements. Contract removed (replace with specialization of BusinessObject). Representation removed (replace with specialization of DataObject, Artifact, or Material).
Elements specific to the application domain: components, interfaces, and data objects. In ArchiMate 4.0, behavior elements previously in the Application layer have been merged into the Common Domain.
Scope Note: Model the software landscape: components represent deployable software units, interfaces represent APIs and integration points, and data objects represent structured data. Behavior is modeled using Common Domain elements (Process, Function, Service) assigned to application components.
Change Note: 4.0: ApplicationCollaboration, ApplicationFunction, ApplicationInteraction, ApplicationProcess, ApplicationEvent, ApplicationService moved to Common Domain as generic elements.
Elements specific to the technology and physical domain: nodes, devices, system software, networks, equipment, facilities, artifacts, and materials. In ArchiMate 4.0, the Technology and Physical layers from 3.x are merged into a single Technology Domain.
Scope Note: Model infrastructure and physical assets in a single domain. Nodes represent compute resources, devices represent hardware, system software represents platforms, and equipment/facilities represent physical assets. The 3.x Physical layer elements are now part of this domain.
Change Note: 4.0: Technology and Physical layers merged into a single domain. TechnologyCollaboration, TechnologyFunction, TechnologyProcess, TechnologyInteraction, TechnologyEvent, TechnologyService moved to Common Domain as generic elements. Path moved to Common Domain. Aggregation from Path to technology internal active structure element replaced by realization from active structure element to Path. Relationships can now have multiplicity.
Elements representing strategic concepts: resources, capabilities, value streams, and courses of action.
Scope Note: Use Strategy elements for capability-based planning and strategic alignment. Capabilities describe what the organization can do, value streams describe how value flows to stakeholders, and courses of action describe the plans to achieve goals. Strategy elements are realized by elements from other domains.
Elements representing the context and reasons behind the architecture: stakeholders, drivers, goals, requirements, principles, and values.
Scope Note: Capture the 'why' behind architecture decisions. Stakeholders have concerns, drivers motivate change, assessments analyze the current state, goals define desired outcomes, and requirements constrain the solution. Influence relationships connect motivation elements to each other and to elements in other domains.
Elements supporting planning and execution of architecture changes: work packages, deliverables, and plateaus.
Scope Note: Use for roadmapping and transition planning. Plateaus represent stable architecture states (baseline, target), and work packages represent the projects that transition between them. Note: Gap and ImplementationEvent from 3.x have been removed in 4.0.
Change Note: 4.0: Gap removed (replace with specialization of Assessment or Deliverable). ImplementationEvent removed (replaced by generic Event in Common Domain). Constraint removed (replace with specialization of Requirement).
Classification of ArchiMate 4.0 elements by their structural aspect — behaviour, structure, motivation, and composite.
Editorial Note: Aspect concepts group elements from multiple OWL superclasses. When the abstract class hierarchy in archimate4-onto.ttl changes, update the narrower lists here accordingly.
Elements that can perform behavior — the subjects of activity. Includes actors, components, nodes, roles, collaborations, and their interfaces.
Scope Note: Active structure elements are the 'who' or 'what' that performs behavior. Internal active structure (actors, components, nodes, roles, collaborations) can be assigned to behavior. External active structure (interfaces) exposes services to the environment. In 4.0, Role and Collaboration are generic Common Domain elements usable across all domains.
Editorial Note: Direct narrower list contains only elements that are ActiveStructureElement but not InternalActiveStructureElement or ExternalActiveStructureElement (i.e., Path, CommunicationNetwork, DistributionNetwork). Internal and external sub-concepts carry the rest.
Internal active structure elements — entities capable of performing behavior: actors, roles, collaborations, components, nodes, devices, system software, equipment, and facilities.
Scope Note: The performers — connected to behavior via assignment. In 4.0, Role and Collaboration are generic Common Domain elements. Can be composed of or aggregated with other internal active structure elements.
External active structure elements (interfaces) — points of access where services are exposed to the environment.
Scope Note: Interfaces expose services and hide internal complexity. Typically composed by the internal active structure element they belong to. Assigned to the services they expose.
Elements on which behavior is performed — objects, artifacts, materials, deliverables, and resources.
Scope Note: Passive structure elements are the 'what' that behavior acts upon — business objects, data objects, artifacts, materials, deliverables, and resources. They are connected to behavior via access relationships (read, write, read-write).
Editorial Note: Includes Resource (Strategy) and Deliverable (Implementation and Migration) which have dual classification by aspect and by domain.
Elements representing dynamic behavior — processes, functions, events, services, capabilities, value streams, courses of action, and work packages.
Scope Note: Behavior elements describe the 'how'. In 4.0, Process, Function, Event, and Service are cross-domain — they belong to the Common Domain and are assigned to domain-specific active structure elements. Use serving relationships to connect services to their consumers.
Editorial Note: Direct narrower list contains only elements that are BehaviorElement but not in the InternalBehavior, ExternalBehavior, or Event sub-concepts (i.e., Capability, ValueStream, CourseOfAction, WorkPackage). Sub-concepts carry the rest.
Internal behavior elements — units of activity: processes and functions.
Scope Note: Internal behavior is what active structure elements actually do. Processes are sequences of steps with a defined outcome. Functions are collections of behavior grouped by criteria. In 4.0, these are cross-domain Common Domain elements assigned to domain-specific active structure. Internal behavior realizes external behavior (services).
External behavior elements (services) — explicitly defined exposed behavior.
Scope Note: Services are the externally visible behavior offered to consumers. Realized by internal behavior and exposed through interfaces. In 4.0, Service is a single cross-domain element in the Common Domain. Use serving relationships to connect services to their consumers.
Event elements — state changes that trigger or are triggered by other behavior.
Scope Note: Events represent something that happens at a point in time. Use triggering relationships to connect events to the behavior they initiate or that produces them. In 4.0, Event is a single cross-domain element in the Common Domain.
Composite elements that may combine multiple aspects or domains — products, groupings, locations, and plateaus.
Scope Note: Composite elements cross aspect boundaries. Products bundle services and passive structure into a customer-facing offering. Groupings are generic containers for organizing any set of elements. Locations represent physical or logical places where elements reside or behavior occurs. Plateaus represent stable architecture states used in transition planning.
Motivation elements — the context and reasons behind the architecture: stakeholders, drivers, goals, requirements, principles, and values.
Scope Note: Use Motivation elements to capture the 'why' behind architecture decisions. Stakeholders have concerns, drivers motivate change, assessments analyze the current state, goals define desired outcomes, and requirements constrain the solution. Influence relationships connect motivation elements to each other and to elements in other domains.
Classification of ArchiMate 4.0 relationship types by the four categories of Chapter 5: structural, dependency, dynamic and other.
Editorial Note: Narrower lists reference the qualified relationship classes (am4:Composition), not the unqualified predicates (am4:composedOf). A kind of relationship — am4:ReadAccess, am4:DirectedAssociation — is classified through its superclass. Keep in sync with the relationship type declarations in archimate4-onto.ttl.
Relationships that model the static construction or composition of concepts: composition, aggregation, assignment and realization.
Scope Note: Composition is a kind of aggregation that adds existence dependency. Assignment allocates responsibility, performance of behaviour, storage or execution; realization relates a more abstract element to one that implements or creates it. Ordered by strength in :StructuralStrength.
Relationships that model how elements are used by or depend on other elements: serving, access, influence and association.
Scope Note: Association is a dependency relationship in the specification (5.2.4): the weakest of them, used where no other relationship is appropriate. Ordered by strength in :DependencyStrength.
The dependency relationships ordered by strength, weakest first: association, influence, access, serving. Two dependency relationships in line may derive the weaker of the two (PDR 7).
Between two events, triggering is proposed first — one event causes the next — and then :ProposalOrder. Table B.5 gives triggering between events only as derived, and aggregation as the relationship a modeller may draw directly.
From a plateau, aggregation is proposed first — a plateau is the set of elements that make up an architecture at a point in time — and then :ProposalOrder. Figure 12-5 also draws realization.
The order in which a modelling tool proposes the relationships the metamodel figures draw between two elements: realization, serving, access, influence, triggering, flow, aggregation, composition, assignment, specialization, association.
The structural relationships ordered by strength, weakest first: realization, assignment, aggregation, composition. Two structural relationships in line derive the weaker of the two (DR 2).
