Use when modeling enterprise architecture with ArchiMate, the Open Group standard visual notation (v3.2). Covers Business, Application, and Technology layers, element types, relationship types, viewpoints, and modeling best practices.
USE FOR: enterprise architecture modeling, layered architecture visualization, Business-Application-Technology mapping, ArchiMate element and relationship notation, architecture viewpoint selection, motivation modeling, cross-layer dependency analysis
DO NOT USE FOR: architecture development process (use togaf), system decomposition (use c4-diagrams), general-purpose diagrams (use mermaidjs or d2)
Use when modeling enterprise architecture with ArchiMate, the Open Group standard visual notation (v3.2). Covers Business, Application, and Technology layers, element types, relationship types, viewpoints, and modeling best practices.
USE FOR: enterprise architecture modeling, layered architecture visualization, Business-Application-Technology mapping, ArchiMate element and relationship notation, architecture viewpoint selection, motivation modeling, cross-layer dependency analysis
DO NOT USE FOR: architecture development process (use togaf), system decomposition (use c4-diagrams), general-purpose diagrams (use mermaidjs or d2)
[{"title":"ArchiMate Specification — The Open Group","url":"https://pubs.opengroup.org/architecture/archimate3-doc/"},{"title":"ArchiMate — The Open Group Overview","url":"https://www.opengroup.org/archimate-forum/archimate-overview"}]
ArchiMate - Enterprise Architecture Modeling Language
Overview
ArchiMate is an open and independent enterprise architecture modeling language maintained by The Open Group. It provides a uniform representation for describing, analyzing, and communicating enterprise architectures. ArchiMate is designed to be used alongside TOGAF — where TOGAF defines the process (ADM), ArchiMate provides the visual notation.
ArchiMate 3.2 organizes elements across layers (Business, Application, Technology) and aspects (Active Structure, Behavior, Passive Structure), with a Motivation extension and Strategy layer.
Layer and Aspect Framework
ArchiMate's core framework is a grid of layers and aspects:
Active Structure Behavior Passive Structure
(Who/What) (How) (On What)
┌──────────────────┬──────────────────┬──────────────────┐
Business │ Business Actor │ Business Process │ Business Object │
│ Business Role │ Business Function │ Contract │
│ Business │ Business Service │ Representation │
│ Collaboration │ Business Event │ Product │
│ Business │ Business │ │
│ Interface │ Interaction │ │
├──────────────────┼──────────────────┼──────────────────┤
Application│ Application │ Application │ Data Object │
│ Component │ Function │ │
│ Application │ Application │ │
│ Collaboration │ Service │ │
│ Application │ Application │ │
│ Interface │ Interaction │ │
│ │ Application Event │ │
├──────────────────┼──────────────────┼──────────────────┤
Technology │ Node │ Technology │ Artifact │
│ Device │ Function │ │
│ System Software │ Technology │ │
│ Technology │ Service │ │
│ Collaboration │ Technology │ │
│ Technology │ Process │ │
│ Interface │ Technology Event │ │
│ Path │ Technology │ │
│ Communication │ Interaction │ │
│ Network │ │ │
└──────────────────┴──────────────────┴──────────────────┘
Business Layer Elements
The Business Layer describes the products and services offered externally and the processes, roles, and functions that realize them internally.
Active Structure Elements
Element
Notation
Description
Business Actor
Yellow rectangle with person icon
An organizational entity capable of performing behavior (e.g., a person, department, company)
Business Role
Yellow rectangle with role icon
A named responsibility for performing specific behavior
Business Collaboration
Yellow rectangle with double-head icon
An aggregate of two or more roles working together
Business Interface
Yellow rectangle with socket icon
A point of access where a business service is made available
Behavior Elements
Element
Notation
Description
Business Process
Yellow rounded rectangle with arrow
A sequence of business behaviors that achieves a specific outcome
Business Function
Yellow rounded rectangle
A collection of behavior based on a chosen set of criteria (typically required business resources or skills)
Business Service
Yellow rounded rectangle with horizontal line
An externally visible unit of functionality
Business Event
Yellow rounded rectangle with lightning bolt
Something that happens and may trigger or be triggered by behavior
Business Interaction
Yellow rounded rectangle with double arrow
A unit of behavior performed by a collaboration
Passive Structure Elements
Element
Notation
Description
Business Object
Yellow rectangle with folded corner
A concept relevant from a business perspective
Contract
Yellow rectangle with signature icon
A formal or informal agreement
Representation
Yellow document shape
A perceptible form of the information carried by a business object
Product
Yellow rectangle with box icon
A coherent collection of services and contract, offered as a whole to customers
Application Layer Elements
The Application Layer describes application components, their services, and the data they manage.
Active Structure Elements
Element
Notation
Description
Application Component
Blue rectangle with component icon
A modular, deployable, and replaceable part of a software system
Application Collaboration
Blue rectangle with double-head icon
An aggregate of application components working together
Application Interface
Blue rectangle with socket icon
A point of access where an application service is made available
Behavior Elements
Element
Notation
Description
Application Function
Blue rounded rectangle
Automated behavior performed by an application component
Application Service
Blue rounded rectangle with horizontal line
An externally visible unit of application functionality
Application Interaction
Blue rounded rectangle with double arrow
A unit of behavior performed by an application collaboration
Application Process
Blue rounded rectangle with arrow
A sequence of application behaviors
Application Event
Blue rounded rectangle with lightning bolt
An application-level event
Passive Structure Elements
Element
Notation
Description
Data Object
Blue rectangle with folded corner
Data structured for automated processing
Technology Layer Elements
The Technology Layer describes the infrastructure (hardware, networks, system software) that supports the Application Layer.
Active Structure Elements
Element
Notation
Description
Node
Green 3D box
A computational or physical resource that hosts artifacts
Device
Green 3D box with device icon
A physical hardware resource
System Software
Green 3D box with software icon
A software environment for specific types of components and objects (e.g., OS, JVM, DBMS)
Technology Collaboration
Green rectangle with double-head icon
An aggregate of nodes working together
Technology Interface
Green rectangle with socket icon
A point of access to technology services
Path
Green line
A link between two or more nodes through which they exchange data
Communication Network
Green line with network icon
A set of structures connecting nodes for transmission, routing, and reception
Behavior Elements
Element
Notation
Description
Technology Function
Green rounded rectangle
A collection of technology behavior
Technology Service
Green rounded rectangle with horizontal line
An externally visible unit of technology functionality
Technology Process
Green rounded rectangle with arrow
A sequence of technology behaviors
Technology Interaction
Green rounded rectangle with double arrow
Technology behavior performed by a collaboration
Technology Event
Green rounded rectangle with lightning bolt
A technology-level event
Passive Structure Elements
Element
Notation
Description
Artifact
Green rectangle with folded corner and binary icon
A piece of data used or produced by technology, typically a file or deployable unit
Motivation Elements
Motivation elements model the reasons behind architecture decisions, capturing stakeholder concerns, goals, and requirements.
Element
Description
Stakeholder
An individual, team, or organization with interests in the architecture
Driver
An external or internal condition that motivates an organization to define its goals
Assessment
The result of analysis of a driver
Goal
A desired end state
Outcome
An end result that is achieved or intended
Principle
A qualitative statement of intent that should be met by the architecture
Requirement
A statement of need that must be met by the architecture
Constraint
A restriction on the design or implementation
Meaning
The knowledge or expertise present in a business object or representation
Value
The relative worth, utility, or importance of a concept
Strategy Elements
Element
Description
Resource
An asset owned or controlled by an individual or organization
Capability
An ability that an active structure element possesses
Course of Action
An approach or plan for achieving a goal
Value Stream
A sequence of activities that creates an overall result for a customer, stakeholder, or end user
Relationships
ArchiMate defines a precise set of relationships between elements. Relationships are categorized into structural, dependency, dynamic, and other.
Structural Relationships
Relationship
Notation
Description
Example
Composition
Filled diamond ◆───►
Element is composed of one or more other elements
Application Component ◆───► Data Object
Aggregation
Open diamond ◇───►
Element groups other elements
Business Role ◇───► Business Actor
Assignment
Filled circle ●───►
Allocation of responsibility, execution, or storage
Business Role ●───► Business Process
Realization
Dashed line with open triangle ╌╌╌▷
Element plays a critical role in the creation of a more abstract element
Application Service ╌╌╌▷ Business Service
Dependency Relationships
Relationship
Notation
Description
Example
Serving
Open arrowhead ───►
Element provides functionality to another
Application Service ───► Business Process
Access
Dashed line with arrowhead ╌╌╌►
Process reads/writes data
Business Process ╌╌╌► Business Object
Influence
Dashed line with open arrowhead ╌╌╌► (with + or -)
Element affects implementation or achievement of a motivation element
Driver ╌╌╌►(+) Goal
Dynamic Relationships
Relationship
Notation
Description
Example
Triggering
Filled arrowhead ──▶
Element causes another to begin
Business Event ──▶ Business Process
Flow
Filled arrowhead with label ──▶ (label)
Transfer of content between elements
Business Process ──▶"order data"──▶ Business Process
Other Relationships
Relationship
Notation
Description
Example
Specialization
Open triangle ───▷
Element is a particular kind of another element
Online Order ───▷ Order
Association
Plain line ───
Unspecified relationship
Element ─── Element
Junction
Filled circle (AND) or open circle (OR)
Combine relationships
Process1 ──▶ ● ──▶ Process2, Process3
Viewpoints
ArchiMate viewpoints define a selection of elements, relationships, and their presentation. Use the right viewpoint for the right audience.
Organization Viewpoint
Purpose: Show the structure of the organization in terms of business actors, roles, and their relationships.
Typical Elements: Business Actor, Business Role, Business Collaboration, Business Interface, Location
Purpose: Show the structure of applications, their components, data objects, and interfaces.
Typical Elements: Application Component, Application Interface, Data Object, Application Collaboration
Technology Viewpoint
Purpose: Show the technology infrastructure: nodes, devices, networks, and system software.
Typical Elements: Node, Device, System Software, Communication Network, Path, Technology Interface, Artifact
Layered Viewpoint
Purpose: Provide a cross-layer overview showing how business services are supported by application services, which in turn are supported by technology services.
Application Layer, Data Objects, Application Structure Viewpoint
Phase D: Technology Architecture
Technology Layer, Technology Viewpoint
Phase E-F: Opportunities & Migration
Layered Viewpoint with gap annotations
Phase G-H: Governance & Change
Implementation and Migration Viewpoint
Best Practices
Use the correct layer. Do not model application concerns in the Business Layer or vice versa. Cross-layer connections should use serving or realization relationships.
Keep viewpoints focused. Each diagram should use a single viewpoint. A Layered Viewpoint can show cross-layer dependencies, but avoid cramming all elements into one diagram.
Use relationships precisely. ArchiMate relationships have specific semantics. Do not use "serving" when you mean "realization" — they convey different architectural meaning.
Color-code by layer. Follow the standard color convention: yellow for Business, blue for Application, green for Technology. This provides instant visual orientation.
Start with the Layered Viewpoint. When introducing an architecture to stakeholders, the Layered Viewpoint provides the best overview of how business is supported by applications and technology.
Model motivation first. Before modeling structure, capture stakeholder goals, drivers, and requirements. This ensures architecture decisions are traceable to business rationale.
Pair with TOGAF. ArchiMate provides the notation; TOGAF provides the process. Use ArchiMate diagrams as deliverables within TOGAF ADM phases.
Limit elements per diagram to 15-20. Overcrowded diagrams lose communicative value. Split into multiple viewpoints if needed.
Name elements with precision. Use clear, specific names (e.g., "Order Management Service" not "Service 1"). Element names should be self-explanatory.
Version your models. Like code, ArchiMate models should be version-controlled. Use tool exports (e.g., Archi Open Exchange format) stored alongside source code.
