Complete firstClear scope
Agree the subject, boundary and decision before filling the model.
A broad or mixed scope produces a misleading model.
Method guideArchitecture
arc42
A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.
ComplexityLow
Time1-2 Tage
Participants1-4
FormatWorkshop + async
MaturityCanonical
01
Prerequisite
What needs to be finished first
Complete firstAccess to relevant evidence
Bring source material and people who know the work; distinguish facts from assumptions.
Unverified interpretations become false certainty.
02
Preparation
What needs to be ready before start
Materials
Shared visual workspace, source evidence, and an agreed decision question.
People / roles
Architect, developers, operations, domain stakeholders, decision owner.
Pre-read
Collect existing data, examples, constraints and relevant stakeholder perspectives.
Time needed
Several focused sessions; size by system complexity and available evidence.
Setup
Choose system, audience, level of detail and living-document owner. Capture business goals, quality goals and binding technical/organizational constraints. Describe external actors/systems, scope and the few decisions shaping the solution. Document relevant building blocks, runtime scenarios and deployment view only as needed. Link quality scenarios, risks, decisions and glossary; assign update triggers.
03
Core question
The one question this method answers
What system context, constraints, and decisions must the architecture communicate?
04
Flow
Phases with goal, actions, output and pitfall
Structures architecture knowledge across goals, context, runtime, deployment, decisions and risks.
arc42 architecture documentation
Fictional worked example
Fictional, “Practice Portal” system: top quality goal is availability during practice hours. Context: patients and practice administration; no direct payment processing. Strategy: initially use a synchronized availability copy. Runtime: reserve a slot, await confirmation, show alternatives on conflict. Risk: delayed synchronization. Maintain sections 1, 3, 4, 6 and 10 first; mark other sections as deliberate gaps.
Introduction and Goals
Record stakeholders, requirements and top quality goals.
Fictional: availability during practice hours is a priority.
Constraints
Name technical, organizational and regulatory constraints.
Privacy requirements and existing practice system.
Context and Scope
Explain boundary, external partners and interfaces.
Patients and practice management; no payment processing.
Solution Strategy
Explain guiding approaches and key architecture decisions.
Availability copy with conflict check.
Building Block View
Show relevant building blocks and responsibilities.
Booking API, web app, appointment database.
Runtime View
Describe critical scenarios and interactions.
Reserve slot; await confirmation.
Deployment View
Map infrastructure and software components.
Hosting and practice integration remain open.
Crosscutting Concepts
Document recurring concepts and rules.
Authentication and audit logging.
Architecture Decisions
Link important decisions with status and rationale.
Synchronization approach under review.
Quality Requirements
State quality scenarios measurably.
Fictional scenario: With the calendar copy available, 95% of slot searches during practice hours return availability within 2 seconds.
Risks and Technical Debt
Record risks, impact and response.
Stale availability may cause double booking.
Glossary
Define domain terms consistently.
Slot means a released time period.
The example text is fictional; replace it with sourced project information.
- 1
Scope
Set system and documentation need
Goal
Lean documentation plan
Inputs for this step
- System boundary, readers and existing architecture docs
Actions
- Name the system, stakeholders, key quality goals and documentation purpose; select relevant arc42 sections.
Output
Lean documentation plan
Lean documentation plan
Quality check
Does each section help stakeholders or development?
Pitfall
All twelve sections are fully completed regardless of need. Document what matters and mark deliberate gaps.
Timing: Allow time according to scope and evidence; no universal duration.
- 2
Goals
Document goals, constraints and context
Goal
Evidence-backed sections 1 to 3
Inputs for this step
- Requirements, constraints and external systems
Actions
- Write prioritized quality scenarios, sourced constraints, system context and interfaces.
Output
Evidence-backed sections 1 to 3
Evidence-backed sections 1 to 3
Quality check
Are quality goals verifiable and interfaces named?
Pitfall
Generic adjectives lack a measure or usage context. State trigger, expected response and measurable criterion.
Timing: Allow time according to scope and evidence; no universal duration.
- 3
Views
Develop strategy and views
Goal
Architecture description and relevant views
Inputs for this step
- Quality goals, current architecture and critical scenarios
Actions
- Describe key decisions and only the building-block, runtime and deployment views needed to explain them. Link diagrams to text.
Output
Architecture description and relevant views
Architecture description and relevant views
Quality check
Does each view answer a structural or quality question?
Pitfall
Diagrams duplicate or contradict one another. Choose one source of truth and link supporting views.
Timing: Allow time according to scope and evidence; no universal duration.
- 4
Upkeep
Maintain quality, decisions and risks
Goal
Living arc42 documentation
Inputs for this step
- Quality scenarios, risks, technical debt and ownership
Actions
- Record important decisions with status, risks and assumptions; link scenarios and assign update triggers.
Output
Living arc42 documentation
Living arc42 documentation
Quality check
Can readers distinguish current, open and outdated content?
Pitfall
Documentation goes stale after the workshop. Tie updates to review, release or system change.
Timing: Allow time according to scope and evidence; no universal duration.
05
Artifact
What comes out at the end
Sketch: what the artifact looks like
Form
Structures architecture knowledge across goals, context, runtime, deployment, decisions and risks. Record scope, evidence, assumptions, owner and next review in the versioned artifact.
Versioning / ownership
Record scope, date, participants, source version and owner. Note changed assumptions and the reason for each revision.
Tool alternatives
- Shared whiteboard or paper template
- Source links, records or measurement data
arc42-working-template.md
Prepare the decision, source evidence and next review.
arc42: Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Run the method Time: See catalog planning range; no universal duration.
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: Shared visual workspace, source evidence, and an agreed decision question.
- Roles: Architect, developers, operations, domain stakeholders, decision owner.
- Advance information: Collect existing data, examples, constraints and relevant stakeholder perspectives.
- Overall time needed: Several focused sessions; size by system complexity and available evidence.
- Setup: Choose system, audience, level of detail and living-document owner. Capture business goals, quality goals and binding technical/organizational constraints. Describe external actors/systems, scope and the few decisions shaping the solution. Document relevant building blocks, runtime scenarios and deployment view only as needed. Link quality scenarios, risks, decisions and glossary; assign update triggers.
Prepare for the work steps
Scope: Set system and documentation need
- System boundary, readers and existing architecture docs
Goals: Document goals, constraints and context
- Requirements, constraints and external systems
Views: Develop strategy and views
- Quality goals, current architecture and critical scenarios
Upkeep: Maintain quality, decisions and risks
- Quality scenarios, risks, technical debt and ownership
arc42 architecture documentation
Introduction and Goals
Record stakeholders, requirements and top quality goals.
...
Constraints
Name technical, organizational and regulatory constraints.
...
Context and Scope
Explain boundary, external partners and interfaces.
...
Solution Strategy
Explain guiding approaches and key architecture decisions.
...
Building Block View
Show relevant building blocks and responsibilities.
...
Runtime View
Describe critical scenarios and interactions.
...
Deployment View
Map infrastructure and software components.
...
Crosscutting Concepts
Document recurring concepts and rules.
...
Architecture Decisions
Link important decisions with status and rationale.
...
Quality Requirements
State quality scenarios measurably.
...
Risks and Technical Debt
Record risks, impact and response.
...
Glossary
Define domain terms consistently.
...
This blank document contains only section prompts.
Scope: Set system and documentation need
Expected artifact: Lean documentation plan
Lean documentation plan
Entry:
...
- Does each section help stakeholders or development?
Goals: Document goals, constraints and context
Expected artifact: Evidence-backed sections 1 to 3
Evidence-backed sections 1 to 3
Entry:
...
- Are quality goals verifiable and interfaces named?
Views: Develop strategy and views
Expected artifact: Architecture description and relevant views
Architecture description and relevant views
Entry:
...
- Does each view answer a structural or quality question?
Upkeep: Maintain quality, decisions and risks
Expected artifact: Living arc42 documentation
Living arc42 documentation
Entry:
...
- Can readers distinguish current, open and outdated content?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/arc42/run-sheet
06
Example output
Concrete filled scenario, fictional example
Fictional example for orientation. Counts and timings describe this case and are not universal requirements.
arc42-beispiel.md
Concrete filled scenario, fictional example
Fictional, “Practice Portal” system: top quality goal is availability during practice hours. Context: patients and practice administration; no direct payment processing. Strategy: initially use a synchronized availability copy. Runtime: reserve a slot, await confirmation, show alternatives on conflict. Risk: delayed synchronization. Maintain sections 1, 3, 4, 6 and 10 first; mark other sections as deliberate gaps.
07
Pitfalls
Recognize symptoms and steer against them
Quick overview, the full text is in the matching phase in the flow
- Set system and documentation needAll twelve sections are fully completed regardless of need.View in phase
- Document goals, constraints and contextGeneric adjectives lack a measure or usage context.View in phase
- Develop strategy and viewsDiagrams duplicate or contradict one another.View in phase
- Maintain quality, decisions and risksDocumentation goes stale after the workshop.View in phase
Trap
Set system and documentation need
Symptom
All twelve sections are fully completed regardless of need.
What to do
Document what matters and mark deliberate gaps.
Trap
Document goals, constraints and context
Symptom
Generic adjectives lack a measure or usage context.
What to do
State trigger, expected response and measurable criterion.
Trap
Develop strategy and views
Symptom
Diagrams duplicate or contradict one another.
What to do
Choose one source of truth and link supporting views.
Trap
Maintain quality, decisions and risks
Symptom
Documentation goes stale after the workshop.
What to do
Tie updates to review, release or system change.
08
Stop criteria
When to pause, resolve prerequisites, or choose another approach
Stop if the decision question or scope is disputed; align it first.
Stop if key inputs are unavailable; list what evidence is needed.
Stop if the group treats assumptions as observed facts.
Finished the method guide?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.