visualization
ArchiMate: Enterprise Architecture Modeling
An introduction to ArchiMate, the open standard for enterprise architecture modeling and visualization.
ArchiMate: Enterprise Architecture Modeling
TL;DR
ArchiMate is an open standard for enterprise architecture modeling that provides a uniform representation for describing, analyzing, and visualizing architecture across business, application, and technology domains. Use ArchiMate for formal EA documentation, stakeholder communication, and impact analysis across the enterprise.
Key Takeaways
- Three layers: Business, Application, and Technology—each with distinct element types
- Relationships matter: 11 core relationships define how elements connect
- Viewpoints: Predefined perspectives for different stakeholder concerns
- Complements TOGAF: ArchiMate provides the notation; TOGAF provides the framework
- Tool support: Supported by Archi (free), Sparx EA, BiZZdesign, and others
Why This Matters
Enterprise architecture without a common language leads to confusion. Business stakeholders see one thing, developers another, and infrastructure teams something else entirely. ArchiMate provides a standardized visual language that bridges these perspectives, enabling clear communication about how business capabilities map to applications and technology. It's particularly valuable for impact analysis ("if we change this system, what's affected?") and transformation planning.
ArchiMate vs UML
ArchiMate is for enterprise-level architecture; UML is for software design. ArchiMate shows how business, applications, and technology relate. UML details how software components work internally. They're complementary, not competing.
Core Concepts
The Three Layers
Layer Colors (Standard)
| Layer | Color | Focus |
|---|---|---|
| Strategy | Beige/Tan | Direction and motivation |
| Business | Yellow | Organization and processes |
| Application | Blue | Software and data |
| Technology | Green | Infrastructure |
| Physical | Green (darker) | Physical elements |
| Implementation | Pink/Salmon | Projects and work packages |
Element Types
Active Structure (Who/What Performs)
| Element | Symbol | Description |
|---|---|---|
| Business Actor | ○ (stick figure) | Human or organizational unit |
| Business Role | ○ (with hat) | Responsibility assigned to actor |
| Business Collaboration | ○○ | Two or more roles working together |
| Business Interface | ⊐ | Point of access for business services |
Behavior (What is Done)
| Element | Symbol | Description |
|---|---|---|
| Business Process | ▷ (rounded arrow) | Sequence of activities producing value |
| Business Function | □ (rounded) | Collection of behavior based on skills |
| Business Interaction | ▷▷ | Collaboration behavior |
| Business Event | ⌁ | State change that triggers behavior |
| Business Service | □ with line | Externally visible behavior |
Passive Structure (What is Acted Upon)
| Element | Symbol | Description |
|---|---|---|
| Business Object | □ | Concept with business relevance |
| Contract | □ with folded corner | Formal agreement |
| Representation | □ (document) | Perceptible form of business object |
| Product | □ with bar | Coherent collection of services |
Example
BUSINESS LAYER EXAMPLE
┌───────────────┐ ┌───────────────────┐
│ Customer │ │ Sales Rep │
│ (Actor) │ │ (Role) │
└───────┬───────┘ └─────────┬─────────┘
│ │
│ requests │ performs
│ │
▼ ▼
┌───────────────┐ ┌───────────────────┐
│ Order Service │◀─────│ Order Process │
│ (Service) │ │ (Process) │
└───────────────┘ └─────────┬─────────┘
│
│ accesses
▼
┌───────────────────┐
│ Order │
│ (Business Object) │
└───────────────────┘
Relationships
Core Relationships
ARCHIMATE RELATIONSHIPS
STRUCTURAL
├── Composition ◆───── Part of (strong)
├── Aggregation ◇───── Part of (weak)
├── Assignment ○─────▶ Allocation of responsibility
├── Realization ─ ─ ─▶ Implementation of
DEPENDENCY
├── Serving ─────▶ Provides functionality to
├── Access - - -▶ Read/write to data
├── Influence · · ·▶ Affects (positive/negative)
DYNAMIC
├── Triggering ─────▶ Temporal/causal
├── Flow ─────▶ Transfer of content
OTHER
├── Specialization ────△ Is a type of
├── Association ───── Unspecified relationship
Relationship Rules
| From Layer | To Layer | Typical Relationship |
|---|---|---|
| Business | Application | Served by (app serves business) |
| Application | Technology | Realized by (tech realizes app) |
| Business | Business | Various (assignment, flow, etc.) |
| Application | Application | Various (serving, flow, etc.) |
Viewpoints
Viewpoint Purpose
Viewpoints define which elements and relationships to include for a specific stakeholder concern.
Key Viewpoints
| Viewpoint | Purpose | Typical Audience |
|---|---|---|
| Organization | Show structure of organization | Management |
| Business Process | Show process flows | Process owners |
| Application Behavior | Show app functionality | Solution architects |
| Application Structure | Show app components | Developers |
| Technology | Show infrastructure | Infrastructure team |
| Layered | Show all layers | Enterprise architects |
| Migration | Show transformation | Program managers |
Layered Viewpoint Example
LAYERED VIEWPOINT (Cross-Layer View)
┌─────────────────────────────────────────────────────────────┐
│ BUSINESS │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Customer │────────▶│Order Process │ │
│ └──────────────┘ └───────┬──────┘ │
├────────────────────────────────────┼────────────────────────┤
│ APPLICATION │ │
│ ┌────────▼───────┐ │
│ ┌──────────────┐ │ Order Service │ │
│ │ Order App │────────│ │ │
│ └──────┬───────┘ └────────┬───────┘ │
├──────────┼─────────────────────────┼────────────────────────┤
│ TECHNOLOGY │ │
│ │ ┌────────▼───────┐ │
│ ┌──────▼───────┐ │ Database │ │
│ │ App Server │════════│ Server │ │
│ └──────────────┘ └────────────────┘ │
└─────────────────────────────────────────────────────────────┘
ArchiMate and TOGAF
Mapping to TOGAF Domains
TOGAF to ARCHIMATE MAPPING
TOGAF Domain ArchiMate Layer
─────────────────────────────────────────
Business Architecture → Business Layer
Strategy Layer
Data Architecture → Application Layer (Data Objects)
Application Arch. → Application Layer
Technology Arch. → Technology Layer
Physical Layer
TOGAF ADM ArchiMate Support
─────────────────────────────────────────
Phase B (Business) → Business viewpoints
Phase C (IS) → Application viewpoints
Phase D (Technology) → Technology viewpoints
Phase E-F (Planning) → Migration viewpoints
When to Use Each
| Use Case | Use ArchiMate | Use TOGAF |
|---|---|---|
| Formal EA documentation | ✓ | |
| Visual communication | ✓ | |
| Impact analysis | ✓ | |
| EA process/methodology | ✓ | |
| Governance framework | ✓ | |
| Repository structure | ✓ |
Tools
ArchiMate Modeling Tools
| Tool | Cost | Notes |
|---|---|---|
| Archi | Free | Open source, cross-platform, excellent for learning |
| Sparx Enterprise Architect | Commercial | Comprehensive, also supports UML |
| BiZZdesign Enterprise Studio | Commercial | Enterprise-focused, TOGAF integration |
| MEGA HOPEX | Commercial | Enterprise governance platform |
| Visual Paradigm | Commercial | Multi-methodology support |
Start with Archi
Archi is free, well-documented, and fully ArchiMate 3.x compliant. It's the best way to learn ArchiMate before investing in commercial tools.
Best Practices
Modeling Guidelines
ARCHIMATE BEST PRACTICES
DO:
├── Start with clear purpose/viewpoint
├── Use consistent naming conventions
├── Show appropriate level of detail for audience
├── Connect layers to show traceability
├── Use viewpoints for different stakeholders
└── Keep diagrams focused (7±2 elements)
DON'T:
├── Put everything in one diagram
├── Mix abstraction levels inappropriately
├── Create elements without relationships
├── Use ArchiMate for detailed software design (use UML)
└── Model to exhaustive detail initially
Naming Conventions
| Element Type | Convention | Example |
|---|---|---|
| Business Process | Verb + Noun | Process Order |
| Business Service | Noun + Service | Order Management Service |
| Application Component | System Name | Order Management System |
| Application Service | Verb + Noun | Submit Order |
| Technology Node | Environment + Purpose | Production App Server |
Quick Reference Card
┌─────────────────────────────────────────────────────────────┐
│ ARCHIMATE CHEAT SHEET │
├─────────────────────────────────────────────────────────────┤
│ │
│ LAYERS │
│ ───────────────────────────────────────────────────────── │
│ Strategy (Beige) → Direction, capabilities, resources │
│ Business (Yellow) → Processes, services, actors │
│ Application (Blue) → Components, services, data │
│ Technology (Green) → Nodes, devices, networks │
│ │
│ KEY RELATIONSHIPS │
│ ───────────────────────────────────────────────────────── │
│ ─────▶ Serving (provides functionality to) │
│ ─ ─ ─▶ Realization (implements) │
│ ○────▶ Assignment (allocated to) │
│ - - -▶ Access (reads/writes) │
│ ─────▶ Triggering (causes) │
│ ─────▶ Flow (transfers) │
│ │
│ ELEMENT PATTERN PER LAYER │
│ ───────────────────────────────────────────────────────── │
│ Active Structure → Who/what performs (actors, components) │
│ Behavior → What is done (processes, services) │
│ Passive Structure → What is acted upon (objects, data) │
│ │
│ COMMON VIEWPOINTS │
│ ───────────────────────────────────────────────────────── │
│ Organization → Org structure, actors, roles │
│ Business Process → Process flows, events, services │
│ Application → App components, interfaces, data │
│ Technology → Infrastructure, nodes, networks │
│ Layered → Cross-layer traceability │
│ │
└─────────────────────────────────────────────────────────────┘
Related Topics
- C4 Model - Simpler software architecture visualization
- TOGAF ADM - EA development framework
- Quality Attributes - Non-functional requirements
Sources
- ArchiMate 3.2 Specification - The Open Group
- Archi Tool - Free ArchiMate modeling
- Mastering ArchiMate - Gerben Wierda