Skip to main content

Command Palette

Search for a command to run...

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

Loading diagram...

Layer Colors (Standard)

LayerColorFocus
StrategyBeige/TanDirection and motivation
BusinessYellowOrganization and processes
ApplicationBlueSoftware and data
TechnologyGreenInfrastructure
PhysicalGreen (darker)Physical elements
ImplementationPink/SalmonProjects and work packages

Element Types

Active Structure (Who/What Performs)

ElementSymbolDescription
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 InterfacePoint of access for business services

Behavior (What is Done)

ElementSymbolDescription
Business Process▷ (rounded arrow)Sequence of activities producing value
Business Function□ (rounded)Collection of behavior based on skills
Business Interaction▷▷Collaboration behavior
Business EventState change that triggers behavior
Business Service□ with lineExternally visible behavior

Passive Structure (What is Acted Upon)

ElementSymbolDescription
Business ObjectConcept with business relevance
Contract□ with folded cornerFormal agreement
Representation□ (document)Perceptible form of business object
Product□ with barCoherent 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 LayerTo LayerTypical Relationship
BusinessApplicationServed by (app serves business)
ApplicationTechnologyRealized by (tech realizes app)
BusinessBusinessVarious (assignment, flow, etc.)
ApplicationApplicationVarious (serving, flow, etc.)

Viewpoints

Viewpoint Purpose

Viewpoints define which elements and relationships to include for a specific stakeholder concern.

Key Viewpoints

ViewpointPurposeTypical Audience
OrganizationShow structure of organizationManagement
Business ProcessShow process flowsProcess owners
Application BehaviorShow app functionalitySolution architects
Application StructureShow app componentsDevelopers
TechnologyShow infrastructureInfrastructure team
LayeredShow all layersEnterprise architects
MigrationShow transformationProgram managers

Layered Viewpoint Example

LAYERED VIEWPOINT (Cross-Layer View)

┌─────────────────────────────────────────────────────────────┐
│ BUSINESS                                                    │
│   ┌──────────────┐         ┌──────────────┐                │
│   │   Customer   │────────▶│Order Process │                │
│   └──────────────┘         └───────┬──────┘                │
├────────────────────────────────────┼────────────────────────┤
│ APPLICATION                        │                        │
│                           ┌────────▼───────┐                │
│   ┌──────────────┐        │ Order Service  │                │
│   │  Order App   │────────│               │                │
│   └──────┬───────┘        └────────┬───────┘                │
├──────────┼─────────────────────────┼────────────────────────┤
│ TECHNOLOGY                         │                        │
│          │                ┌────────▼───────┐                │
│   ┌──────▼───────┐        │    Database    │                │
│   │ App Server   │════════│    Server      │                │
│   └──────────────┘        └────────────────┘                │
└─────────────────────────────────────────────────────────────┘
Loading diagram...

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 CaseUse ArchiMateUse TOGAF
Formal EA documentation
Visual communication
Impact analysis
EA process/methodology
Governance framework
Repository structure

Tools

ArchiMate Modeling Tools

ToolCostNotes
ArchiFreeOpen source, cross-platform, excellent for learning
Sparx Enterprise ArchitectCommercialComprehensive, also supports UML
BiZZdesign Enterprise StudioCommercialEnterprise-focused, TOGAF integration
MEGA HOPEXCommercialEnterprise governance platform
Visual ParadigmCommercialMulti-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 TypeConventionExample
Business ProcessVerb + NounProcess Order
Business ServiceNoun + ServiceOrder Management Service
Application ComponentSystem NameOrder Management System
Application ServiceVerb + NounSubmit Order
Technology NodeEnvironment + PurposeProduction 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                │
│                                                             │
└─────────────────────────────────────────────────────────────┘


Sources