Skip to content
Software Architecture Guide

Architecture Canvas

Explanation

Section titled “Explanation”

An architecture canvas turns a complex topic into a single structured page. The arc42 canvases build on ideas from the Business Model Canvas (see the article of that name).

The canvas works as a workshop tool. Stakeholders brainstorm the sections together, ideally on large paper. The shared page helps the group understand each other. The canvas is fully compatible with the arc42 template (see arc42 Architecture Documentation Template).

Three variants

  • Inception Canvas. It is for creating and envisioning new systems from scratch. It builds on Patrick Roos’ Software Architecture Canvas.
  • Communication Canvas. It has fields for describing a system, such as core decisions, components and technologies.
  • Tech Stack Canvas. It is an INNOQ approach. It puts all relevant technologies on one page. You can use it to plan new projects or to document the status quo of an existing product.

Selected Inception fields

  • Business Case is the “why” field. It names the economic driver behind a software initiative.
  • Quality goals ask for the three most important goals of the stakeholders. These goals drive the architecture.
  • Architectural hypotheses record your assumptions. Ideally, you can turn them into draft architecture decision records (see Architectural Decision Record).
  • Business context treats your system as a black box, separate from its communication partners.

Selected Communication fields

  • Core Decisions asks which decisions led to the current state of the system.
  • Components lists the major building blocks, such as modules, subsystems, packages, components or services.
  • Technologies lists the most important technologies for development and operation.

Example

Section titled “Example”

A small team must start a new booking system next week. They gather around a large sheet of paper laid out as an Inception Canvas. Together they write the business case, pick three quality goals and note their first architectural assumptions. They draw the system as a black box with its communication partners. Later, they turn an assumption into a draft decision record.

Trade-offs

Section titled “Trade-offs”

The facts give no limits of the canvas. One page forces you to keep only the essentials, so detail has to live elsewhere, for example in the full arc42 template.

Checks

Section titled “Checks”
  • The document lists the three most important stakeholder quality goals.
  • Architectural assumptions are recorded and, where possible, drafted as decision records.
  • The business context shows the system as a black box apart from its communication partners.
  • The decisions that led to the current system state are named.
Section titled “Related”

Sources

Section titled “Sources”