Classification of ArchiMate elements by their architectural layer — the primary horizontal grouping in the ArchiMate framework.
Editorial Note: Each layer concept's skos:narrower list must match the concrete OWL classes in archimate3.2-onto.ttl that have the corresponding LayerElement as a superclass.
Elements representing strategic concepts: resources, capabilities, value streams, and courses of action. The Strategy layer provides the bridge between business goals and the architecture that supports them.
Scope Note: Use Strategy elements to model high-level planning artifacts. Capabilities describe what the organization can do, value streams describe how value is delivered, and courses of action describe the plans to get there. Strategy elements are typically realized by Business, Application, and Technology layer elements.
Change Note: 3.0: Introduced with Resource, Capability, and CourseOfAction. 3.1: ValueStream added.
Elements representing business concepts: actors, roles, processes, functions, services, objects, and products. The Business layer describes the organization's operations and how it creates value.
Scope Note: Model the organizational structure (actors, roles, collaborations), the behavior they perform (processes, functions, services), and the information they work with (business objects, contracts). Business layer elements are typically served by Application layer elements.
Change Note: 3.0: Value and Meaning moved from Business Layer to Motivation elements. Location moved to generic metamodel. 3.2: Improved definitions of business function and product.
Elements representing application concepts: components, interfaces, functions, services, and data objects. The Application layer describes the software systems that support business processes.
Scope Note: Model the application landscape: components represent deployable software units, interfaces represent APIs and integration points, and data objects represent structured data. Application elements serve Business layer elements and are realized by Technology layer elements.
Change Note: 3.0: ApplicationProcess added to increase regularity across layers. Events added at all layers.
Elements representing technology concepts: nodes, devices, system software, networks, paths, and artifacts. The Technology layer describes the infrastructure that hosts and runs applications.
Scope Note: Model the infrastructure: nodes represent compute resources, devices represent physical hardware, system software represents platforms and middleware, and artifacts represent deployable packages. Technology elements realize Application layer elements.
Change Note: 3.0: Renamed from 'Infrastructure' to 'Technology'. TechnologyProcess, TechnologyInteraction, TechnologyCollaboration added. CommunicationPath renamed to Path with extended meaning. Events added. 3.2: Device, SystemSoftware, Facility, Equipment no longer subtypes of Node but of technology internal active structure element; composition and aggregation with Node added.
Elements representing physical concepts: equipment, facilities, distribution networks, and materials. The Physical layer describes tangible assets and physical infrastructure.
Scope Note: Use Physical elements when modeling logistics, manufacturing, or data center infrastructure where tangible assets matter. Equipment represents machines and tools, facilities represent buildings and sites, and distribution networks represent physical transport links.
Change Note: 3.0: Introduced with Equipment, Facility, DistributionNetwork, and Material. 3.2: Made part of the Technology Layer chapter instead of a separate chapter.
Elements representing implementation and migration concepts: work packages, deliverables, events, plateaus, and gaps. This layer supports planning and managing architecture transitions.
Scope Note: Use these elements for roadmapping and transition planning. Plateaus represent stable architecture states (baseline, target), gaps represent differences between plateaus, and work packages represent the projects that close those gaps.
Change Note: 3.0: ImplementationEvent added. 3.2: Composition and aggregation from Plateau to Outcome added. Changed default color of Plateau and Gap to match other Implementation and Migration elements.
Classification of ArchiMate elements by their structural aspect — the vertical dimension in the ArchiMate framework (active structure, behavior, passive structure, motivation, composite).
Editorial Note: Aspect concepts group elements from multiple OWL superclasses. When the abstract class hierarchy in archimate3.2-onto.ttl changes, update the narrower lists here accordingly.
Elements that can perform behavior — the subjects of activity. Includes actors, components, nodes, and their interfaces. Active structure elements are assigned to behavior elements.
Scope Note: Active structure elements are the 'who' or 'what' that performs behavior. Internal active structure (actors, components, nodes) can be assigned to behavior. External active structure (interfaces) exposes services to the environment. Assignment relationships connect active structure to behavior.
Editorial Note: Direct narrower list contains only elements that are ActiveStructureElement but not InternalActiveStructureElement or ExternalActiveStructureElement (i.e., Path, CommunicationNetwork, DistributionNetwork, Resource). Internal and external sub-concepts carry the rest.
Internal active structure elements — entities capable of performing behavior: actors, roles, collaborations, components, and nodes.
Scope Note: These are the performers — the entities that do things. They are connected to behavior via assignment relationships. In diagrams, internal active structure elements are typically shown as boxes (actors, components, nodes). They 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 are the boundary between an element and its environment. They expose services and hide internal complexity. A business interface might be a customer portal or call center channel. An application interface might be a REST API. A technology interface might be a network endpoint. Interfaces are typically composed by the internal active structure element they belong to.
Elements on which behavior is performed — objects, artifacts, and materials. Passive structure elements are accessed by behavior elements.
Scope Note: Passive structure elements are the 'what' that behavior acts upon — business objects, data objects, artifacts, and materials. They are connected to behavior via access relationships (read, write, read-write).
Editorial Note: Includes Deliverable and Gap which are also classified under Implementation and Migration. These elements have dual classification by aspect and by layer.
Elements representing dynamic behavior — processes, functions, interactions, events, and services. Behavior elements describe what active structure elements do.
Scope Note: Behavior elements describe the 'how'. Internal behavior (processes, functions) is performed by active structure elements via assignment. External behavior (services) is exposed through interfaces. Events trigger or are triggered by other behavior. Use serving relationships to connect services to their consumers.
Editorial Note: Direct narrower list contains only elements that are BehaviorElement but not InternalBehaviorElement, ExternalBehaviorElement, or Event (i.e., Capability, ValueStream, CourseOfAction). Internal behavior, external behavior, and event sub-concepts carry the rest.
Internal behavior elements — units of activity performed by active structure elements: processes, functions, and interactions.
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 (e.g., skill, resource). Interactions are collective behavior performed by collaborations. Internal behavior is assigned to internal active structure and realizes external behavior (services).
External behavior elements (services) — explicitly defined exposed behavior accessible through interfaces.
Scope Note: Services are the externally visible behavior — what an element offers to its consumers. A business service might be 'claims processing'. An application service might be 'payment authorization'. A technology service might be 'data storage'. Services are realized by internal behavior (processes, functions) and exposed through interfaces. Use serving relationships to connect services to their consumers.
Event elements — instantaneous state changes that trigger or are triggered by other behavior.
Scope Note: Events represent something that happens at a point in time — a state change that triggers or is triggered by other behavior. Use triggering relationships to connect events to the behavior they initiate or that produces them. Events can be external (received from outside) or internal (produced by a process).
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 core elements.
Change Note: 3.0: Renamed from 'Motivation Extension' to motivation elements. Outcome introduced. Value and Meaning moved here from Business Layer. 3.2: Improved definitions of outcome and constraint.
Composite elements that may combine multiple aspects or layers — 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.
Change Note: 3.0: Location moved from Business Layer to generic metamodel. Grouping concept improved.
Strategy elements viewed as an aspect — resources, capabilities, value streams, and courses of action that bridge business goals to architecture.
Scope Note: Strategy elements operate at a higher abstraction level than core layer elements. Capabilities describe organizational abilities, value streams describe end-to-end value delivery, and courses of action describe plans. They are realized by combinations of Business, Application, and Technology elements.
Classification of ArchiMate relationship types by their semantic category.
Editorial Note: Narrower lists reference the qualified relationship classes (e.g., am:Composition), not the unqualified predicates (e.g., am:composedOf). Keep in sync with the relationship type declarations in archimate3.2-onto.ttl.
Relationships modeling structural dependencies between elements: composition (part-of), aggregation (groups), assignment (performs), and realization (implements).
Scope Note: Structural relationships define how elements are organized. Composition is the strongest (part cannot exist without the whole), aggregation is weaker (grouping), assignment connects active structure to behavior, and realization connects logical to physical. Ordered by strength in :StructuralStrength.
Change Note: 3.0: Restructured from the 2.1 relationship categories. Assignment given directional notation (arrow replaces black circle).
Relationships modeling dependencies between elements: serving (provides functionality), access (reads/writes data), influence (affects motivation), and association (any other dependency).
Scope Note: Dependency relationships express how elements rely on each other. Serving connects a provider to a consumer (typically across layers), access connects behavior to passive structure (with read/write direction), influence connects any element to a motivation element (with positive/negative strength), and association — the weakest, specification 5.2.4 — any two elements where no other relationship is appropriate. Ordered by strength in :DependencyStrength.
Change Note: 3.0: 'Used By' renamed to 'Serving'. Influence notation changed for consistency with other dependency relationships. Cross-layer relationship constraints relaxed.
Relationships modeling dynamic behavior between elements: triggering (temporal/causal) and flow (transfer of information, goods, or money).
Scope Note: Dynamic relationships express temporal and causal dependencies. Triggering indicates that one behavior causes another to start. Flow indicates transfer of something (data, goods, money) between behavior elements. Both are directional.
Change Note: 3.0: Relationships to other relationships allowed (e.g., associating objects with flows). 3.1: Derivation rules further improved and formalized.
Relationship connectors (junctions) used to combine relationships of the same type using AND or OR logic.
Editorial Note: Junctions are modeled as OWL classes (am:Junction_And, am:Junction_Or) subclassing arch:Element, not arch:QualifiedRelationship. They are not relationship types.
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).
From a facility to a node — a device, system software, equipment or a facility among them, which the ontology classifies as nodes — composition is proposed first, and then :ProposalOrder.
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 112 also draws composition and 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).
