ArchiMate (Enterprise Architecture Modeling Language)

1. Overview

A. Definition

ArchiMate is an open standard maintained by The Open Group — a visual modeling notation for expressing, analyzing, and communicating the business, application, and technology domains of enterprise architecture (EA), together with the relationships among them, in a single, consistent visual language. Its aim is to render an organization's strategy, business, systems, and infrastructure in one common vocabulary (elements and relationships) so that different stakeholders read the same meaning from the same picture.

To understand ArchiMate correctly, one must first be clear that it is "a language, not a methodology." If TOGAF's ADM is a methodology that prescribes "by what process architecture is built," ArchiMate is a notation that prescribes "with what symbols its deliverables are drawn." In other words, if TOGAF is the design process, ArchiMate is the drawing convention that holds the result; since both standards fall under The Open Group, they were designed to be mutually complementary.

There are three core characteristics. First, it decomposes the enterprise along two axes — layer and aspect — so that any architecture element is classified by "which layer it belongs to × whether it is active structure, behavior, or passive structure." Second, it embeds service orientation into the language itself, consistently connecting all layers through a relationship in which an upper layer consumes the 'services' of a lower layer. Third, the viewpoint mechanism supports selective visualization that extracts only a given stakeholder's concerns from the same model.

Unlike domain-specific languages such as UML and BPMN, ArchiMate's distinctive value lies in "stitching the enterprise onto a single sheet across layers (cross-layer)." UML draws the inside of software, and BPMN draws business processes precisely, but neither can show, as one connected model, "by which application component this business service is realized, and on which servers and networks that component runs." ArchiMate takes exactly this 'cross-layer traceability' as its core capability.

B. Background and Necessity

ArchiMate originated from a research project led by the Netherlands' Telematica Instituut in 2002–2004, was transferred to The Open Group in 2008, and has since evolved through 2.0 (2012), 3.0 (2016), 3.1 (2019), and 3.2 (2022). The fundamental reason this standard was needed lies in the fact that EA practice had long been fragmented into "a different drawing language for each layer."

The first driver is the communication breakdown caused by notational fragmentation. In the past, EA deliverables were drawn separately — business as flowcharts, applications in UML, data in ERDs, and infrastructure in network diagrams. Each picture was precise but disconnected from the others, so they could not answer the enterprise-level question "if this business changes, which systems and servers are affected?" ArchiMate sought to bridge this disconnect by binding all layers into one notational system.

The second driver is the visualization of business–IT alignment. Executives speak of strategy, capabilities, and value streams; engineers speak of servers and middleware. If the intermediate bridge of 'application services and business services' between them is not made explicit, the two sides imagine different worlds. ArchiMate's service layering structurally forces "strategy → business → application → technology" to connect vertically through service-consumption relationships, thereby revealing alignment.

The third driver is securing impact analysis and a basis for decision-making. As digital transformation exploded the interdependence of systems, tracing by hand the ripple effects of replacing a particular application or of a regulatory change became virtually impossible. An ArchiMate model, in which relationships among elements are defined as formal rules, can be queried through tools for "the upstream and downstream elements connected to this node," becoming evidence for impact analysis and investment decisions.

The fourth driver is interoperability as an international standard. If each organization draws its architecture in an in-house dialect, exchanging deliverables across firms and departments and achieving tool compatibility becomes difficult. ArchiMate provides an open standard and an exchange format (the ArchiMate Model Exchange File Format), enabling models to move and integrate without lock-in to a particular vendor tool. In practice, public-sector and financial-institution EA projects at home and abroad increasingly adopt TOGAF ADM and ArchiMate together, standardizing process and notation at once.

2. Core Structure of ArchiMate — Layers and Aspects

ArchiMate's skeleton is a two-dimensional framework of "layer × aspect." The vertical axis, the layer, denotes the height of abstraction (strategy, business, application, technology); the horizontal axis, the aspect, denotes the nature of an element (what acts, what happens, what is handled). Thanks to this orthogonal decomposition, any architecture element is classified into a single cell, suppressing duplication and omission.

graph TD
    AM["ArchiMate framework (layer x aspect)"]
    AM --> L["Vertical axis: layer (height of abstraction)"]
    AM --> A["Horizontal axis: aspect (nature of element)"]
    L --> L0["Strategy: resource, capability, value stream"]
    L --> L1["Business: business actor, service, process"]
    L --> L2["Application: component, application service, data"]
    L --> L3["Technology: node, system SW, infrastructure service"]
    L --> L4["Physical: facility, equipment, material"]
    L --> L5["Implementation & Migration: work package, plateau"]
    A --> A1["Active structure: the acting subject"]
    A --> A2["Behavior: the activity or service performed"]
    A --> A3["Passive structure: the object being handled"]
    A --> A4["Motivation: stakeholder, goal, requirement, principle"]

A. Layer — Vertical Decomposition from Strategy to Technology

The core layers of ArchiMate 3.x are the three layers of business, application, and technology, to which are added the upper Strategy layer and the Motivation and Implementation & Migration extensions that cut across all layers. The business layer deals with the value the organization delivers to customers and with business services, processes, and roles; the application layer deals with the software components and application services that support that business; and the technology layer deals with the hardware, system software, and communications infrastructure that drives the applications.

The fundamental reason for separating layers is "to avoid mixing concerns of different abstraction levels." For instance, the business service 'insurance claim processing' (business), the 'claims management system' that realizes it (application), and the 'container orchestration cluster' on which that system runs (technology) differ entirely in their rate of change and responsible owner. Separating layers allows change in one layer to be managed independently of the others, and the layers are only loosely coupled to one another through 'service' interfaces. This is the practical implication of the service orientation that ArchiMate declares.

The Strategy layer, added in 3.0, helps EA move beyond being a mere system map and connect directly with management strategy. With elements such as Resource, Capability, and Course of Action / Value Stream, it draws "what capabilities we will secure and along which path we will deliver value," and links how those capabilities are realized by lower-layer business, application, and technology. For example, if a telecom carrier places 'hyper-personalized marketing capability' as a strategy element, the flow by which it is realized by the business function 'CDP build,' the application component 'customer data platform,' and the technology node 'GPU analytics cluster' can be captured on a single sheet.

B. Aspect — Active Structure, Behavior, Passive Structure

The horizontal axis, the aspect, can be likened to parts of speech in grammar. Active structure corresponds to the 'subject' of action (business role, application component, technology node); behavior corresponds to the 'verb' (business process, application function, service); and passive structure corresponds to the 'object' (business object, data object, artifact). Added to these is the Motivation aspect that runs through all layers, dealing with stakeholders, drivers, goals, requirements, constraints, and principles.

This grammatical decomposition is useful because it repeats the same narrative structure of "who (active) handles what (passive) how (behavior)" across all layers. The structure 'a claims assessor (active) assesses a claim form (passive) (behavior)' in the business layer corresponds directly to 'the claims-assessment component (active) validates the claim data (passive) (behavior)' in the application layer, so mapping and tracing across layers occur naturally. The Motivation aspect makes "why this structure exists" explicit as a separate dimension, connecting how regulations, goals, and principles are realized by particular business and application elements.

Where the aspect distinction is especially valuable in practice is in regulatory and compliance traceability. For instance, if external constraints such as the Personal Information Protection Act or financial-sector electronic-finance supervisory regulations are modeled as 'driver' and 'requirement' in the Motivation aspect, one can trace by relationships how that requirement is realized by which business process (behavior), application component (active structure), and data object (passive structure). Because the systems affected when a regulation is amended can be identified by model query, the aspect axis becomes substantive evidence for governance and audit response beyond mere classification.

3. Elements and Relationships — Service Orientation and Layer Connection

An ArchiMate model is, in the end, a graph that links elements by relationships. If elements are the vocabulary, relationships are the grammar, and the fact that the kinds of relationships and their permitted rules are rigorously defined is what decisively distinguishes it from free-form 'boxes and arrows' drawings.

graph TB
    subgraph BIZ["Business layer"]
        BS["Business service: insurance claim processing"]
        BP["Business process: intake-assess-pay"]
        BR["Business role: claims assessor"]
    end
    subgraph APP["Application layer"]
        AS["Application service: claim assessment API"]
        AC["Application component: claims management system"]
        DO["Data object: claim data"]
    end
    subgraph TECH["Technology layer"]
        TS["Technology service: container runtime"]
        NODE["Node: K8s cluster"]
    end
    BR -->|"assignment: performs"| BP
    BP -->|"realization: realizes"| BS
    AS -->|"serving: supports"| BP
    AC -->|"realization: realizes"| AS
    AC -->|"access: read/write"| DO
    TS -->|"serving: drives"| AC
    NODE -->|"realization: provides"| TS

A. Types of Relationships — Structural, Dependency, Dynamic, Other

ArchiMate's relationships fall into four groups by nature. Structural relationships express the static composition of elements and include composition, aggregation, assignment, and realization. Dependency relationships express how elements rely on one another and include serving, access, influence, and association. Dynamic relationships express the flow of time — triggering and flow — and others include specialization and junction.

That relationships are formally defined carries great implications in practice. For example, 'realization' is defined to mean only "a more concrete element implements a more abstract one," so consistent vertical tracing is possible — a business process realizing a business service, an application component realizing an application service. Conversely, 'serving' means the horizontal or vertical dependency in which one element provides function to another, becoming the main conduit for cross-layer connection in which an application service 'supports' a business process. Only when the meaning of relationships is fixed in this way can a tool query and validate the model.

B. The Logic of Service Orientation and Layer Connection

The most important of ArchiMate's design ideas is the principle that "each layer is coupled only through the services that the layer below exposes." No matter how complex the internal components of the application layer are, the business layer consumes only the 'application services' it exposes, and the technology layer likewise upholds applications only through 'technology services.' This service boundary lowers coupling across layers, so that even if the inside of one layer is replaced, the upper layer is unaffected as long as the exposed services remain identical.

This principle fits the era of microservices and the API economy especially well. For instance, when a bank re-builds a legacy mainframe lending system into something cloud-native, if only the contract (interface) of the exposed 'loan assessment service' is maintained, the business processes and channel applications that consume that service remain unchanged. An ArchiMate model explicitly reveals this 'service boundary that must be preserved,' visually demarcating the scope of modernization and the scope of impact.

4. Viewpoint — Selective Visualization by Stakeholder

An enterprise-wide model reaches hundreds to thousands of elements, so showing it as is renders it unreadable to anyone. ArchiMate resolves this with the viewpoint mechanism. A viewpoint is "a lens that prescribes the kinds of elements and relationships to show from the whole model, tailored to a particular stakeholder's particular concern," and the picture actually drawn through that lens is a view. This aligns with the 'stakeholder–concern–viewpoint–view' concepts of ISO/IEC/IEEE 42010, the international standard for architecture description.

For example, executives are given a 'capability-map view' containing only strategy and capabilities and the core business services that realize them; application architects a 'application cooperation view' containing only application components and their collaboration; and infrastructure staff an 'infrastructure view' centered on nodes, networks, and system software. Because they are extracted through different lenses from the same single model, the fact that the executives' capability elements and the infrastructure's servers are traceably connected within one model is fundamentally different from hand-drawn PowerPoint pictures.

The standard provides basic (standard) viewpoints as examples, but an organization can define custom viewpoints tailored to its concerns. The important practical principle is "however many views, there is one model." Even as views multiply, the single repository of underlying elements and relationships must be kept as one so that consistency and impact-analysis capability are preserved. If separate elements are duplicated for each view, ArchiMate's core value collapses.

5. Comparison — Relationship with Adjacent Notations and Frameworks

ArchiMate's position becomes clear through comparison with adjacent languages and frameworks. The key is the division of roles: "ArchiMate is an enterprise-level notation that cuts across layers; UML, BPMN, and ERD are dedicated notations that precisely draw the inside of a particular layer; and TOGAF and Zachman are not notations but process and classification schemes."

Category	Nature	Primary scope	Relationship with ArchiMate
ArchiMate	Modeling language (notation)	All layers: strategy, business, application, technology	This topic — specialized in cross-layer connection
TOGAF ADM	Methodology (process)	The whole EA development lifecycle	Complementary (process↔notation), same stewardship
Zachman	Classification schema (ontology)	Coordinate system for deliverable classification	Complementary — 'what' to classify vs 'how' to draw
UML	Modeling language	Software internal design	Application-layer detail complemented by UML
BPMN	Modeling language	Business process detail	Business process detail complemented by BPMN

The fundamental reason the differences arise in this comparison is that "the height of the problem being solved" differs. UML and BPMN pursue precision inside a single layer, so their expressive power is deep but enterprise-wide overview is hard; ArchiMate pursues an overview of all layers, so its depiction inside a layer is relatively shallow. The practical implication is clear: the two are not rivals but a division of roles, and a layered documentation is recommended in which, after drawing the enterprise terrain with ArchiMate, one 'zooms in' on the inside of a particular application with UML class and sequence diagrams and on the detailed flow of a particular business with BPMN. Likewise, because ArchiMate (notation), TOGAF (process), and Zachman (classification) answer different questions ("how to draw, by what process to build, what to classify"), synergy arises when they are used together.

6. Advanced — Latest Trends and Practical Application

ArchiMate's latest version is 3.2, released in 2022. 3.2 improved the ability to handle value-stream and capability elements more precisely in the Strategy layer and clarified notations such as directed association, thereby complementing expressive power. The earlier 3.0 (2016), which introduced strategy and physical elements, was the largest structural expansion, while 3.1 (2019) and 3.2 (2022) are more in the nature of refinements. Version details are most accurately confirmed against The Open Group specification, and because detailed notation rules may be revised, it is safer to treat them on the premise of "checking the current specification" rather than asserting them.

The tool ecosystem has also matured. A range of tools, including the open-source Archi and commercial EA tools, support ArchiMate, and the standard exchange format (Model Exchange File Format) enables models to move between tools. Recently, amid a trend toward managing architecture models like code (Architecture-as-Code), the practice of describing ArchiMate models in a text-based DSL and linking them to version control (Git) and CI to track change history is spreading in the field. This dovetails with the intent to operate architecture deliverables not as 'static reporting documents' but as a 'living repository.'

From a practical-application standpoint, ArchiMate is especially useful as an impact-analysis tool in digital-transformation, cloud-migration, and legacy-modernization projects. For instance, when a public agency migrates some 30 on-premises systems to the cloud, tracing in the ArchiMate model the business services each application component realizes and the technology services it consumes lets one identify "independent systems that can be moved first" and "tightly coupled bundles that must be moved together." Moreover, with the plateau and work-package elements of the Implementation & Migration layer, one can model the transition stages from the current (As-Is) to the target (To-Be), connecting the roadmap and the architecture as one. That said, not every organization needs to model all layers precisely; since excessive modeling only inflates cost, right-sizing the scope to the purpose (impact analysis, communication, roadmap) is realistic.

7. Considerations and Implications (Professional Engineer's Perspective)

Application strategy — purpose-driven right-sized modeling: ArchiMate should start not from the completeness of "drawing the enterprise exhaustively" but from the purpose of "which decision it will support." Defining a purpose first — impact analysis, modernization-scope identification, business-IT alignment — and modeling only the layers and viewpoints needed for it is key to avoiding over-investment.
Trade-off — enterprise overview vs within-layer precision: The price of gaining a cross-layer overview is that depiction inside each layer becomes shallow. Rather than trying to be self-contained with ArchiMate alone, a layered documentation strategy that complements detail with dedicated notations such as UML, BPMN, and ERD is desirable.
Linked technologies — combination with methodology, classification, and governance: As a notation, ArchiMate takes effect only when combined with TOGAF ADM (process), Zachman (classification), EA governance (principles and review), and configuration management / a model repository (single source of truth). In particular, a single model repository must be maintained so that consistency and impact-analysis capability are preserved even as views multiply.
Outlook — expansion toward Architecture-as-Code and knowledge graphs: A trend is observed of treating models as text/code to link them with CI/configuration management, and of connecting the element-relationship graph with organizational knowledge graphs and data catalogs. This points toward operating architecture as a living asset, but since it is an unstandardized attempt, it is appropriate to understand it at the level of direction.
Risk — guarding against formalization into reporting pictures: If an ArchiMate model becomes a dead document detached from reality, its value disappears. Alignment with the operating reality must be verified periodically, and a governance loop must be secured that uses architecture in actual decisions (investment, modernization, regulatory response).
Organizational capability — notational proficiency and stakeholder participation: If the meaning of relationships is not accurately observed, the model degenerates into 'pretty box pictures.' Only when the architects' notational proficiency, stakeholder agreement on viewpoints, and an organizational culture that reads the model and uses it in decisions are in place does ArchiMate finally work.

References

The Open Group, "ArchiMate 3.2 Specification" — https://pubs.opengroup.org/architecture/archimate3-doc/
The Open Group, ArchiMate Overview — https://www.opengroup.org/archimate-forum/archimate-overview
Archi (open-source ArchiMate modeling tool) — https://www.archimatetool.com/

In one line: ArchiMate is The Open Group's open standard — an EA modeling language that draws all layers (strategy, business, application, technology) consistently with 'layer × aspect' and formally defined elements and relationships, enabling cross-layer tracing and impact analysis, and shows its true worth when combined with process (TOGAF), classification (Zachman), and dedicated notations (UML, BPMN).