Enterprise architecture is only as useful as its ability to communicate complex realities clearly. You can have the most thorough understanding of your IT landscape in the world, but if you cannot convey dependencies, relationships, and trade-offs to stakeholders in a consistent and readable way, that understanding stays locked inside a handful of experts' heads.
This is the problem ArchiMate was designed to solve. Maintained by The Open Group alongside TOGAF, ArchiMate is a standardized modeling language that provides a uniform way to describe, analyze, and visualize enterprise architectures. This guide covers what you need to know to start using ArchiMate effectively.
What is ArchiMate?
ArchiMate is an open and independent modeling language for enterprise architecture. First released in 2004 and now at version 3.1, it provides a set of standard elements, relationships, and viewpoints that architects use to create consistent architecture descriptions.
Unlike general-purpose modeling languages such as UML, ArchiMate is purpose-built for enterprise architecture. It covers the full scope of an organization's architecture — from business strategy and processes through application services and data to technology infrastructure — in a single, coherent language.
The key principles behind ArchiMate are:
- Layered structure: Architecture is organized into distinct but connected layers
- Service orientation: Layers interact through well-defined services
- Standard notation: Every element and relationship has a defined visual symbol
- Viewpoint-based: Different stakeholders see different views of the same underlying model
The Three Core Layers
ArchiMate organizes architecture elements into three core layers, each representing a different level of abstraction. This layered approach is fundamental to how ArchiMate works and is one of its greatest strengths.
Business Layer
The Business Layer describes the products, services, and processes that the organization delivers to its external customers and the internal structures that support them. Core elements include:
- Business Actor: A person or organizational unit that performs behavior (e.g., "Customer Service Department")
- Business Role: A named responsibility assigned to an actor (e.g., "Account Manager")
- Business Process: A sequence of activities that produces a defined outcome (e.g., "Order Fulfillment Process")
- Business Service: An externally visible unit of functionality (e.g., "Customer Onboarding Service")
- Business Object: A concept relevant from a business perspective (e.g., "Customer Order")
- Business Event: Something that happens and may trigger or be triggered by processes (e.g., "Order Received")
The Business Layer answers the question: what does the organization do, and how is it organized?
Application Layer
The Application Layer describes the software applications and data that support the business. Core elements include:
- Application Component: A modular, deployable, and replaceable part of a software system (e.g., "CRM System," "Payment Gateway")
- Application Service: An externally visible unit of functionality provided by a component (e.g., "Customer Data Lookup Service")
- Application Interface: A point of access where an application service is made available (e.g., "REST API," "Web Portal")
- Data Object: Data structured for automated processing (e.g., "Customer Record," "Invoice")
- Application Function: Internal behavior of a component that implements a service
- Application Event: An application-level event that triggers or is triggered by application behavior
The Application Layer answers the question: what software and data support the business?
Technology Layer
The Technology Layer describes the infrastructure needed to run applications. Core elements include:
- Node: A computational or physical resource (e.g., "Application Server," "Database Server")
- Device: A physical IT resource (e.g., "Firewall Appliance," "Storage Array")
- System Software: Software that provides a platform for running other software (e.g., "Linux OS," "Kubernetes")
- Technology Service: An externally visible unit of infrastructure functionality (e.g., "Hosting Service," "Messaging Service")
- Artifact: A piece of data used or produced by technology (e.g., "Docker Image," "Configuration File")
- Communication Network: A link between nodes (e.g., "Corporate LAN," "VPN Tunnel")
The Technology Layer answers the question: what infrastructure runs the software?
Relationships
ArchiMate defines a set of standard relationships that connect elements within and across layers. The most important are:
- Composition: An element consists of other elements (whole-part relationship)
- Aggregation: An element groups other elements (weaker than composition)
- Assignment: An active element is assigned to perform behavior (e.g., an Application Component is assigned to an Application Function)
- Realization: A concrete element realizes an abstract element (e.g., an Application Component realizes an Application Service)
- Serving: An element provides its functionality to another element (the fundamental cross-layer connection)
- Flow: Transfer of content (data, materials, information) between elements
- Triggering: One element triggers another (temporal or causal relationship)
- Access: A behavioral element accesses a data/business object (read, write, or both)
- Association: A general, unspecified relationship between elements
The Serving relationship is particularly important because it is the primary mechanism by which layers connect. Technology serves applications, applications serve business — this service chain is the backbone of ArchiMate models.
Viewpoints and Views
A single ArchiMate model can contain hundreds or thousands of elements. No single diagram can show everything without becoming an unreadable mess. ArchiMate addresses this through viewpoints and views.
A viewpoint defines a perspective on the architecture — what types of elements and relationships to include, and what purpose the view serves. A view is a specific diagram created according to a viewpoint.
ArchiMate 3.1 defines several standard viewpoints, including:
- Organization Viewpoint: Shows the structure of the organization and its roles
- Business Process Viewpoint: Shows business processes and their relationships to services and roles
- Application Usage Viewpoint: Shows how applications support business processes
- Application Cooperation Viewpoint: Shows application-to-application relationships and data flows
- Technology Usage Viewpoint: Shows how technology supports applications
- Layered Viewpoint: Shows the full stack from business through technology in a single diagram
- Migration Viewpoint: Shows transition architectures over time
Choosing the right viewpoint for your audience is critical. A CTO wants the Technology Usage viewpoint. A business process owner wants the Business Process viewpoint. A solution architect working on integration wants the Application Cooperation viewpoint. The underlying model is the same — the views simply filter and present what is relevant.
ArchiMate vs. UML
A common question is how ArchiMate differs from UML (Unified Modeling Language). The distinction is straightforward:
- UML is designed for detailed software design — class diagrams, sequence diagrams, state machines. It excels at modeling the internals of individual systems.
- ArchiMate is designed for enterprise-level architecture — the relationships between systems, the connection between business and technology, the big picture. It deliberately avoids the detail level of UML.
They are complementary, not competing. Use ArchiMate to model the enterprise landscape and how systems relate to each other and to business. Use UML (or C4, or other software modeling approaches) to model the internal design of individual systems.
Tool Support for ArchiMate
ArchiMate's standardized notation makes it well-suited for tool support. Several categories of tools work with ArchiMate:
- Dedicated ArchiMate tools: Tools like Archi (open source) that are built specifically around the ArchiMate metamodel
- Enterprise architecture platforms: Comprehensive EA tools that support ArchiMate alongside other modeling approaches
- Modern EA platforms: Tools like Albumi that take a data-driven approach to architecture, allowing teams to model architecture elements and relationships and generate visualizations automatically from the underlying data
The advantage of a data-driven approach is that diagrams stay current as the architecture model is updated. Instead of manually maintaining static ArchiMate diagrams that drift out of sync with reality, architects maintain the architecture data and let the tool generate accurate views on demand.
Getting Started with ArchiMate
If you are new to ArchiMate, here is a practical path forward:
- Learn the core elements first: Focus on Business Process, Application Component, Technology Node, and the Serving relationship. These cover 80% of typical modeling needs.
- Start with one viewpoint: The Application Cooperation viewpoint is often the most immediately useful for organizations trying to understand their integration landscape.
- Model what you know: Begin with a small, well-understood part of your architecture to build confidence with the notation.
- Iterate: Your first models will be imperfect. Refine as your understanding of both ArchiMate and your architecture deepens.
- Use tooling: Manual diagram drawing does not scale. Invest in an EA tool that supports ArchiMate to maintain models efficiently.
ArchiMate provides a powerful, standardized way to communicate enterprise architecture. When combined with frameworks like TOGAF and modern EA platforms, it enables organizations to move from ad-hoc architecture communication to consistent, stakeholder-appropriate views of their architecture landscape.