Session Brief: Software Architecture Canvas

Goal

Artifact: Architecture Canvas

Working Question

Which components, interfaces, decisions and cross-cutting concerns together form a consistent architecture that satisfies the quality attribute scenarios?

Context

Inception Canvas, QA scenarios, existing system landscape, technology stack, known decisions from previous projects, budget and timeframe.

Setup

• Format: Method session
• Duration: 1 day (6-8 h)
• Mode: Workshop
• Participants: One architect as owner; 3-5 participants from engineering, operations, product, security; scribe; decider for critical decisions.
• Owner: One architect as owner
• Participation mode: Team round, shared work and alignment
• Outcome logic: Finish artifact

Participation Logic

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome Logic

The session works directly toward Architecture Canvas. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Whiteboard or Miro with canvas fields (context, goals, stakeholders, quality attributes, components, interfaces, data model, cross-cutting concerns, decisions, risks, roadmap); stickies; ADR template.

Preparation

Canvas fields large and visible. Plan 30-45 min per field. Rule: every entry contributes to the architecture statement, no completeness theater.

Agenda

1. Section 1: Context and goals (30 min) Owner: Facilitator Action: Take from inception: system purpose, goals, top stakeholders, boundary. Update if state has changed. Hint: If much has changed since inception, update inception first. Otherwise canvas fields build on outdated assumptions. Output: Architecture Canvas

2. Section 2: Quality attributes and trade-offs (45 min) Owner: Facilitator Action: Take top scenarios from QAW. Identify potential trade-offs per scenario (for example performance vs. consistency). Hint: Make trade-offs explicit. Without them, architecture looks like a free solution, which it is not. Output: Goals

3. Section 3: Components and interfaces (90 min) Owner: Facilitator Action: Identify main components (5-12). Per component: responsibility, technology, communication pattern (synchronous, asynchronous). Make interfaces explicit. Hint: If more than 15 components appear, granularity is too fine. Strategic view, not microservice collection. Output: Constraints

4. Section 4: Data model and persistence (60 min) Owner: Facilitator Action: Sketch main entities and data flows. Per datastore: persistence pattern (relational, document-based, event store). Ownership per data domain. Hint: Shared database between components is a common anti-pattern. If unavoidable, mark explicitly as risk. Output: Quality Attributes

5. Section 5: Cross-cutting concerns (60 min) Owner: Facilitator Action: Authentication, authorization, observability, logging, configuration, tracing, resilience patterns. For each concern, solution approach and owner. Hint: Addressing cross-cutting too late is more expensive than from the start. Decide at least auth, logging and tracing. Output: Architecture Canvas

6. Section 6: Decisions, risks, roadmap (60 min) Owner: Owner Action: Top 5 architecture decisions as ADR stubs. Top 5 risks with mitigation. Roadmap with phases (for example MVP, scaling, internationalization). Hint: Roadmap not too detailed. Main phases with quarterly granularity, details come from sprints. Output: Goals

7. Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: Architecture Canvas

Closeout

• Update result artifact: Architecture Canvas
• Define location, version, and review recipients.
• Define owner, next step, and review date.

Architecture Canvas: Software Architecture Canvas

Working Question

Which components, interfaces, decisions and cross-cutting concerns together form a consistent architecture that satisfies the quality attribute scenarios?

Context

Inception Canvas, QA scenarios, existing system landscape, technology stack, known decisions from previous projects, budget and timeframe.

Participants

• Owner: One architect as owner
• Participants: One architect as owner; 3-5 participants from engineering, operations, product, security; scribe; decider for critical decisions.

Input

Whiteboard or Miro with canvas fields (context, goals, stakeholders, quality attributes, components, interfaces, data model, cross-cutting concerns, decisions, risks, roadmap); stickies; ADR template.

Template

Software Architecture Canvas Working Template

Goal

Capture the system, its goals, constraints, quality attributes, and open decisions in one place.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Working area

• System and scope:
• Goals:
• Constraints:
• Quality attributes:
• Key building blocks:
• Open decisions and questions:

Output artifacts

• Architecture canvas:
• Constraint list:
• Decision log:

Assumptions and open questions

• ...

Decision / next step

Owner, date, and success signal.

Completion Check

• Architecture Canvas is complete enough for review:
• Location:
• Version / status:
• Review by:
• Next step:

Next Step

• Review result
• Mark open questions
• Schedule review or decision