Linked.Archi ArchiMate 4.0 Ontology
type: Ontology
version IRI: 4.0#
license: http://creativecommons.org/licenses/by/4.0/
created: 2026-04-19
creator: Kalin Maldzhanski
description: Linked.Archi ArchiMate ontology aligned to the ArchiMate 4.0 specification (the "Hexagonion"). ArchiMate 4.0 replaces the layer-based structure of 3.x with a domain-based organization (Common, Business, Application, Technology, Strategy, Motivation, Implementation & Migration). Behavior elements that were previously duplicated per layer (e.g., BusinessProcess, ApplicationProcess, TechnologyProcess) are merged into single cross-domain elements (Process, Function, Event, Service). New Common Domain elements (Role, Collaboration, Path) are introduced as generic, domain-independent concepts. This is not an official Open Group document.
issued: 2026-04-29
modified: 2026-04-29
publisher: linked.archi
publisher: Linked.Archi
source: archimate4-doc
status: draft
preferred namespace prefix: am4
citation: Linked.Archi ArchiMate 4.0 Ontology
prior version: 3.2#
version info: 4.0
history note: 4.0.0: Major revision from ArchiMate 3.2 to 4.0. Layers replaced by domains (Common, Business, Application, Technology, Strategy, Motivation, Implementation & Migration). Per-layer behavior elements (BusinessProcess, ApplicationProcess, TechnologyProcess, etc.) merged into single cross-domain elements (Process, Function, Event, Service). Per-layer collaborations and roles merged into Common Domain. Removed elements: Interaction, Contract, Representation, Gap, ImplementationEvent, Constraint. New namespace archimate4/onto# introduced for breaking metamodel changes. Aligned to Linked.Archi core ontology conventions and the qualified relationship pattern.
scope note: This namespace (archimate4/onto#) covers ArchiMate 4.x. It is separate from archimate3/onto# because the 3.2→4.0 transition introduced breaking metamodel changes: layers were replaced by domains, many per-layer elements were merged into cross-domain equivalents, and several elements were removed entirely. The two namespaces can coexist for migration purposes.

Accesses
type: ObjectProperty
definition: Indicates that a behavior element may access a business or data object.
domain includes: ActiveStructureElement
domain includes: BehaviorElement
range includes: PassiveStructureElement

Aggregates
type: ObjectProperty
definition: Indicates that an element combines one or more other elements.
domain includes: Element
range includes: Element

Assigned To
type: ObjectProperty
definition: Indicates the allocation of responsibility, performance of behavior, storage, or execution.
domain includes: ActiveStructureElement
domain includes: PassiveStructureElement
range includes: BehaviorElement

Associated With
type: ObjectProperty
definition: Indicates an unspecified relationship, or one that is not represented by another ArchiMate relationship.
domain includes: Element
range includes: Element

Composed Of
type: ObjectProperty
sub property of: Aggregates
definition: Indicates that an element consists of one or more other elements.
domain includes: Element
range includes: Element

Flows To
type: ObjectProperty
definition: Indicates transfer from one element to another.
domain includes: BehaviorElement
domain includes: StrategyElement
range includes: BehaviorElement
range includes: StrategyElement

Influences
type: ObjectProperty
definition: Indicates that an element affects the implementation or achievement of some motivation element.
domain includes: ActiveStructureElement
domain includes: BehaviorElement
domain includes: MotivationElement
domain includes: PassiveStructureElement
domain includes: StrategyElement
range includes: MotivationElement
range includes: StrategyElement

qualified Accesses
type: ObjectProperty
range: Access
definition: Navigates from a source element to an Access qualified relationship resource. The Access resource carries the accessType (Read, Write, ReadWrite).
domain includes: ActiveStructureElement
domain includes: BehaviorElement
unqualified form: Accesses

qualified Aggregation
type: ObjectProperty
range: Aggregation
definition: Navigates from a source element to an Aggregation qualified relationship resource.
domain includes: Element
unqualified form: Aggregates

qualified Assignment
type: ObjectProperty
range: Assignment
definition: Navigates from a source element to an Assignment qualified relationship resource.
domain includes: ActiveStructureElement
domain includes: PassiveStructureElement
unqualified form: Assigned To

qualified Association
type: ObjectProperty
range: Association
definition: Navigates from a source element to an Association qualified relationship resource.
domain includes: Element
unqualified form: Associated With

qualified Composition
type: ObjectProperty
range: Composition
definition: Navigates from a source element to a Composition qualified relationship resource.
domain includes: Element
unqualified form: Composed Of

qualified Flow
type: ObjectProperty
range: Flow
definition: Navigates from a source element to a Flow qualified relationship resource.
domain includes: BehaviorElement
domain includes: StrategyElement
unqualified form: Flows To

qualified Influences
type: ObjectProperty
range: Influence
definition: Navigates from a source element to an Influence qualified relationship resource. The Influence resource carries the influenceStrength (+, ++, -, --).
domain includes: ActiveStructureElement
domain includes: BehaviorElement
domain includes: MotivationElement
domain includes: PassiveStructureElement
domain includes: StrategyElement
unqualified form: Influences

qualified Realization
type: ObjectProperty
range: Realization
definition: Navigates from a source element to a Realization qualified relationship resource.
domain includes: ActiveStructureElement
domain includes: BehaviorElement
domain includes: ImplementationAndMigrationElement
domain includes: PassiveStructureElement
domain includes: StrategyElement
unqualified form: Realizes

qualified Serves
type: ObjectProperty
range: Serving
definition: Navigates from a source element to a Serving qualified relationship resource.
domain includes: ActiveStructureElement
domain includes: BehaviorElement
unqualified form: Serves

qualified Specialization
type: ObjectProperty
range: Specialization
definition: Navigates from a source element to a Specialization qualified relationship resource.
domain includes: Element
unqualified form: Specializes

qualified Triggers
type: ObjectProperty
range: Triggering
definition: Navigates from a source element to a Triggering qualified relationship resource.
domain includes: BehaviorElement
domain includes: StrategyElement
unqualified form: Triggers

Realizes
type: ObjectProperty
definition: Indicates that an entity plays a critical role in the creation, achievement, sustenance, or operation of a more abstract entity.
domain includes: ActiveStructureElement
domain includes: BehaviorElement
domain includes: ImplementationAndMigrationElement
domain includes: PassiveStructureElement
domain includes: StrategyElement
range includes: ActiveStructureElement
range includes: BehaviorElement
range includes: MotivationElement
range includes: PassiveStructureElement
range includes: StrategyElement

Serves
type: ObjectProperty
definition: Indicates that an element provides its functionality to another element.
domain includes: ActiveStructureElement
domain includes: BehaviorElement
range includes: ActiveStructureElement
range includes: BehaviorElement

Specializes
type: ObjectProperty
definition: Indicates that an element is a particular kind of another element.
domain includes: Element
range includes: Element

Triggers
type: ObjectProperty
definition: Indicates a temporal or causal relationship between elements.
domain includes: BehaviorElement
domain includes: StrategyElement
range includes: BehaviorElement
range includes: StrategyElement

Access Type
type: DatatypeProperty
domain: Access
range: string
definition: Specifies the type of access: read, write, read-write, or unspecified.

Influence Strength
type: DatatypeProperty
domain: Influence
range: string
definition: Specifies the strength or sign of an influence (e.g., +, ++, -, --).

Access
type: Class
subclass of: QualifiedRelationship
source: sec-Access-Relationship
definition: An access relationship represents the ability of behavior and active structure elements to observe or act upon passive structure elements.
scope note: An access relationship indicates that a process, function, service, or event “does something” with a passive structure element; e.g., create, read, modify or delete a business or data object or an artifact; or produce, consume, move, transform, or destroy material. The relationship can also be used to indicate that the passive structure element . The relationship can also be used to indicate that the object is just associated with the behavior; e.g., it models the information that comes with an event, or the information that is made available as part of a service. The arrowhead, if present, indicates the creation, change, or usage of passive structure elements. The access relationship should not be confused with the UML dependency relationship, which uses a similar notation. Note that, at the metamodel level, the direction of the relationship is always from an active structure element or a behavior element to a passive structure element, although the notation may point in the other direction to denote “read” or “usage” access, and in both directions to denote “read-write” or “change” access. Care must be taken when using access with derived relationships because the arrow on the relationship has no bearing to its directionality. Alternatively, an access relationship can be expressed by nesting the passive structure element inside the behavior or active structure element that accesses it; for example, nesting a data object inside an application component. The “Create Invoice” process writes/creates the “Invoice” business object; the “Send Invoice” process reads that object.
was quoted from: sec-Access-Relationship
unqualified form: Accesses

ActiveStructureElement
type: Class
subclass of: StructureElement
source: sec-Active-Structure-Elements
definition: An internal active structure element represents an entity that is capable of performing behavior.
scope note: Superclass for all performers: internal active structure (actors, components, nodes, roles, collaborations) and external active structure (interfaces). Also includes paths, communication networks, and distribution networks.
was quoted from: sec-Active-Structure-Elements
is abstract class: true

Aggregation
type: Class
subclass of: QualifiedRelationship
source: sec-Aggregation-Relationship
definition: A composition relationship represents that an element combines one or more other concepts, where the existence of those concepts depends on that of the element.
scope note: The aggregation relationship has been inspired by the aggregation relationship in UML class diagrams. An aggregation relationship is always allowed between two elements of the same type. In addition to this, the metamodel explicitly defines other source and target elements that may be connected by an aggregation relationship. The interpretation of an aggregation relationship is that the whole or part of the source element aggregates the whole of the target concept. See also Section 5.1.5, “Semantics of Structural Relationships”.
was quoted from: sec-Aggregation-Relationship
unqualified form: Aggregates

And Junction
type: Class
subclass of: Element
definition: Used to connect relationships of the same type.

Application Component
type: Class
subclass of: ApplicationDomainElement
subclass of: InternalActiveStructureElement
source: sec-Application-Component
alternative label: Application
alternative label: Software Component
definition: An application component represents an encapsulation of application functionality aligned to implementation structure, which is modular and replaceable.
scope note: An application component is a self-contained unit. As such, it is independently deployable, re-usable, and replaceable. It encapsulates its behavior and data, exposes services, and makes them available through interfaces. An application component may be assigned (through a role) to one or more internal application behavior or application event. Application components can also be assigned to data objects, to express that the application is the repository, golden source, or single source of truth of that data. Cooperating application components can be aggregated in collaborations. Application interfaces of other application components may serve an application component. The name of an application component should preferably be a noun. The application component element is used to model entire applications (i.e., deployed and operational IT systems, as defined by the TOGAF Standard [C220]) and individual parts of such applications, at all relevant levels of detail. This is explained in Section 3.5, “Abstraction in the ArchiMate Language”.
was quoted from: sec-Application-Component

ApplicationDomainElement
type: Class
subclass of: Element
source: sec-application-Active-Structure-Elements
definition: Application Domain elements represent concepts specific to the application domain.
scope note: Domain marker for application-specific elements: components, interfaces, and data objects. Behavior is modeled using Common Domain elements assigned to application components.
was quoted from: sec-application-Active-Structure-Elements
is abstract class: true

Application Interface
type: Class
subclass of: ApplicationDomainElement
subclass of: ExternalActiveStructureElement
source: sec-Application-Interface
alternative label: API
definition: An application interface represents a point of access where an application component makes its services available to its environment.
scope note: An application interface specifies how the functionality of a component can be accessed by other elements. An application interface exposes services of an application component to the environment. The same service may be exposed through different interfaces and the same interface may expose multiple services. In a sense, an application interface specifies a contract that a component making this interface available must fulfill. This may include parameters, protocols used, pre- and post-conditions, and data formats. An application interface may be part of an application component through aggregation, which means that this interface is provided by that component and can serve other application components. An application interface can be assigned to services, which means that the interface exposes these services to the environment. The name of an application interface should preferably be a noun.
was quoted from: sec-Application-Interface

Artifact
type: Class
subclass of: PassiveStructureElement
subclass of: TechnologyDomainElement
source: sec-Artifact
alternative label: Binary
alternative label: Deployment Unit
alternative label: Package
definition: An artifact represents a piece of data that is used or produced in a software development process, or by deployment and operation of an IT system.
scope note: An artifact represents a “physical” element in the IT world. Artifact is a specialization of technology passive structure elements. It is typically used to model (software) products such as source files, executables, scripts, database tables, messages, documents, specifications, and model files. It can be accessed (created, deleted, read, written) by behavior elements. An instance (copy) of an artifact can be deployed on a device or system software; this is modeled with an assignment relationship. An artifact could be used to represent a physical data component that realizes a data object. An application component or system software may be realized by one or more artifacts. A data object may be realized by one or more artifacts. A device or system software element may be assigned to an artifact to model that the artifact is deployed on this element. Thus, the two typical ways to use the artifact element are as an execution component or as a data file. In fact, these could be defined as specializations of the artifact element. The name of an artifact should preferably be the kind of artifact or the name of the file it represents; e.g., “virtual image”, “monitoring script”, or “order.jar”. An artifact may consist of sub-artifacts.
was quoted from: sec-Artifact

Assessment
type: Class
subclass of: MotivationElement
source: sec-Assessment
definition: An assessment represents the result of an analysis of the state of affairs of the enterprise with respect to some driver.
scope note: An assessment may reveal strengths, weaknesses, opportunities, or threats for some area of interest. These need to be addressed by adjusting existing goals or setting new ones, which may trigger changes to the Enterprise Architecture. Strengths and weaknesses are internal to the organization. Opportunities and threats are external to the organization. Weaknesses and threats can be considered as problems that need to be addressed by goals that “negate” the weaknesses and threats. Strengths and opportunities may be translated directly into goals. For example, the weakness “Customers complain about the helpdesk” can be addressed by defining the goal “Improve helpdesk”. Or the opportunity “Customers favor insurances that can be managed online” can be addressed by the goal “Introduce online portfolio management”. The name of an assessment should preferably be a noun or a (very) short sentence.
was quoted from: sec-Assessment

Assignment
type: Class
subclass of: QualifiedRelationship
source: sec-Assignment-Relationship
definition: An assignment relationship represents the allocation of responsibility, performance of behavior, storage, or execution.
scope note: The assignment relationship links active structure elements with units of behavior that are performed by them, internal active structure elements (e.g., business actors) with roles fulfilled by them, and active structure elements with passive structure elements from the same domain. It can, for example, relate an internal active structure element with an internal behavior element, an interface with a service, or a node, device, and system software with an artifact. The full set of permitted relationships is listed in Appendix B, Relationships (Normative). In the ArchiMate language described in Section 3.2, “The ArchiMate Language”, it always points from active structure to behavior, from behavior to passive structure, and from active to passive structure. As with all structural relationships, an assignment relationship can also be expressed by nesting the model elements. The direction mentioned above is also the direction of nesting; for example, a role inside the business actor performing that role, a function inside an application component executing that function, or an artifact inside a node that stores it. The interpretation of an assignment relationship is that the whole or part of the source element is assigned the whole of the target element (see also Section 5.1, “Structural Relationships”). This means that if, for example, two active structure elements are assigned to the same behavior element, either of them can perform the complete behavior. If both active structure elements are needed to perform the behavior, the grouping element or a junction (see Section 5.5, “Junctions”) can be used, and if the combination of these elements has a more substantive and independent character, a collaboration would be the right way to express this. The “Finance” application component is assigned to the “Transaction Processing” function, and the “Payment Interface” is assigned to the “Payment Service”.
was quoted from: sec-Assignment-Relationship
unqualified form: Assigned To

Association
type: Class
subclass of: QualifiedRelationship
source: sec-Association-Relationship
definition: An association relationship represents an unspecified relationship, or one that is not represented by another ArchiMate relationship.
scope note: An association relationship is always allowed between two elements, or between a relationship and an element. The association relationship can be used when drawing a first high-level model where relationships are initially denoted in a generic way, and later refined to show more specific relationship types. In the metamodel pictures, some specific uses of the association relationship are explicitly shown. An association is undirected or directed. See also Section 5.2.5, “Semantics of Dependency Relationships”. It also shows an association between a flow relationship and this “Insurance Policy”, to indicate that the business object is transferred from “Policy Creation” to “Policy Management”.
was quoted from: sec-Association-Relationship
unqualified form: Associated With

BehaviorElement
type: Class
subclass of: Element
source: sec-Behavior-Elements
definition: An internal behavior element represents a unit of activity that can be performed by one or more internal active structure elements.
scope note: Superclass for all behavior: processes, functions, events, services, capabilities, value streams, courses of action, and work packages. In 4.0, core behavior elements (Process, Function, Event, Service) are cross-domain — they belong to the Common Domain.
was quoted from: sec-Behavior-Elements
is abstract class: true

Business Actor
type: Class
subclass of: BusinessDomainElement
subclass of: InternalActiveStructureElement
source: sec-Business-Actor
alternative label: Department
alternative label: Organization
alternative label: Person
definition: A business actor represents a business entity that is capable of performing behavior.
scope note: A business actor is a business entity as opposed to a technical entity; i.e., it belongs to the Business Domain. Actors may, however, include entities outside the actual organization; e.g., customers and partners. A business actor can represent such business entities at different levels of detail and may correspond to both an actor and an organizational unit in the TOGAF Standard [C220]. Examples of business actors are humans, departments, and business units. A business actor may be assigned to one or more roles. It can then perform the behavior to which these roles are assigned. Business actors can also be assigned to business objects, to express that someone is responsible for some specific information or another kind of business object. The name of a business actor should preferably be a noun. Business actors may be specific individuals or organizations; e.g., “John Smith” or “ABC Corporation”, or they may be generic; e.g., “customer” or “supplier”. ArchiMate modelers may represent generic organizational entities that perform behavior as either business actors or roles. For example, the business actor “Supplier” depicts an organizational entity, while the role “Supplier” depicts a responsibility. Specific or generic business actors can be assigned to carry responsibilities depicted as roles. For example, the specific business actor “ABC Corporation” or the generic business actor “Business Partner” can be assigned to the “Supplier” role.
was quoted from: sec-Business-Actor

BusinessDomainElement
type: Class
subclass of: Element
source: sec-business-Active-Structure-Elements
definition: Business Domain elements represent concepts specific to the business domain.
scope note: Domain marker for business-specific elements: actors, interfaces, objects, and products. Behavior is modeled using Common Domain elements assigned to business actors.
was quoted from: sec-business-Active-Structure-Elements
is abstract class: true

Business Interface
type: Class
subclass of: BusinessDomainElement
subclass of: ExternalActiveStructureElement
source: sec-Business-Interface
alternative label: Channel
definition: A business interface represents a point of access where a business actor makes services available to its environment.
scope note: A business interface exposes the functionality of a service that is provided by a business actor. It is often referred to as a channel (telephone, Internet, local office, etc.). The same service may be exposed through different interfaces. A business interface may be part of a business actor through an aggregation relationship, and a business interface may serve a role or business actor. A business interface may be assigned to one or more services, which means that these services are exposed by the interface. The name of a business interface should preferably be a noun.
was quoted from: sec-Business-Interface

Business Object
type: Class
subclass of: BusinessDomainElement
subclass of: PassiveStructureElement
source: sec-Business-Object
alternative label: Information Object
definition: A business object represents a conceptual passive element that has relevance from a business perspective.
scope note: The term “conceptual” in this context refers to the conceptual abstraction level used in, for example, data modeling. See also Section 3.5, “Abstraction in the ArchiMate Language”. As explained in that section, the ArchiMate language in general focuses on the modeling of types, not instances, since this is the most relevant at the Enterprise Architecture level of description. Hence a business object typically models an object type (cf. a UML class) of which multiple instances may exist in operations. Only occasionally, business objects represent actual instances of information produced and consumed by behavior elements such as processes. This is, in particular, the case for singleton types; i.e., types that have only one instance. A wide variety of types of business objects can be defined. Business objects are passive in the sense that they do not trigger or perform processes. A business object could be used to represent information assets that are relevant from a business point of view and can be realized by data objects. Business objects may be accessed (e.g., in the case of information objects, they may be created, read, or written) by a process, function, event, or service. A business object may have association, specialization, or aggregation relationships with other business objects. A business object may be realized by a data object or material. The name of a business object should preferably be a noun.
was quoted from: sec-Business-Object

Capability
type: Class
subclass of: BehaviorElement
subclass of: StrategyElement
source: sec-Capability
alternative label: Business Capability
definition: A capability represents an ability that an organizational entity, person, or system possesses.
scope note: In the field of business, strategic thinking and planning delivers strategies and high-level goals that are often not directly implementable in the architecture of an organization. These long-term or generic plans need to be specified and made actionable in a way that both business leaders and Enterprise Architects can relate to at a relatively high abstraction level. Capabilities help to reduce this gap by focusing on business outcomes. On one hand, they provide a high-level view of the current and desired abilities of an organization, in relation to its strategy and its environment. On the other hand, they are realized by various elements (people, processes, systems, and so on) that can be described, designed, and implemented using Enterprise Architecture approaches. Capabilities may also have serving relationships; for example, to denote that one capability contributes to another. Capabilities are classified as behavior in the ArchiMate language because they describe abilities: what the enterprise can (is able to) do (now or in the future). Capabilities are expressed in general, high-level terms that are typically realized by a combination of organization, people, processes, information, and technology. For example, business planning, customer management, or asset management. This capability concept corresponds to the business capability in the TOGAF Standard. Capabilities are typically aimed at achieving some outcome. Capabilities are themselves realized by core behavior elements. To denote that a set of core elements together realizes a capability, grouping can be used. Capabilities are often used for capability-based planning, to describe their evolution over time. To model such so-called capability increments, the specialization relationship can be used to denote that a certain capability increment is a specific version of that capability. Aggregating those increments and the core elements that realize them in plateaus (see :Plateau) can be used to model the …
was quoted from: sec-Capability

Collaboration
type: Class
subclass of: CommonDomainElement
subclass of: InternalActiveStructureElement
source: sec-Collaboration
change note: 4.0: Merges BusinessCollaboration, ApplicationCollaboration, and TechnologyCollaboration into a single generic element.
definition: A collaboration represents a collection of business actors, application components, nodes, devices, system software, equipment, facilities, roles, and/or other collaborations that work together to perform collective behavior.
scope note: In some cases, behavior is the collective effort of more than one internal active structure element. In fact, a collaboration of two or more internal active structure elements results in collective behavior that may be more than simply the sum of the behavior of the separate elements. Collaborations represent this collective effort. A collaboration is a (possibly temporary) collection of internal active structure elements (including other collaborations) which perform collaborative behavior. Unlike, say, a department, a collaboration need not have an official (permanent) status within the organization. A collaboration may be assigned to one or more processes or functions. A collaboration may aggregate interfaces that it provides to its environment, and interfaces may serve a collaboration. The name of a collaboration should preferably be a noun.
was quoted from: sec-Collaboration

CommonDomainElement
type: Class
subclass of: Element
source: sec-Common-Domain-Active-Structure-Elements
definition: Common Domain elements are generic, cross-domain concepts shared across Business, Application, and Technology.
scope note: New in 4.0. Contains behavior elements (Process, Function, Event, Service) that were previously duplicated per layer, plus generic active structure (Role, Collaboration, Path) and composite elements (Grouping, Location). Use domain-specific assignment to indicate context.
was quoted from: sec-Common-Domain-Active-Structure-Elements
is abstract class: true

Communication Network
type: Class
subclass of: ActiveStructureElement
subclass of: TechnologyDomainElement
source: sec-Communication-Network
alternative label: LAN
alternative label: Network
alternative label: WAN
definition: A communication network represents a set of IT structures for transmission, routing, and reception of data.
scope note: A communication network represents the physical communication infrastructure. It “provides the basic services to interconnect systems and provide the basic mechanisms for opaque transfer of data. It contains the hardware and software elements which make up the networking and physical communications links used by a system, and of course all the other systems connected to the network”, as described by the TOGAF Series Guide: The TOGAF Technical Reference Model (TRM). A communication network can be associated with the devices or system softwares it connects. The most basic communication network is a single link between two devices, but it may comprise multiple links and required network equipment or software. A network has properties such as bandwidth and latency. A communication network realizes one or more paths. It embodies the physical realization of the logical path between nodes. A communication network can consist of sub-networks. It can aggregate devices and system software to model the routers, switches, and firewalls that are part of the network infrastructure.
was quoted from: sec-Communication-Network

CompositeElement
type: Class
subclass of: Element
source: sec-Composite-Elements
definition: Composite elements consist of other concepts, possibly from multiple aspects or domains.
scope note: Elements that cross aspect boundaries: products (bundle services and objects), groupings (generic containers), locations (physical or logical places), and plateaus (stable architecture states).
was quoted from: sec-Composite-Elements
is abstract class: true

Composition
type: Class
subclass of: Aggregation
source: sec-Aggregation-Relationship
definition: A composition relationship represents that an element combines one or more other concepts, where the existence of those concepts depends on that of the element.
scope note: The composition relationship is a specialisation of the aggregation relationship that expresses an existence dependency: if a composite is deleted, its parts are deleted as well. A composition relationship is allowed in exactly the same cases where an aggregation relationship would be allowed. It follows the same semantics as aggregation relationships. See also Section 5.1.5, "Semantics of Structural Relationships".
was quoted from: sec-Aggregation-Relationship
unqualified form: Composed Of

Course of Action
type: Class
subclass of: BehaviorElement
subclass of: StrategyElement
source: sec-Course-of-Action
definition: A course of action represents an approach or plan for configuring some capabilities and resources of the enterprise, to achieve a goal.
scope note: A course of action represents what an enterprise has decided to do to achieve its objectives. Courses of action can be categorized as strategies and tactics. It is not possible to make a hard distinction between the two, but strategies tend to be long term and fairly broad in scope, while tactics tend to be short term and narrower in scope.
was quoted from: sec-Course-of-Action

Data Object
type: Class
subclass of: ApplicationDomainElement
subclass of: PassiveStructureElement
source: sec-Data-Object
alternative label: Data Asset
alternative label: Data Entity
definition: A data object represents data structured for automated processing.
scope note: A data object should be a self-contained piece of information with a clear meaning to the business, not just to the application level. Typical examples of data objects are a customer record, a client data set, or an insurance claim. As explained in Section 3.5, “Abstraction in the ArchiMate Language”, the ArchiMate language in general focuses on the modeling of types, not instances, since this is the most relevant at the Enterprise Architecture level of description. Hence a data object typically models a logical object type of which one or many instances may exist in operational applications. A function, process, or service can access data objects. A data object may be transferred via flow relations and used or produced by services. A data object may realize a business object and may be realized by an artifact. A data object may have association, specialization, or aggregation relationships with other data objects. The name of a data object should preferably be a noun.
was quoted from: sec-Data-Object

Deliverable
type: Class
subclass of: ImplementationAndMigrationDomainElement
subclass of: PassiveStructureElement
source: sec-Deliverable
definition: A deliverable represents a result of a work package.
scope note: Work packages produce deliverables. These may be results of any kind; e.g., reports, papers, services, software, physical products, etc., or intangible results such as organizational change. A deliverable may also be the implementation of (a part of) an architecture. Often, deliverables are contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders as is; for example, prescribed by the TOGAF Standard [C220].
was quoted from: sec-Deliverable

Device
type: Class
subclass of: InternalActiveStructureElement
subclass of: TechnologyDomainElement
source: sec-Device
alternative label: Hardware
alternative label: Physical Server
definition: A device represents IT hardware (possibly virtualized) used for processing, data storage, and similar purposes.
scope note: A device represents an IT resource with processing capability. It is typically used to model hardware systems such as mainframes, PCs, smartphones, or routers. It can also be used to model virtualized hardware; e.g., in an Infrastructure as a Service (IaaS) environment. Usually, devices are part of a node together with system software. Devices may be composite; i.e., aggregate sub-devices. Devices can be interconnected by communication networks as well as being assigned to artifacts and to system software, to model deployment of these on those devices. A node can contain one or more devices. Devices can be realized by artifacts; e.g., to model virtualized hardware systems. The name of a device should preferably be a noun phrase referring to the type of hardware (e.g., “IBM® Z Mainframe”) or its usage (e.g., “Application Server”).
was quoted from: sec-Device

Distribution Network
type: Class
subclass of: ActiveStructureElement
subclass of: TechnologyDomainElement
source: sec-Distribution-Network
definition: A distribution network represents a physical network used to transport materials or energy.
scope note: A distribution network represents the physical distribution or transportation infrastructure. It embodies the physical realization of the logical paths between facilities. A distribution network can be associated with the facilities it connects, and may realize one or more paths. A distribution network can consist of sub-networks and can aggregate facilities and equipment to model, for example, railway stations and trains that are part of a rail network.
was quoted from: sec-Distribution-Network

Driver
type: Class
subclass of: MotivationElement
source: sec-Driver
definition: A driver represents an external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them.
scope note: Drivers that are associated with a stakeholder are often called “concerns” of that stakeholder. Stakeholder concerns are defined in the TOGAF Standard [C220] as “an interest in a system relevant to one or more of its stakeholders. Concerns may pertain to any aspect of the system’s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability and may determine the acceptability of the system.” Drivers of change may be external to the enterprise (e.g., economic changes or changing legislation) and need not have a stakeholder associated with them. The name of a driver should preferably be a noun.
was quoted from: sec-Driver

Equipment
type: Class
subclass of: InternalActiveStructureElement
subclass of: TechnologyDomainElement
source: sec-Equipment
alternative label: Machine
alternative label: Physical Device
definition: Equipment represents a physical machine, tool, instrument, or livestock.
scope note: Equipment comprises all active processing elements that carry out physical processes in which materials are used or transformed. It is possible to model nodes that are formed by a combination of IT infrastructure (devices, system software) and physical infrastructure (equipment); e.g., an MRI scanner at a hospital, a production plant with its control systems, etc. Material can be accessed (e.g., created, used, moved, transformed, or otherwise manipulated) by equipment. Equipment may be assigned to material in order to model where the material is stored. Material may realize equipment. Equipment can serve other equipment as well as other active structure elements such as roles and business actors, and facilities can be assigned to equipment. A piece of equipment can aggregate other pieces of equipment or devices. Facilities can be assigned to equipment (i.e., equipment is installed and used in or on a facility). Equipment can be aggregated in a location. The name of a piece of equipment should preferably be a noun.
was quoted from: sec-Equipment

Event
type: Class
subclass of: BehaviorElement
subclass of: CommonDomainElement
source: sec-Event
alternative label: Application Event
alternative label: Business Event
alternative label: State Change
change note: 4.0: Merges BusinessEvent, ApplicationEvent, TechnologyEvent, and ImplementationEvent into a single generic element.
definition: An event represents something that happens or occurs inside or outside the enterprise, such as a state change.
scope note: Processes and other behavior may be triggered or interrupted by an event. Processes may raise events that trigger other processes or functions. Unlike processes or functions, an event is instantaneous: it does not have a duration. Events may originate from the environment of the organization (e.g., from a customer) or some external physical or IT system, as well as internal events generated within the organization or system world. An event may trigger or be triggered (raised) by a process or function. An event may access passive elements and may aggregate other events. The name of an event should preferably be a verb in the perfect tense; e.g., “Claim Received”. This event concept is similar to a BPMN event, and to the initial state and final state elements in UML activity diagrams. However, the ArchiMate event is more generally applicable in the sense that it can also be used to model other types of events, in addition to triggers of processes. “Claims Administration” is a function that aggregates a number of processes. This function realizes a “Claims Processing” service. An event “Claim Filed” triggers the first process “Accept Claim Risk”, which in turn triggers a process “Assign Claim”. Depending on the type of claim, either the process “Adjudicate Standard Claim” or the process “Adjudicate High-Risk Claim” is performed. According to the company policy, two roles should always be involved in the latter process, to minimize the risk of fraud. This is modeled with the collaboration “High-Risk Claims Adjudication”. After adjudication, the processes “Notify Customer” and “Pay Claim” are performed in parallel, and when both have finished, process “Close Claim” is triggered.
was quoted from: sec-Event

EventElement
type: Class
subclass of: BehaviorElement
definition: Event elements — state changes that trigger or are triggered by other behaviour.
is abstract class: true

ExternalActiveStructureElement
type: Class
subclass of: ActiveStructureElement
source: sec-Active-Structure-Elements
definition: An internal active structure element represents an entity that is capable of performing behavior.
scope note: Interfaces expose services to the environment and hide internal complexity. Typically composed by the internal active structure element they belong to. Assigned to the services they expose.
was quoted from: sec-Active-Structure-Elements
is abstract class: true

ExternalBehaviorElement
type: Class
subclass of: BehaviorElement
definition: External behaviour elements (services) — explicitly defined exposed behaviour.
scope note: Services offered to consumers. Realized by internal behaviour and exposed through interfaces.
is abstract class: true

Facility
type: Class
subclass of: InternalActiveStructureElement
subclass of: TechnologyDomainElement
source: sec-Facility
alternative label: Building
alternative label: Data Center
alternative label: Site
definition: A facility represents a physical structure or environment.
scope note: A facility represents a physical resource that has the capability of facilitating (e.g., housing or locating) the use of equipment. It is typically used to model factories, buildings, or outdoor constructions that have an important role in production or distribution processes, and also IT-related facilities. Examples of facilities include a factory, laboratory, warehouse, shopping mall, cave, data center, or spaceship. Facilities can be interconnected by distribution networks. A facility may be composed of technology interfaces in order to serve other internal active structure elements such as business roles and actors. A facility can aggregate other facilities or nodes and can be aggregated in a location. The name of a facility should preferably be a noun referring to the type of facility; e.g., “Rotterdam oil refinery”.
was quoted from: sec-Facility

Flow
type: Class
subclass of: QualifiedRelationship
source: sec-Flow-Relationship
definition: The flow relationship represents transfer from one element to another.
scope note: The flow relationship is used to model the flow of, for example, information, goods, or money between behavior elements. A flow relationship does not imply a causal relationship. In order to determine the order in which the claims should be assessed, “Claim Assessment” makes use of schedule information received from the “Scheduling” function.
was quoted from: sec-Flow-Relationship
unqualified form: Flows To

Function
type: Class
subclass of: CommonDomainElement
subclass of: InternalBehaviorElement
source: sec-Function
alternative label: Application Function
alternative label: Business Function
change note: 4.0: Merges BusinessFunction, ApplicationFunction, and TechnologyFunction into a single generic element. Also replaces Interaction (BusinessInteraction, ApplicationInteraction, TechnologyInteraction).
definition: A function represents a collection of behavior based on a chosen set of criteria.
scope note: Just like a process, a function also describes internal behavior performed by a role. However, while a process groups behavior based on a sequence or flow of activities that is needed to realize a product or service, a function typically groups behavior based on required resources, skills, competencies, knowledge, etc. There is a potential many-to-many relation between processes and functions. Complex processes in general involve activities that require various functions. In this sense, a process can form a string of functions. Organizational units or applications may coincide with functions due to their specific grouping of activities. In the Business Domain, functions are often closely aligned to an organization, but not necessarily explicitly governed by the organization. Functions can realize capabilities. Where functions are often aligned with organization structure and describe the current, day-to-day activities of the enterprise, capabilities (see :Capability) represent its potential behavior and are independent from the implementation in the organization structure. A function may be triggered by, or trigger, any other behavior element (event, process, or function). A function may access passive elements. A function may realize one or more services and may be served by other services. A role may be assigned to a function. The name of a function should clearly indicate a well-defined behavior, but unlike processes, it is typically not in the form of a verb-noun phrase. Examples are customer management, claims administration, recycling, or payment processing.
was quoted from: sec-Function

Goal
type: Class
subclass of: MotivationElement
source: sec-Goal
definition: A goal represents a high-level statement of intent, direction, or desired end state for an organization and its stakeholders.
scope note: In principle, a goal can represent any objective a stakeholder may desire, such as a state of affairs, or a produced value. Examples of goals include: to increase profit, to reduce waiting times at the helpdesk, or to introduce online portfolio management. Goals are typically used to measure success of an organization. Goals are generally expressed using qualitative words; e.g., “increase”, “improve”, or “easier”. Goals can also be decomposed; e.g., “increase profit” can be decomposed into the goals “reduce cost” and “increase sales”. However, it is also very common to associate concrete outcomes with goals, which can be used to describe both the quantitative and time-related results that are essential to describe the desired state, and when it should be achieved.
was quoted from: sec-Goal

Grouping
type: Class
subclass of: CompositeElement
source: sec-Grouping
definition: A grouping represents a collection of concepts that belong together based on some common characteristic.
scope note: The grouping element is used to aggregate an arbitrary group of concepts, which can be elements and/or relationships of the same or of different types. An aggregation relationship is used to link the grouping element to the grouped concepts. Grouping elements can also have other relationships to and from them, as shown in Appendix B, Relationships (Normative). Concepts may be aggregated by multiple (overlapping) groups. One useful way of employing grouping is for modeling ABBs and SBBs, as described in the TOGAF Standard [C220]. Another useful application of grouping is for modeling domains. For example, the TOGAF Standard [C220] Glossary of Supplementary Definition defines Information Domain as: “grouping of information (or data entities) by a set of criteria such as security classification, ownership, location, etc. In the context of security, Information Domains are defined as a set of users, their information objects, and a security policy”.
was quoted from: sec-Grouping

ImplementationAndMigrationDomainElement
type: Class
subclass of: Element
source: sec-Implementation-and-Migration-Elements-Metamodel
definition: Implementation and Migration Domain elements support planning and execution of architecture changes.
scope note: Domain marker for transition planning: work packages, deliverables, and plateaus. Gap and ImplementationEvent from 3.x have been removed in 4.0.
was quoted from: sec-Implementation-and-Migration-Elements-Metamodel
is abstract class: true

Influence
type: Class
subclass of: QualifiedRelationship
source: sec-Influence-Relationship
definition: An influence relationship represents that an element affects the implementation or achievement of some motivation element.
scope note: The influence relationship is used to describe that some architectural element influences the achievement of a motivation element, such as a goal or principle. In general, a motivation element is realized to a certain degree. An influence relationship can be used to indicate that an element has a positive or negative influence on the realization of a motivation element.
was quoted from: sec-Influence-Relationship
unqualified form: Influences

InternalActiveStructureElement
type: Class
subclass of: ActiveStructureElement
source: sec-Active-Structure-Elements
definition: An internal active structure element represents an entity capable of performing behavior.
scope note: The performers — actors, roles, collaborations, components, nodes, devices, system software, equipment, facilities. Connected to behavior via assignment. In 4.0, Role and Collaboration are generic Common Domain elements.
was quoted from: sec-Active-Structure-Elements
is abstract class: true

InternalBehaviorElement
type: Class
subclass of: BehaviorElement
definition: Internal behaviour elements — units of activity performed by active structure elements.
scope note: Processes and functions. Realized by internal active structure via assignment. Realizes external behaviour (services).
is abstract class: true

Location
type: Class
subclass of: CompositeElement
source: sec-Location
definition: A location represents a place or position where structure elements can be located or behavior can be performed.
scope note: The location element is used to model the place where (active and passive) structure elements such as business actors, application components, and devices are located. This covers both physical (e.g., geographical) locations and logical places such as the regions of cloud providers. This is modeled by means of an aggregation relationship from a location to structure element. A location can also aggregate a behavior element, to indicate where the behavior is performed. This element corresponds to the “Where” column of the Zachman® framework [Sowa & Jackman, 1992].
was quoted from: sec-Location

Material
type: Class
subclass of: PassiveStructureElement
subclass of: TechnologyDomainElement
source: sec-Material
definition: Material represents tangible physical matter or energy.
scope note: Material is typically used to model raw materials and physical products, and also energy sources such as fuel and electricity. Material can be accessed by behavior elements to model how it is created, used, moved, transformed, or otherwise manipulated. Equipment may be assigned to material, to model where the material is stored. This allows a distinction to be modeled between, for instance, “the sand is in the dump truck” and “the sand is poured into the concrete mixer”. Material may realize equipment. The name of material should be a noun. Pieces of material may aggregate other pieces of material.
was quoted from: sec-Material

Meaning
type: Class
subclass of: MotivationElement
source: sec-Meaning
definition: Meaning represents the knowledge or expertise present in, or the interpretation given to, a concept in a particular context.
scope note: A meaning represents the interpretation of a concept of the architecture. In particular, this is used to describe the meaning of passive structure elements (for example, a document, a message). It is a description that expresses the intent of that element; i.e., how it informs the external user. It is possible that different users view the informative functionality of an element differently. For example, what may be a “registration confirmation” for a client could be a “client mutation” for a CRM department (assuming for the sake of argument that it is modeled as an external user). Also, various different representations may carry essentially the same meaning. For example, various different documents (a web document, a filled-in paper form, a “client contact” report from the call center) may essentially carry the same meaning. A meaning can be associated with any concept. To denote that a meaning is specific to a particular stakeholder, this stakeholder can also be associated to the meaning. The name of a meaning should preferably be a noun or noun phrase.
was quoted from: sec-Meaning

MotivationElement
type: Class
subclass of: Element
source: sec-Motivation-Elements-Metamodel
definition: A motivation element represents the context of or reason behind the architecture.
scope note: The 'why' behind the architecture: stakeholders, drivers, assessments, goals, outcomes, principles, requirements, meanings, and values. Connected to other elements via influence relationships.
was quoted from: sec-Motivation-Elements-Metamodel
is abstract class: true

Node
type: Class
subclass of: InternalActiveStructureElement
subclass of: TechnologyDomainElement
source: sec-Node
alternative label: Compute Node
alternative label: Host
alternative label: Server
definition: A node represents a generic IT or physical structure that hosts, manipulates, or interacts with other such structures.
scope note: Nodes are active structure elements that perform behavior and execute, store, and process artifacts or materials. For instance, nodes are used to model application platforms, defined by the TOGAF Standard [C220] as: “a collection of technology components of hardware and software that provide the services used to support applications”. Nodes can be interconnected by paths, communication networks or distribution networks, and may be assigned to an artifact to model that the artifact is deployed on the node. The name of a node should preferably be a noun. A node may consist of sub-nodes.
was quoted from: sec-Node

Or Junction
type: Class
subclass of: Element
definition: Used to connect relationships of the same type.

Outcome
type: Class
subclass of: MotivationElement
source: sec-Outcome
definition: An outcome represents an end result, effect, or consequence of a certain state of affairs.
scope note: Outcomes are high-level, business-oriented results produced by the capabilities of an organization and, by inference, by the core elements of its architecture that realize these capabilities. Outcomes are tangible, possibly quantitative, and time-related, and can be associated with assessments. An outcome may have a different value for different stakeholders. The notion of outcome is important in business outcome-driven approaches to Enterprise Architecture and in capability-based planning. Outcomes are closely related to requirements, goals, and other intentions. The distinction between goals and outcomes is important. Simply put, a goal is what you want, and an outcome is what you get. Outcomes are the end results, and goals or requirements are often related to outcomes that should be realized. Capabilities can be designed to achieve such outcomes. However, not all outcomes relate to the successful achievement of goals. When modeling a future state, an outcome models some result or effect that is expected to have been achieved or occur at that future point in time. Unlike goals, outcomes can also be used to model potentially unwanted effects; for example, in order to design appropriate mitigating measures. Outcome names should unambiguously identify end results that have been achieved or are expected to be achieved at a definite point in the future. Examples include “First-place customer satisfaction ranking achieved” and “Key supplier partnerships in place”. Outcome names can also be more specific; e.g., “10% year-over-year quarterly profits increase in 2018”.
was quoted from: sec-Outcome

PassiveStructureElement
type: Class
subclass of: StructureElement
source: sec-Passive-Structure-Elements
definition: A passive structure element represents an element on which behavior is performed.
scope note: Objects acted upon by behavior — business objects, data objects, artifacts, materials, deliverables, and resources. Connected to behavior via access relationships (read, write, read-write).
was quoted from: sec-Passive-Structure-Elements
is abstract class: true

Path
type: Class
subclass of: ActiveStructureElement
subclass of: CommonDomainElement
source: sec-Path
alternative label: Connection
alternative label: Link
change note: 4.0: Moved from Technology Layer to Common Domain. Aggregation from Path to technology internal active structure element replaced by realization from active structure element to Path.
definition: A path represents a logical link between business actors, application components, nodes, devices, system software, equipment, facilities, roles, and/or collaborations, through which these elements can exchange information, data, energy, or material.
scope note: A path is used to model the logical communication or distribution relations between internal active structure elements. It may be realized by one or more communication networks or distribution networks (which represent the physical communication or distribution links), and by any other active structure elements (to model the people and technology on which the path relies). A path can be associated with the internal active structure elements it connects. Typical examples of paths are a Virtual Private Network (VPN), realized by WiFi, Local Area Network (LAN), and Wide Area Network (WAN) communication networks; intermodal freight, realized by a combination of shipping, trucking, and rail distribution networks; or a social network that lets users communicate with each other.
was quoted from: sec-Path

Plateau
type: Class
subclass of: CompositeElement
subclass of: ImplementationAndMigrationDomainElement
source: sec-Plateau
alternative label: Architecture State
alternative label: Baseline
alternative label: Target State
definition: A plateau represents a relatively stable state of the architecture that exists during a limited period of time.
scope note: An important premise in the TOGAF framework is that the various architectures are described for different stages in time. In each of the Phases B, C, and D of the Architecture Development Method (ADM), Baseline and Target Architecture Descriptions are created, describing the current situation and the desired future situation. In Phase E (Opportunities and Solutions), so-called Transition Architectures are defined, showing the enterprise at incremental states reflecting periods of transition between the Baseline and Target Architectures. Transition Architectures are used to allow for individual work packages and projects to be grouped into managed portfolios and programs, illustrating the business value at each stage and expressing the step-by-step approach to migration. In order to support this, the plateau element is defined.
was quoted from: sec-Plateau

Principle
type: Class
subclass of: MotivationElement
source: sec-Principle
definition: A principle represents a statement of intent defining a general property that applies to any system in a certain context in the architecture.
scope note: The term “system” is used in its general meaning; i.e., as a group of (functionally) related elements, where each element may be considered as a system again. Therefore, a system may refer to any active structure element, behavior element, or passive structure element of some organization, such as a business actor, application component, process, service, business object, or data object. Principles are strongly related to goals and requirements. Similar to requirements, principles define intended properties of systems. However, in contrast to requirements, principles are broader in scope and more abstract than requirements. A principle defines a general property that applies to any system in a certain context, whereas a requirement defines a property that applies to a specific system as described by an architecture. For example, the principle “Information management processes comply with all relevant laws, policies, and regulations” is realized by the requirements that are imposed by the actual laws, policies, and regulations that apply to the specific system under design.
was quoted from: sec-Principle

Process
type: Class
subclass of: CommonDomainElement
subclass of: InternalBehaviorElement
source: sec-Process
alternative label: Application Process
alternative label: Business Process
alternative label: Workflow
change note: 4.0: Merges BusinessProcess, ApplicationProcess, and TechnologyProcess into a single generic element.
definition: A process represents a sequence of behaviors that achieves a specific result.
scope note: A process describes the internal behavior performed by a role that is required to produce a set of services. A complex process may be an aggregation of other, finer-grained processes. To each of these, finer-grained roles may be assigned. There is a potential many-to-many relationship between processes and functions. Informally speaking, processes describe some kind of “flow” of activities, whereas functions group activities according to required skills, knowledge, resources, etc. A process may be triggered by, or trigger, any other behavior element (i.e., event, process, or function). A process may access passive elements. A process may realize one or more services and may be served by other services. A role may be assigned to a process to model the responsibility for performing this process. The name of a process should clearly indicate a predefined sequence of actions using a verb or verb-noun combination and may include the word “process”. Examples are “adjudicate claim”, “employee on-boarding”, “approval process”, “general ledger update job”, or “replicate database”. In an ArchiMate model, the existence of processes is depicted: High-level business, end-to-end processes, macro flows, workflows, and automated processes can all be expressed with the same process element in the ArchiMate language. It does not, however, list the flow of activities in detail. This is typically done during detailed process modeling in a process design language such as BPMN [BPMN].
was quoted from: sec-Process

Product
type: Class
subclass of: BusinessDomainElement
subclass of: CompositeElement
source: sec-Product
definition: A product represents a coherent collection of services, business objects, data objects, artifacts, and/or material, which is offered as a whole to (internal or external) customers.
scope note: This definition covers both intangible, services-based, or information products that are common in information-intensive organizations, as well as tangible, physical products. A financial or information product typically consists of a collection of services along with a business object representing a contract that specifies the characteristics, rights, and obligations associated with the product. “Buying” a product gives the customer the right to use the associated services. Generally, the product element is used to specify a product type. The number of product types in an organization is typically relatively stable compared to the processes that realize or support the products. “Buying” is usually one of the services associated with a product which results in a new instance of that product (belonging to a specific customer). Similarly, there may be services to modify or destroy a product. A product may aggregate services, business objects, data objects, artifacts, and material. Hence a product may aggregate elements from domains other than the Business Domain. A value may be associated with a product. The name of a product is usually the name used in the communication with customers, or possibly a more generic noun (e.g., “Travel Insurance”).
was quoted from: sec-Product

Realization
type: Class
subclass of: QualifiedRelationship
source: sec-Realization-Relationship
change note: 4.0: Cross-layer realization between services of different domains replaced by specialization (from realizing service to realized service) or aggregation (from realized service to realizing service).
definition: A realization relationship represents that an element plays a critical role in the creation, achievement, sustenance, or operation of a more abstract element.
scope note: A realization relationship indicates that more abstract elements (“what” or “logical”) are realized by means of more tangible elements (“how” or “physical”). The realization relationship is used to model run-time realization; for example, that a process realizes a service, and that a data object realizes a business object, an artifact realizes an application component, or a core element realizes a motivation element. The interpretation of a realization relationship is that the whole or part of the source element realizes the whole of the target element (see also Section 5.1, “Structural Relationships”). For example, this means that if two internal behavior elements have a realization relationship to the same service, either of them can realize the complete service. If both internal behavior elements are needed to realize, the grouping element or an And-junction (see :Junction) can be used. For weaker types of effects on the realization of a motivation element, the influence relationship (see Section 5.2.3, “Influence Relationship”) should be used. For realization, nesting as a notation is allowed in both directions of the relationship. For instance, a service can be nested in an application component to express that it is realized by that application component, and a process nested in a capability may express that this process realizes the capability. Since this can lead to ambiguity, it is advisable to use it only in one direction in the same view and add an explanation to any view in which such ambiguity may arise. A “Transaction Processing” function realizes a “Billing Service”; the “Invoice” business object is realized by the data object “Billing Data”.
was quoted from: sec-Realization-Relationship
unqualified form: Realizes

Requirement
type: Class
subclass of: MotivationElement
source: sec-Requirement
definition: A requirement represents a statement of need defining a property that applies to a specific system as described by the architecture.
scope note: In the end, a business goal must be realized by a plan or concrete change goal, which may or may not require a new system or changes to an existing system. Requirements model the properties of these elements that are needed to achieve the “ends” that are modeled by the goals. In this respect, requirements represent the “means” to realize goals. During the design process, goals may be decomposed until the resulting sub-goals are sufficiently detailed to enable their realization by properties that can be exhibited by systems. At this point, goals can be realized by requirements that demand these properties from the systems. For example, two alternative requirements may be identified to realize the goal “Improve portfolio management”: By assigning a personal assistant to each customer By introducing online portfolio management The former requirement can be realized by a human actor and the latter by a software application. These requirements can be decomposed further to define the requirements on the human actor and the software application in more detail.
was quoted from: sec-Requirement

Resource
type: Class
subclass of: StrategyElement
subclass of: StructureElement
source: sec-Resource
definition: A resource represents a useful or valuable possession or means that can be drawn upon by the enterprise.
scope note: Resources are a central concept in the field of strategic management, economics, computer science, portfolio management, and more. They are often recognized along with capabilities, to be sources of competitive advantage for organizations. Resources are analyzed in terms of strengths and weaknesses, and considered when implementing strategies. Due to resources being limited, they can often be a deciding factor for choosing which strategy, goal, and project to implement and in which order. Resources can be classified in different ways, including tangible assets, intangible assets, and human assets. Examples of tangible assets include financial assets (cash, securities, borrowing capacity, etc.) and physical assets (plant, equipment, land, mineral reserves, etc.). Examples of intangible assets include technology assets (patents, copyrights, trade secrets, etc.), reputation assets (brand, relationships, etc.), and culture assets. Examples of human assets include skills/know-how, capacity for communication and collaboration, and motivation. Resources are realized by active and passive structure elements and are therefore classified as structures that are neither active nor passive. The name of a resource should preferably be a noun.
was quoted from: sec-Resource

Role
type: Class
subclass of: CommonDomainElement
subclass of: InternalActiveStructureElement
source: sec-Role
alternative label: Application Role
alternative label: Business Role
change note: 4.0: Replaces BusinessRole. Now a generic Common Domain element to which any internal active structure element can be assigned.
definition: A role represents the position or purpose that a business actor, application component, node, device, system software, equipment, facility, or a collaboration has in performing specific behavior.
scope note: Roles with certain responsibilities or skills are assigned to processes or functions. An internal active structure element that is assigned to a role is responsible for ensuring that the corresponding behavior is carried out, either by performing it or by delegating and managing its performance. In addition to the relation of a role with behavior, a role is also useful in a (structural) organizational sense; for instance, in the division of labor within an organization. A role may aggregate interfaces that it provides to its environment, and interfaces may serve a role. The name of a role should preferably be a noun. For example, a business actor can be assigned to a “Requester” or “Approver” role, or an application component can be assigned to a “Policy Enforcement Point” or “Policy Decision Point” role.
was quoted from: sec-Role

Service
type: Class
subclass of: CommonDomainElement
subclass of: ExternalBehaviorElement
source: sec-Service
alternative label: Application Service
alternative label: Business Service
alternative label: Infrastructure Service
alternative label: Technology Service
change note: 4.0: Merges BusinessService, ApplicationService, and TechnologyService into a single generic element. Cross-layer realization between services replaced by specialization or aggregation.
definition: A service represents an explicitly defined behavior that a business actor, application component, node, device, system software, equipment, facility, role, or collaboration provides to its environment.
scope note: Thus, a service exposes specific functionality of the providing active structure element (for example, an organization unit or IT system) from the perspective of others that use that service; the environment consists of everything outside this providing organization unit or system. The value offered to the user of the service provides the motivation for the existence of the service. For the users, only this exposed behavior and value, together with non-functional aspects such as the quality of service, costs, etc., are relevant. Services are accessible through interfaces. A service may serve other behavior or active structure elements. A process or function may realize a service. An interface may be assigned to a service. A service may access passive elements. The name of a service should clearly describe the functionality being offered (for example, using a verb ending with “-ing”); e.g., “claims processing”, "transaction processing”, or “messaging”. Also, a name explicitly containing the word “service” may be used; e.g., “data replication service”.
was quoted from: sec-Service

Serving
type: Class
subclass of: QualifiedRelationship
source: sec-Serving-Relationship
definition: A serving relationship represents that an element provides its functionality to another element.
scope note: A serving relationship describes how the services or interfaces offered by a behavior or active structure element serve entities in their environment. This relationship is applied to both the behavior aspect and the active structure aspect. The “Payment Interface” serves the “Customer”, while the “Payment Service” serves the “Pay Invoices” process of that customer.
was quoted from: sec-Serving-Relationship
unqualified form: Serves

Specialization
type: Class
subclass of: QualifiedRelationship
source: sec-Specialization-Relationship
definition: The specialization relationship represents that an element is a particular kind of another element.
scope note: The specialization relationship has been inspired by the generalization relationship in UML class diagrams but is applicable to specialize a wider range of concepts. A specialization relationship is always allowed between two elements of the same type. Alternatively, a specialization relationship can be expressed by nesting the specialized element inside the generic element. In this case, the “Take Out Travel Insurance” and “Take Out Luggage Insurance” processes are a specialization of a more generic “Take Out Insurance” process.
was quoted from: sec-Specialization-Relationship
unqualified form: Specializes

Stakeholder
type: Class
subclass of: MotivationElement
source: sec-Stakeholder
definition: A stakeholder represents the perspective from which a business actor perceives the effects of the architecture.
scope note: A stakeholder has one or more interests in, or concerns about, the organization and its Enterprise Architecture. In order to direct efforts to these interests and concerns, stakeholders change, set, and emphasize goals. Stakeholders may also influence each other. Examples of stakeholders are the Chief Executive Officer (CEO), the board of directors, shareholders, customers, business and application architects, but also legislative authorities. The name of a stakeholder should preferably be a noun.
was quoted from: sec-Stakeholder

StrategyElement
type: Class
subclass of: Element
source: sec-Strategy-Elements-Metamodel
definition: Strategy elements represent strategic concepts used to model the enterprise at a high level.
scope note: High-level planning elements: capabilities (what the organization can do), value streams (how value is delivered), courses of action (plans), and resources (assets). Realized by elements from other domains.
was quoted from: sec-Strategy-Elements-Metamodel
is abstract class: true

StructureElement
type: Class
subclass of: Element
definition: A structural element — an entity that exists. Divides into active structure (performers of behaviour) and passive structure (objects acted upon).
is abstract class: true

System Software
type: Class
subclass of: InternalActiveStructureElement
subclass of: TechnologyDomainElement
source: sec-System-Software
alternative label: Middleware
alternative label: Operating System
alternative label: Platform Software
definition: System software represents software that provides or contributes to an environment for storing, executing, and using software or data deployed within it.
scope note: System software is used to model the software environment in which artifacts run. This can be an operating system, a Java®, Enterprise Edition (JEE) application server, a database system, or a workflow engine. System software can also be used to represent communication middleware. Usually, system software is combined with a device representing the hardware environment to form a general node. A device or system software can be assigned to other system software; e.g., to model different layers of software running on top of each other. System software can be assigned to artifacts to model that these artifacts are deployed on that software and can realize other system software. A node can aggregate system software. The name of system software should preferably be a noun referring to the type of execution environment; e.g., “JEE server”. System software may aggregate other system software; e.g., an operating system containing a database.
was quoted from: sec-System-Software

TechnologyDomainElement
type: Class
subclass of: Element
source: sec-technology-Active-Structure-Elements
definition: Technology Domain elements represent concepts specific to the technology and physical domain.
scope note: Domain marker for technology and physical elements: nodes, devices, system software, networks, equipment, facilities, artifacts, and materials. Merges the 3.x Technology and Physical layers.
was quoted from: sec-technology-Active-Structure-Elements
is abstract class: true

Technology Interface
type: Class
subclass of: ExternalActiveStructureElement
subclass of: TechnologyDomainElement
source: sec-Technology-Interface
definition: A technology interface represents a point of access where a node, device, system software, facility, or equipment makes services available to its environment.
scope note: A technology interface specifies how the services of a technology internal active structure element can be accessed by other elements. A technology interface exposes a service to the environment. The same service may be exposed through different interfaces. In a sense, a technology interface specifies a kind of contract that a node realizing this interface must fulfill. This may include, parameters, protocols used, pre- and post-conditions, and data formats. A technology interface may be part of a technology internal active structure through aggregation, which means that these interfaces are provided by that element and can serve other elements. A technology interface can be assigned to a service, to expose that service to the environment. The name of a technology interface should preferably be a noun.
was quoted from: sec-Technology-Interface

Triggering
type: Class
subclass of: QualifiedRelationship
source: sec-Triggering-Relationship
definition: The triggering relationship represents a temporal or causal relationship between elements.
scope note: The triggering relationship is used to model the temporal or causal precedence of behavior elements in a process. The interpretation of a triggering relationship is that some part of the source element should be completed before the target element can start (see also Section 5.3.3, “Semantics of Dynamic Relationships”). Note that this does not necessarily mean that one behavior element actively starts another; in a hypothetical daily process, the “Have Lunch” activity follows (is triggered by) the “Have Breakfast” activity, even though there is no active signal between the two.
was quoted from: sec-Triggering-Relationship
unqualified form: Triggers

Value
type: Class
subclass of: MotivationElement
source: sec-Value
definition: Value represents the relative worth, utility, or importance of a concept.
scope note: Value represents the usefulness, advantage, benefit, desirability, or gain for a customer, stakeholder, or end user by, for example, selling a product, using a service, or completing some activity. Value is often expressed in terms of money, but it has long since been recognized that non-monetary value is also essential to business; for example, practical/functional value (including the right to use a service), and the value of information or knowledge. Though value can hold internally for some system or organizational unit, it is most typically applied to the external appreciation of goods, services, information, knowledge, or money, normally as part of some sort of customer-provider relationship. Value may also be negative. For instance, the introduction of an Artificial Intelligence (AI) chatbot on a company website may have a positive value (efficiency) for that company but a negative value (frustration) for customers. A value can be associated with any concept. To model the stakeholder for whom this value applies, this stakeholder can also be associated with that value. Although the name of a value can be expressed in many different ways (including amounts, objects), where the “functional” value of an architecture element is concerned, it is recommended to try and express it as an action or state that can be performed or reached as a result of the corresponding element being available.
was quoted from: sec-Value

Value Stream
type: Class
subclass of: BehaviorElement
subclass of: StrategyElement
source: sec-Value-Stream
definition: A value stream represents a sequence of activities that create an overall result for a customer, stakeholder, or end user.
scope note: A value stream describes how an enterprise organizes its activities to create value. As described in the TOGAF® Series Guide: Value Streams, a key principle of value streams is that value is always defined from the perspective of the stakeholder — the customer, end user, or recipient of the product, service, or deliverable produced by the work. The value obtained is in the eye of the beholder; it depends more on the stakeholder’s perception of the worth of the product, service, outcome, or deliverable than on its intrinsic value; i.e., the cost to produce. This is modeled in the ArchiMate language by using the value element and, in turn, is associated on the one hand with the result being produced and, on the other hand, may be associated with the stakeholder. Value streams may be defined at different levels of the organization; e.g., at the enterprise level, business unit level, or department level. Value streams can be an aggregation of value-adding activities. These are also modeled with the value stream element and known as value (stream) stages, each of which creates and adds incremental value from one stage to the next. These stages are typically related using flow relationships to model the flow of value between them. Resources can be assigned to value streams and capabilities can serve (i.e., enable) a value stream. Importantly, value streams and processes may seem alike, but they are defined at different abstraction levels and serve separate purposes. A process describes the (time-ordered) sequence of behaviors required to create some result for an individual case, and it may describe alternative paths and decision points (modeled with junctions). In contrast, a value stream focuses on the overall value-creating behavior from the perspective of the importance, worth, or usefulness of what is produced, and is not a description of time-ordered tasks for individual cases. Value streams (and capabilities) reflect an organization’s business model and value propo…
was quoted from: sec-Value-Stream

Work Package
type: Class
subclass of: BehaviorElement
subclass of: ImplementationAndMigrationDomainElement
source: sec-Work-Package
alternative label: Initiative
alternative label: Project
definition: A work package represents a series of actions identified and designed to achieve specific results within specified time and resource constraints.
scope note: The central behavioral element is a work package. A work package is typically not a continuously ongoing activity, but has a start and an end. It produces a well-defined set of results, typically modeled as goals, outcomes, or deliverables. The work package element can be used to model sub-projects or tasks within a project, complete projects, programs, or project portfolios. In an Agile context, a work package can be used to model the work performed in an Agile iteration (e.g., sprint) or higher level increment. Conceptually, a work package is similar to a process, in that it consists of a set of causally-related tasks, aimed at producing a well-defined result. However, a work package is a unique “one-off” process. Still, a work package can be described in a way very similar to the description of a process.
was quoted from: sec-Work-Package