What needs to be finished first
There is a concrete reason for architecture work, such as a new system, a major redesign, or a platform launch, ideally with a business sponsor.
The main stakeholders for the system are identified so that goals, constraints, and quality attributes come from the right side.
What needs to be ready before start
Whiteboard or Miro board with canvas fields (goals, stakeholders, constraints, risks, quality attributes, system boundary, external interfaces, assumptions, next steps); stickies; template for ADR stub.
One architect as owner; 3-6 participants from Engineering, Product, Operations, Security; one facilitator, ideally external but can be the architect; scribe.
Business goal of the system; relevant business requirements; existing technical landscape; known constraints (budget, time, technology, compliance); similar systems as reference.
3-4 h
Put the canvas on the wall. Add a short explanation to each field. Rule: fill fields in sequence, not in parallel. Focus on a 10-page architecture, not a 100-slide deck.
The one question this method answers
Which minimal architecture decision covers the goals, constraints, and stakeholder needs without prematurely closing options?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Goals and system purpose | 20 min | Describe the system purpose in 2-3 sentences. Define the top 3 business goals and their metrics. Clarify what will change when the system is live. | If the goals are only about better architecture, they come from Engineering. Demand business outcomes. |
2Phase 2: Stakeholders and quality attributes | 30 min | List stakeholders with their main requirements. Derive the most important quality attributes from these requirements, such as performance, availability, security, and modifiability. | If all quality attributes are high, the prioritization was not serious. Force ranking by the decider. |
3Phase 3: System boundary and interfaces | 30 min | Define what is inside the system and what belongs to the environment. List external interfaces, such as consumers, suppliers, and data sources. | Clear boundaries prevent scope creep. If the boundary is fuzzy, requirements are often fuzzy too. |
4Phase 4: Constraints, risks, assumptions | 30 min | List constraints (technology, budget, time, compliance), risks (technical, organizational, business), and assumptions explicitly. Mark assumptions that are critical for the architecture. | Assumptions are often where architectures fail. Keep them explicit with date and owner so they can be revisited. |
5Phase 5: Next steps and ADR stubs | 30 min | Identify the top 3 architecture decisions that should become ADRs. Schedule the next workshops, for example QAW or Software Architecture Canvas. Assign an owner per stub. | The canvas is inception, not the end product. Next steps must be scheduled explicitly, otherwise the artifact disappears. |
What comes out at the end
Architecture Inception Canvas as an image plus Markdown with all fields filled with bullet points, tables, and short explanations. Supplemented by ADR stubs and a list of next workshops.
Canvas with date and version. Changes need a rationale. For larger changes, create a new entry and archive the previous one. Link ADR stubs.
Compact working template for Architecture Inception Canvas with context, input, output artifacts, and next step.
What is this method used for?
Which question should be answered at the end?
Which data, observations, or materials are available?
Owner, date, success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
System purpose: Booking API that supplies Workspot and partner platforms with consistent availability and booking data.
Goals
Stakeholders and top requirements
Quality attributes (prioritized)
System boundary: Booking API plus datastores. Auth service external. Notification service external.
External interfaces
Constraints
Risks
Assumptions
Next steps
Recognize symptoms and steer against them
Fields become mini-documents with detailed diagrams.
The canvas is inception, every entry should stay within 1-3 bullets. Move details to follow-up documents, such as ADR or SAC. Keep the facilitator disciplined.
The discussion relies on unstated assumptions that later blow up.
Force the assumptions field to be filled. Give each assumption a validation owner and a date. Plan a spike for critical uncertainty.
The architect arrives with a finished picture and the workshop is just a show.
Keep options open and discuss at least two alternatives for each top decision. The canvas is for option openness.
The canvas is filled, but nothing is decided and architecture work stalls.
Identify the top 3 decisions, create ADR stubs, and assign owner plus due date. Without this step, the canvas is not complete.
Only Engineering is in the room and the quality attributes become technical only.
At least Product, Operations, and Security need to be represented. If that is not possible, run separate interviews first and bring the results to the workshop.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.