Complete firstSystem boundarynot in catalog
The system or service in scope is named with a clear boundary and a primary audience for the diagram.
Without: Without a boundary, the C4 views drift between product, platform, and organization.
RunsheetArchitecture
C4 Model
ComplexityLow
Time1-4 h
Participants1-5
FormatWorkshop + async
MaturityCanonical
01
Prerequisite
What needs to be finished first
02
Preparation
What needs to be ready before start
Materials
Whiteboard or digital canvas; C4 template; sticky notes; existing architecture notes or diagrams; markers; optional deployment context sketch.
People / roles
One facilitator; one architect or technical lead; one domain expert; one to four additional participants who know the system and its users.
Pre-read
Scope of the system, important users and external dependencies, known container names, and any constraints that should already appear in the diagram.
Time needed
60-90 min
Setup
Start with the context view, then zoom into containers, then into components only where needed. Keep each level visible before moving to the next one.
03
Core question
The one question this method answers
How can the system be described at the right level of detail for communication and decisions?
04
Flow
Marker: Sektion
| Step | Duration | Action | Hint |
|---|---|---|---|
1Section 1: Context | 15 min | Describe the system boundary, the primary users, and the external systems around it. Capture the main interactions in one context view. | If the boundary is unclear, the diagram becomes a map of everything. Keep the focus on one system and its environment. |
2Section 2: Containers | 15 min | Identify the main containers that deliver or store the system's behavior, such as apps, services, databases, or queues. | Do not list every technical detail yet. Containers are the stable building blocks, not the implementation rabbit hole. |
3Section 3: Components | 20 min | Break down only the containers that matter most. Show the key responsibilities and how the parts interact. | Only zoom in where the audience needs more detail. A good C4 diagram avoids over-explaining the whole system. |
4Section 4: Code-level detail | 10 min | Add code-level detail only where a decision depends on it. Keep this part optional and tightly scoped. | If the conversation stays at component level, stop there. Code detail is a tool, not the default. |
5Section 5: Review and handoff | 10 min | Review the diagram with the audience, capture open questions, and agree which C4 level should be shared or stored next. | A diagram that nobody can use is unfinished. Check whether the next audience needs the context, container, or component view. |
05
Artifact
What comes out at the end
Form
A C4 set with at least a context diagram and a container diagram, plus a component view where needed, annotated with system boundary, major dependencies, and open questions.
Versioning / ownership
Store the diagram with date, system name, and audience. Keep context, container, and component versions separate so the right zoom level can be reused later.
Tool alternatives
- Structurizr
- Miro or FigJam
- Lucidchart or draw.io
- Whiteboard photo plus Markdown notes
c4-model-working-template.md
Compact working template for C4 Model with context, input, output artifacts, and next step.
C4 Model Working Template
Context
What is this method used for?
Core question
Which question should be answered at the end?
Input
Which data, observations, or materials are available?
Working area
- Area 1:
- Area 2:
- Area 3:
- Relationships / patterns:
Output artifacts
- Context Diagram:
- Container Diagram:
- Component Diagram:
Open questions
- ...
Next step
Owner, date, success signal.
06
Example output
Concrete filled scenario, fictional example
c4-model-beispiel.md
Concrete filled scenario, fictional example
C4 Model — Order platform
Context: Customers use the web app, support uses the back office, and the platform integrates with payment and ERP systems.
Containers: Web app, API service, order database, event queue, notification worker.
Component view: The API service contains order validation, payment orchestration, and fulfillment publishing.
Use: Share the context view with stakeholders, the container view with delivery teams, and the component view with engineers during design review.
07
Pitfalls
Recognize symptoms and steer against them
Trap
Too much code detail too early
Symptom
The group jumps straight into classes, functions, or file names before the system boundary is clear.
What to do
Start with context and containers first. Only add code-level detail when a decision actually depends on it.
Trap
Boundary is missing
Symptom
The diagram includes everything from the organization and no audience can read it quickly.
What to do
Name one system boundary and stick to it. If multiple systems matter, create separate diagrams.
Trap
Containers are vague
Symptom
Labels like 'backend' or 'infrastructure' hide the actual building blocks.
What to do
Name the concrete container and its responsibility. The value of C4 sits in making the structure explicit.
Trap
The wrong level is shared
Symptom
Stakeholders get a component view when they only needed context, or engineers receive only a high-level box diagram.
What to do
Choose the level according to the audience. Share only the level they can act on.
Trap
The diagram is not updated
Symptom
The picture no longer matches the actual system after a few releases.
What to do
Treat the C4 set as a living artifact and update it when major boundaries or containers change.
08
Stop criteria
Done signals checkable in under a minute
The system boundary cannot be named, so the diagram would stay vague.
No one in the room knows the system well enough to describe its containers.
The goal is a quick implementation task, not an architecture conversation.
There is no time to review the diagram with the intended audience.
The system is so small that a C4 set would be overkill.
No one will own the diagram after the session, so it would immediately go stale.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.