What needs to be finished first
An Architecture Inception Canvas or comparable inception artifact exists, so goals, stakeholders and constraints are known.
Top quality attributes and scenarios are elaborated, so the canvas can build on them.
What needs to be ready before start
Whiteboard or Miro with canvas fields (context, goals, stakeholders, quality attributes, components, interfaces, data model, cross-cutting concerns, decisions, risks, roadmap); stickies; ADR template.
One architect as owner; 3-5 participants from engineering, operations, product, security; scribe; decider for critical decisions.
Inception Canvas, QA scenarios, existing system landscape, technology stack, known decisions from previous projects, budget and timeframe.
1 day (6-8 h)
Canvas fields large and visible. Plan 30-45 min per field. Rule: every entry contributes to the architecture statement, no completeness theater.
The one question this method answers
Which components, interfaces, decisions and cross-cutting concerns together form a consistent architecture that satisfies the quality attribute scenarios?
Marker: Sektion
| Step | Duration | Action | Hint |
|---|---|---|---|
1Section 1: Context and goals | 30 min | Take from inception: system purpose, goals, top stakeholders, boundary. Update if state has changed. | If much has changed since inception, update inception first. Otherwise canvas fields build on outdated assumptions. |
2Section 2: Quality attributes and trade-offs | 45 min | Take top scenarios from QAW. Identify potential trade-offs per scenario (for example performance vs. consistency). | Make trade-offs explicit. Without them, architecture looks like a free solution, which it is not. |
3Section 3: Components and interfaces | 90 min | Identify main components (5-12). Per component: responsibility, technology, communication pattern (synchronous, asynchronous). Make interfaces explicit. | If more than 15 components appear, granularity is too fine. Strategic view, not microservice collection. |
4Section 4: Data model and persistence | 60 min | Sketch main entities and data flows. Per datastore: persistence pattern (relational, document-based, event store). Ownership per data domain. | Shared database between components is a common anti-pattern. If unavoidable, mark explicitly as risk. |
5Section 5: Cross-cutting concerns | 60 min | Authentication, authorization, observability, logging, configuration, tracing, resilience patterns. For each concern, solution approach and owner. | Addressing cross-cutting too late is more expensive than from the start. Decide at least auth, logging and tracing. |
6Section 6: Decisions, risks, roadmap | 60 min | Top 5 architecture decisions as ADR stubs. Top 5 risks with mitigation. Roadmap with phases (for example MVP, scaling, internationalization). | Roadmap not too detailed. Main phases with quarterly granularity, details come from sprints. |
What comes out at the end
Software Architecture Canvas with all sections, filled with bullet points, diagrams (C4-light), tables. Complemented by ADRs, risk register and roadmap. Overall 5-15 pages depending on depth.
Canvas with date and version. Changes linked to ADRs. For larger changes, new entry with diff to previous period. Quarterly review.
Compact working template for the Software Architecture Canvas with system scope, constraints, quality attributes, and next step.
Capture the system, its goals, constraints, quality attributes, and open decisions in one place.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Context: Booking API as core service for Workspot web/mobile and partner integrations.
Goals: 5x volume, p95 under 600 ms, partner onboarding in 5 person-days.
Top QA scenarios
Main components
Interfaces
bookings.events.Data model and persistence
Cross-cutting concerns
Top decisions (ADRs)
Risks
Roadmap
Recognize symptoms and steer against them
Component section contains 30 microservices, strategic statement gets lost.
Limit to 5-12 strategic components. Details in C4-L3 or service catalog separately. Canvas remains big picture.
Components are defined, auth, logging, tracing are missing.
Cross-cutting section must be filled. At least auth, observability, resilience. Late solution is more expensive than early one.
Architecture appears magical, all quality attributes fulfilled at once.
Explicit trade-off per QA scenario. Which other aspect suffers, how is it mitigated.
Canvas shows target state, nobody knows sequence or phases.
Roadmap section with phases and milestones. Not too fine, at least rough quarterly structure.
Canvas entries remain assertions without rationale.
ADR per top decision with options and rationale. Canvas links ADRs.
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.