Complete firstClear working frame
Use Patrick Roos’ published version 1.0 as the field reference; record team, system, date and iteration.
Without a bounded question or checkable evidence, the result will be unclear.
Method guideArchitecture
Software Architecture Canvas
A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.
ComplexityLow
Time1-2 h
Participants3-10
FormatWorkshop
MaturityEstablished
01
Prerequisite
What needs to be finished first
02
Preparation
What needs to be ready before start
Materials
Original canvas, business case, functional overview and verifiable constraints.
People / roles
Product/business · software architecture · engineering · key stakeholders.
Pre-read
Choose materials, data access and participants to fit the research or decision question.
Time needed
60–120 minutes; research, sizing and technical spikes are separate.
Setup
Open the method-specific structure. Fictional examples are for orientation only; keep the blank worksheet separate from actual findings.
03
Core question
The one question this method answers
Which business and functional context bounds the solution space, and which architecture hypotheses must be tested?
04
Flow
Phases with goal, actions, output and pitfall
Patrick Roos’ Software Architecture Canvas structures early architecture around Goals, Solution and Assessment, with fields from the published original.
Software Architecture Canvas fields from the published template
Fictional example
Source-defined fields only; use the linked version. The example is fictional and the working canvas begins empty.
Business Case
Describe the business case or economic driver.
A rental platform may simplify bookings; driver remains unconfirmed.
Functional Overview
List the most important high-level functions.
Check availability, request a reservation, receive confirmation.
Quality Goals
Name the three highest-priority architecture quality goals.
Keep reservation status clear during concurrent requests; metric open.
Business Context
Separate the system from users and neighboring systems.
Customers and payment service are outside partners.
Organisational Constraints
Record requirements restricting architecture freedom.
Existing booking operation is a proposed constraint to verify.
Technical Constraints
Record technical requirements restricting design choices.
Existing booking interface is unknown pending investigation.
Architectural Hypotheses
Record important/risky decisions with reasons.
Test synchronization in a technical spike before deciding.
Technical Challenges & Risks
List current known challenges and technical risks.
Timeout could leave a reservation ambiguous.
- 1
Context
Name initiative and context
Goal
Record team, system, date and iteration.
Inputs for this step
- Use Patrick Roos’ published version 1.0 as the field reference; record team, system, date and iteration.
- Original canvas, business case, functional overview and verifiable constraints.
Actions
- Complete the header of Patrick Roos’ canvas and clarify business case before technical options.
- Record Shared architecture context with its evidence status, source or open verification need.
Output
Shared architecture context
Shared architecture context
Quality check
Is purpose separate from solution?
Pitfall
Technology choice begins without a business driver. Clarify business case first.
Timing: About 10–20 minutes; schedule data or clarification work separately.
- 2
Goals
Complete the Goals section
Goal
Describe the business driver and high-level functions.
Inputs for this step
- Shared architecture context
- Original canvas, business case, functional overview and verifiable constraints.
Actions
- Use the original Business Case and Functional Overview fields.
- Record Business case and functional overview with its evidence status, source or open verification need.
Output
Business case and functional overview
Business case and functional overview
Quality check
Are desired outcomes clear?
Pitfall
A generic vision replaces the core value. State a testable business question.
Timing: About 10–20 minutes; schedule data or clarification work separately.
- 3
Solution
Shape the solution playground
Goal
Keep original field structure; label assumptions and evidence.
Inputs for this step
- Business case and functional overview
- Original canvas, business case, functional overview and verifiable constraints.
Actions
- Use the published fields for quality goals, business context, constraints and architectural hypotheses.
- Record Solution frame and hypotheses with its evidence status, source or open verification need.
Output
Solution frame and hypotheses
Solution frame and hypotheses
Quality check
Can each hypothesis be checked?
Pitfall
Fields from unrelated canvases are mixed in. Keep the source model intact and mark assumptions.
Timing: About 10–20 minutes; schedule data or clarification work separately.
- 4
Risks
Assess risks and next investigations
Goal
Assign owners to spikes or evidence checks.
Inputs for this step
- Solution frame and hypotheses
- Original canvas, business case, functional overview and verifiable constraints.
Actions
- Document technical challenges and risks; turn hypotheses into investigations rather than decisions.
- Record Assessment and next checks with its evidence status, source or open verification need.
Output
Assessment and next checks
Assessment and next checks
Quality check
Is claim status unambiguous?
Pitfall
A canvas statement is treated as an approved decision. Add status, owner and validation date.
Timing: About 10–20 minutes; schedule data or clarification work separately.
05
Artifact
What comes out at the end
Sketch: what the artifact looks like
Form
Versioned record of question, evidence, result, uncertainty, owners and next review date.
Versioning / ownership
Track date, scope, sources, assumptions and changes; assign an owner and review for ongoing practice or initiatives.
Tool alternatives
- Paper and pens
- Whiteboard or simple table
software-architecture-canvas-working-template.md
Plan a session or initiative to match the actual scope of work.
Software Architecture Canvas: Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Prepare the full method Time: 60–120 minutes; research, sizing and technical spikes are separate.
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: Original canvas, business case, functional overview and verifiable constraints.
- Roles: Product/business · software architecture · engineering · key stakeholders.
- Advance information: Choose materials, data access and participants to fit the research or decision question.
- Overall time needed: 60–120 minutes; research, sizing and technical spikes are separate.
- Setup: Open the method-specific structure. Fictional examples are for orientation only; keep the blank worksheet separate from actual findings.
Prepare for the work steps
Context: Name initiative and context
- Use Patrick Roos’ published version 1.0 as the field reference; record team, system, date and iteration.
- Original canvas, business case, functional overview and verifiable constraints.
Goals: Complete the Goals section
- Shared architecture context
- Original canvas, business case, functional overview and verifiable constraints.
Solution: Shape the solution playground
- Business case and functional overview
- Original canvas, business case, functional overview and verifiable constraints.
Risks: Assess risks and next investigations
- Solution frame and hypotheses
- Original canvas, business case, functional overview and verifiable constraints.
Software Architecture Canvas fields from the published template
Business Case
Describe the business case or economic driver.
...
Functional Overview
List the most important high-level functions.
...
Quality Goals
Name the three highest-priority architecture quality goals.
...
Business Context
Separate the system from users and neighboring systems.
...
Organisational Constraints
Record requirements restricting architecture freedom.
...
Technical Constraints
Record technical requirements restricting design choices.
...
Architectural Hypotheses
Record important/risky decisions with reasons.
...
Technical Challenges & Risks
List current known challenges and technical risks.
...
Software Architecture Canvas by Patrick Roos, version 1.0
Context: Name initiative and context
Expected artifact: Shared architecture context
Shared architecture context
Entry:
...
- Is purpose separate from solution?
Goals: Complete the Goals section
Expected artifact: Business case and functional overview
Business case and functional overview
Entry:
...
- Are desired outcomes clear?
Solution: Shape the solution playground
Expected artifact: Solution frame and hypotheses
Solution frame and hypotheses
Entry:
...
- Can each hypothesis be checked?
Risks: Assess risks and next investigations
Expected artifact: Assessment and next checks
Assessment and next checks
Entry:
...
- Is claim status unambiguous?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/software-architecture-canvas/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.
software-architecture-canvas-beispiel.md
Concrete filled scenario, fictional example
Fictional example: rental platform
Business case: Simplify reservations and pickup; the economic driver is unconfirmed.
Functional overview: Check availability, request a reservation, receive confirmation.
Quality goal: Keep status understandable during concurrent requests; operations must define a measurement scenario.
Business context: Customers and payment service.
Constraint: Connection to the existing booking system needs confirmation.
Architectural hypothesis: Synchronization is practical; a spike tests conflict handling.
Risk: A timeout may leave reservation state unclear.
07
Pitfalls
Recognize symptoms and steer against them
Quick overview, the full text is in the matching phase in the flow
- Name initiative and contextTechnology choice begins without a business driver.View in phase
- Complete the Goals sectionA generic vision replaces the core value.View in phase
- Shape the solution playgroundFields from unrelated canvases are mixed in.View in phase
- Assess risks and next investigationsA canvas statement is treated as an approved decision.View in phase
Trap
Name initiative and context
Symptom
Technology choice begins without a business driver.
What to do
Clarify business case first.
Trap
Complete the Goals section
Symptom
A generic vision replaces the core value.
What to do
State a testable business question.
Trap
Shape the solution playground
Symptom
Fields from unrelated canvases are mixed in.
What to do
Keep the source model intact and mark assumptions.
Trap
Assess risks and next investigations
Symptom
A canvas statement is treated as an approved decision.
What to do
Add status, owner and validation date.
08
Stop criteria
When to pause, resolve prerequisites, or choose another approach
The field structure comes from Roos’ published original. arc42 describes AIC as a greenfield continuation. Do not swap in ACC fields or invent a generic canvas.
Finished the method guide?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.