Modeling with ArchiMate and C4

Start with the audience, not the notation

The most common modeling mistake isn’t using the wrong notation. It’s drawing a diagram without knowing who it’s for or what question it answers.

The international standard for architecture description, ISO/IEC/IEEE 42010, gives you the vocabulary:

• Stakeholders have concerns: cost, security, time to market, which team owns what.
• A viewpoint is a template for building views that address particular concerns: which elements to show, which notation to use, which audience it’s for.
• A view is the actual diagram or model for your architecture, built according to a viewpoint.

Before drawing anything, answer three questions:

1. Who is this for?
2. What question does it answer for them?
3. What can I leave out?

The third question matters most. A diagram that shows everything communicates nothing.

ArchiMate essentials

ArchiMate is The Open Group’s modeling language for enterprise architecture. It’s closely aligned with TOGAF, and its main strength is connecting layers: showing how business capabilities and processes depend on applications, and how applications depend on technology.

Layers

Layer	Describes	Example elements
Strategy	Capabilities, value streams, resources, courses of action	Capability, Value Stream, Resource
Business	Actors, roles, processes, services, business objects	Business Actor, Business Process, Business Service
Application	Applications, their services, interfaces, and data	Application Component, Application Service, Data Object
Technology	Platforms, infrastructure, networks	Node, System Software, Technology Service
Physical	Equipment, facilities, materials	Equipment, Facility
Implementation & Migration	Work packages, deliverables, plateaus, gaps	Work Package, Plateau, Gap

Motivation elements (stakeholders, drivers, goals, principles, requirements) can be connected to any layer to show why something exists.

Aspects

Within each core layer, elements fall into three aspects, which makes the language consistent across layers:

Aspect	Question	Business	Application	Technology
Active structure	Who or what acts?	Business Actor	Application Component	Node
Behavior	What do they do?	Business Process / Service	Application Function / Service	Technology Service
Passive structure	What is acted on?	Business Object	Data Object	Artifact

The relationships you’ll use most

ArchiMate defines a dozen relationship types. These cover most diagrams:

Relationship	Meaning	Example
Serving	Provides functionality to	Payments API serves Rent Collection process
Realization	Implements or makes real	PayNest realizes Payment Processing service
Assignment	Is responsible for performing	Collections team assigned to Arrears process
Access	Reads or writes	Billing app accesses Invoice data object
Composition / Aggregation	Is made up of	Core platform composed of components
Flow / Triggering	Passes something to / causes	Lease signed triggers First rent collection

Useful viewpoints

You don’t need all of ArchiMate’s example viewpoints. These are the ones EAs use most:

• Capability map: strategy layer only. You built one in module 4.
• Layered view: one business process or service, traced down through applications to technology. Great for impact analysis.
• Application cooperation: which applications exchange which data. Great for integration discussions.
• Migration / plateau view: baseline, transition, and target states with the work packages between them.

C4 essentials

The C4 model, created by Simon Brown, is a lightweight approach to diagramming software systems at four levels of zoom:

Level	Shows	Audience
1. System Context	The system, its users, and the other systems it interacts with	Everyone, including non-technical people
2. Container	The deployable/runnable units inside the system (apps, services, databases, queues) and how they communicate	Architects, engineers, ops
3. Component	The major components inside one container	Engineers working on that container
4. Code	Classes, functions, and so on	Rarely drawn by hand; generate if needed

Supplementary diagrams cover the system landscape (all systems in the enterprise), dynamic flows, and deployment.

C4 deliberately has very little notation. Every element has a name, a type, a technology, and a short description, and every relationship arrow has a label. That simplicity is why engineering teams adopt it readily.

When to use which

Situation	Use
Connecting capabilities and processes to applications and technology	ArchiMate
Enterprise-wide impact analysis (“what breaks if we retire this?”)	ArchiMate, ideally in a tool
Migration and plateau planning	ArchiMate (Implementation & Migration layer)
Explaining one system to an engineering audience	C4
Design docs, ADRs, onboarding	C4
A board or executive deck	Neither, strictly. A simple, clear picture informed by the model

They work well together: ArchiMate for the enterprise landscape, C4 for solution detail. Keep them consistent by using the same names for the same systems in both.

At Quillfeather

A C4 system context diagram: notifications

Engineers were arguing about notification consolidation without a shared picture. You drew this first:

  ┌────────────┐      ┌────────────┐      ┌────────────┐
  │   Tenant   │      │  Property  │      │ Contractor │
  │  [Person]  │      │  manager   │      │  [Person]  │
  └─────▲──────┘      └─────▲──────┘      └─────▲──────┘
        │                   │                   │
        └────────── email / SMS / push ─────────┘
                            │
             ┌──────────────┴─────────────┐          ┌───────────────────────┐
             │ Notification Platform      │  reads   │ Customer master       │
             │ [Software System]          ├─────────►│ (consent, preferences)│
             │ Sends all customer comms   │          └───────────────────────┘
             └────▲─────────▲─────────▲───┘
                  │         │         │
   "send rent     │         │         │     "send job
    reminder"     │         │         │      assignment"
           ┌──────┴───┐ ┌───┴──────┐ ┌┴───────────┐
           │   Core   │ │ PayNest  │ │ FixIt Pro  │
           │ platform │ │          │ │            │
           └──────────┘ └──────────┘ └────────────┘

It’s deliberately simple, and it showed the CPO and the three teams the target they were arguing about: one platform, one consent source, three callers.

An ArchiMate layered view: Rent Collection

For the CFO and Head of Payments you used a layered view, tracing the Collect Rent business process down through the application and technology layers:

Layer	Elements
Business	Collect Rent process → served by Payment Collection business service; Tenant actor
Application	PayNest component realizes Payment Processing; Core platform serves lease and amount data; Notification Platform serves reminders
Technology	PayNest runs on its own AWS account; payment gateway as an external technology service
Implementation & Migration	Work package Add SEPA Direct Debit, part of plateau T1 Launch-ready

Seeing it layered made it obvious that SEPA support was a PayNest extension, not a new system. That was the point of contention with the Head of Payments, who had worried it meant PayNest would be absorbed.

Tooling

Approach	Examples	Fits when
Whiteboard / drawing tools	Excalidraw, Miro, draw.io	Early exploration; workshops
Diagrams as code	Structurizr (C4), Mermaid, PlantUML (with C4-PlantUML)	Engineering-facing views that live next to code and ADRs
Free ArchiMate modeling	Archi	Learning ArchiMate; a small EA practice building its first real model
EA repository platforms	LeanIX, Ardoq, Bizzdesign, Sparx Enterprise Architect	Larger portfolios needing inventory, impact analysis, and reporting

For a scaling organization, a sensible path is: diagrams as code for solution views, Archi to learn ArchiMate and build the first enterprise model, and an EA platform only once you’re maintaining an application inventory that people actually query. That’s usually when it outgrows a spreadsheet.

Exercise

Pick one important system in your organization and draw:

1. A C4 system context diagram for an executive audience. Use at most eight boxes.
2. A layered view (in ArchiMate, or as a simple table like the one above) for one business process it supports.

Show each to someone in its intended audience. What questions do they ask? Those questions tell you what the diagram failed to answer.

Reflection

• Find an architecture diagram in your organization’s wiki. Who was it for, and what question does it answer? Can you tell?
• Where would a single shared enterprise model save your organization real time?
• What’s the smallest tooling change that would improve how your organization communicates architecture?