ArchiMate 3 Practitioner key terms

A set of models and other documents that together express how an enterprise or system is organized and how it works, produced so that stakeholders can reason about it.

A purposeful abstraction of some part of an enterprise, created with a specific set of concepts and rules so that questions about that part can be answered.

The specification of the concepts, their attributes, and the relationships allowed between them, which defines what a valid model in the language may contain.

One of the horizontal partitions of the language (Strategy, Business, Application, Technology, and the implementation and migration layers) that groups concepts of the same kind of concern.

A vertical partition that classifies concepts by the kind of architecture concern they express: active structure, behavior, passive structure, or motivation.

A concept representing something that can perform behavior, such as an actor, role, component, node, or interface. Often drawn as a box in the structural part of a layer.

A concept representing something an active structure element does, such as a process, function, interaction, service, or event, including its internal activity and its externally visible offering.

A concept representing information or physical material that is used or produced by behavior, such as a business object, data object, artifact, or material. It does not act.

A unit of functionality that an active structure element exposes to its environment, described by the behavior it offers and explicitly governed by a contract or expectation.

An active structure element in the business layer that represents an organizational entity capable of performing behavior, such as a department, a company, or a named person.

An active structure element in the business layer that represents a responsibility for behavior, which one or more actors can fulfill. It lets you model what must be done apart from who does it.

A behavior element in the business layer that represents a sequence of activities producing a defined result, typically modeled to show ordering, roles, and the objects it uses or creates.

A passive structure element in the business layer that represents a piece of information meaningful to the business, such as a customer record, order, or contract.

An active structure element in the application layer representing a modular, deployable piece of software that encapsulates its behavior and data and exposes interfaces.

An active structure element in the application layer that represents the point where an application component's services can be accessed by other components, users, or systems.

An active structure element in the technology layer that represents a computational or physical resource, such as a server, device, or runtime environment, on which other elements are deployed.

A passive structure element in the technology layer representing a physical piece of data or a deployable file, such as a configuration file, database, or executable, that is deployed on a node.

A concept that explains why an architecture looks as it does, covering stakeholders, drivers, assessments, goals, outcomes, principles, requirements, and constraints.

A motivation element representing an external or internal condition that motivates an organization to change, and which is typically analyzed through assessments into goals and requirements.

A motivation element stating a property or capability that a system or architecture must satisfy, often derived from goals and realized by core elements in the model.

A typed connection between two or more concepts, such as composition, aggregation, assignment, realization, serving, access, influence, or specialization, each with defined meaning and allowed endpoints.

A relationship expressing that an active structure element performs behavior or is responsible for a passive element, linking who or what acts to what is done.

A relationship expressing that a more concrete element achieves or carries out a more abstract one, for example a process realizing a service or an application realizing a business function.

A relationship expressing that one element provides its functionality to another, for example a service serving a process or an interface serving a component.

A relationship expressing that a behavior element reads, writes, or reads and writes a passive structure element, capturing how processes and functions use information or material.

Whole-part relationships: composition means the part cannot exist without the whole and belongs to exactly one whole, while aggregation means the part can exist independently and may belong to several wholes.

A relationship expressing that one element is a more specific kind of another, inheriting its properties and allowed connections, used to build type hierarchies in a model.

A relationship that is not drawn explicitly but is implied by other relationships in the model, such as a serving relation inferred from realization and assignment chains.

A connection between elements in different layers, such as an application service serving a business process, used to show how higher-level behavior depends on lower-level support.

The coherence between layers or domains, for example ensuring business processes, applications, and infrastructure support the same goals without gaps or unnecessary duplication.

A selection of concepts and relationships from the language, with conventions for their use, chosen to address the concerns of one or more stakeholders. Often drawn as a diagram.

The actual model or diagram produced when a viewpoint is applied to a specific architecture, showing the subset of elements relevant to that perspective.

A person, team, or organization with an interest in the architecture, whose concerns should drive which viewpoints and level of detail are used in the description.

An interest or matter of importance to a stakeholder that the architecture description should address, such as cost, performance, compliance, or time to market.

A comparison of baseline and target architectures that identifies elements present in one but not the other, used to plan the work needed to move from current to future state.

The description of the architecture as it exists at a defined point before a change, used as the starting point for impact analysis and for deriving a target state.

The description of the intended future architecture after planned changes, derived from goals and requirements and used to direct transformation work.

A relatively stable state of the architecture during a transition, used to break a large transformation into a sequence of intermediate target states.

An implementation and migration element representing a unit of change that delivers a defined result within a set period, often grouped with others into a project or program.

An implementation and migration element representing a tangible or intangible output of a work package, such as a document, a deployed system, or a trained team.