methodatlas
Method guideArchitecture

Architecture Inception 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-8
FormatWorkshop
MaturityEstablished
Plan the work
01

Prerequisite

What needs to be finished first

Complete firstClear working frame

Use the published Architecture Inception Canvas and record system, team, workshop date and iteration.

Without a bounded question or checkable evidence, the result will be unclear.
02

Preparation

What needs to be ready before start

Materials

Official canvas, business goals, communication partners, known constraints and key stakeholders.

People / roles

Product/business · software architecture · engineering · stakeholders responsible for quality.

Pre-read

Choose materials, data access and participants to fit the research or decision question.

Time needed

60–120 minutes with prepared participants; missing requirements or technical research 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 goals, constraints and testable architecture hypotheses shape the new system?

04

Flow

Phases with goal, actions, output and pitfall

A compact inception workshop for a new system: business case, functions, context, quality goals, constraints, hypotheses and risks.

Architecture Inception 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 or economic driver.

A rental booking service is proposed; the economic driver still needs confirmation.

Functional Overview

List the most important functions at high level.

Check availability, request a reservation and receive confirmation.

Business Context

Show the system as a black box and its communication partners.

Customers and payment service are neighboring partners.

Organisational Constraints

Record organizational limits on design choices.

Must connect to the existing booking operation; owner to confirm.

Quality Goals

Name three top quality goals from key stakeholder view.

Clear status during concurrent reservations; metric still open.

Technical Constraints

Record technical limits on design choices.

Existing booking interface needs verification.

Architectural Hypotheses

Record consequential architecture hypotheses and reasons.

A spike tests whether availability can be synchronized reliably.

Technical Challenges & Risks

List known technical challenges and risks.

Timeout may leave reservation status unclear.

Architecture Inception Canvas (official PDF)

  1. 1

    System

    Name system and business case

    Goal

    Start with why the system is needed, not technology selection.

    Inputs for this step

    • Use the published Architecture Inception Canvas and record system, team, workshop date and iteration.
    • Official canvas, business goals, communication partners, known constraints and key stakeholders.

    Actions

    • Complete system, team, date and iteration; describe business case and functional overview for a new system.
    • Record Context for a greenfield inception with its evidence status, source or open verification need.

    Output

    Context for a greenfield inception

    Context for a greenfield inception

    Quality check

    Is purpose separate from technology?

    Pitfall

    The workshop starts with a stack debate. Clarify business case and functions first.

    Timing: About 10–20 minutes; schedule data or clarification work separately.

  2. 2

    Goals

    Capture context and quality goals

    Goal

    Name neighboring users/systems and prioritize quality goals.

    Inputs for this step

    • Context for a greenfield inception
    • Official canvas, business goals, communication partners, known constraints and key stakeholders.

    Actions

    • Draw the system as a black box with communication partners; record the top quality goals from stakeholder view.
    • Record Context diagram and quality goals with its evidence status, source or open verification need.

    Output

    Context diagram and quality goals

    Context diagram and quality goals

    Quality check

    Are partners and quality expectations concrete?

    Pitfall

    Quality wishes have no owner or scenario. Add stakeholder, situation and measure.

    Timing: About 10–20 minutes; schedule data or clarification work separately.

  3. 3

    Constraints

    Record constraints

    Goal

    Verify each constraint and its authority.

    Inputs for this step

    • Context diagram and quality goals
    • Official canvas, business goals, communication partners, known constraints and key stakeholders.

    Actions

    • Separate binding requirements from preferences; add source, owner and effect.
    • Record Traceable constraints with its evidence status, source or open verification need.

    Output

    Traceable constraints

    Traceable constraints

    Quality check

    Is every constraint binding and verifiable?

    Pitfall

    Preference is treated as immutable. Record source and ability to change.

    Timing: About 10–20 minutes; schedule data or clarification work separately.

  4. 4

    Hypotheses

    Record hypotheses and risks

    Goal

    Mark assumptions as hypotheses and plan validation before commitment.

    Inputs for this step

    • Traceable constraints
    • Official canvas, business goals, communication partners, known constraints and key stakeholders.

    Actions

    • List consequential architecture hypotheses with reasons, technical risks and a way to investigate them.
    • Record Hypotheses and technical challenges with its evidence status, source or open verification need.

    Output

    Hypotheses and technical challenges

    Hypotheses and technical challenges

    Quality check

    Is a concrete check planned?

    Pitfall

    An early option is treated as an approved decision. Record evidence, counterexample and decision criterion.

    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

Architecture Inception Canvas · Inception BoardConnect problem, goals, constraints, risks, architecture ideas, and next investigations
Architecture Inception CanvasThe sketch shows an early architecture workspace with context, inception canvas, and next investigations.Architecture inception as a shared working boardProblem, goals, and constraints turn into architecture hypotheses and next investigations.Starting contextWhy are we starting?Inception Canvascollect shared architecture assumptionsNext clarificationsWhat do we check?Problemtrigger and scopeSystem purposevalue and target...Stakeholdersroles and needsGoalsoutcome, success, scopeConstraintstime, budget, technologyQuality Attributesperformance, security, UXRisksmake uncertainty visibleArchitecture ideassketch system shapeOpen questionsplan validationADR candidatespark decisionsQAWdeepen qualitiesSpikestest assumptions1Clarify problem2Constraints3Hypotheses4Next Steps
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

architecture-inception-canvas-working-template.md

Plan a session or initiative to match the actual scope of work.

Architecture Inception Canvas: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Prepare the full method Time: 60–120 minutes with prepared participants; missing requirements or technical research are separate.

Complete this worksheet on paper or in your own document during the work.

Preparation for this scope

Method setup

  • Materials: Official canvas, business goals, communication partners, known constraints and key stakeholders.
  • Roles: Product/business · software architecture · engineering · stakeholders responsible for quality.
  • Advance information: Choose materials, data access and participants to fit the research or decision question.
  • Overall time needed: 60–120 minutes with prepared participants; missing requirements or technical research 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

System: Name system and business case

  • Use the published Architecture Inception Canvas and record system, team, workshop date and iteration.
  • Official canvas, business goals, communication partners, known constraints and key stakeholders.

Goals: Capture context and quality goals

  • Context for a greenfield inception
  • Official canvas, business goals, communication partners, known constraints and key stakeholders.

Constraints: Record constraints

  • Context diagram and quality goals
  • Official canvas, business goals, communication partners, known constraints and key stakeholders.

Hypotheses: Record hypotheses and risks

  • Traceable constraints
  • Official canvas, business goals, communication partners, known constraints and key stakeholders.

Architecture Inception Canvas fields from the published template

Business Case

Describe the business or economic driver.

...

Functional Overview

List the most important functions at high level.

...

Business Context

Show the system as a black box and its communication partners.

...

Organisational Constraints

Record organizational limits on design choices.

...

Quality Goals

Name three top quality goals from key stakeholder view.

...

Technical Constraints

Record technical limits on design choices.

...

Architectural Hypotheses

Record consequential architecture hypotheses and reasons.

...

Technical Challenges & Risks

List known technical challenges and risks.

...

Architecture Inception Canvas (official PDF)

System: Name system and business case

Expected artifact: Context for a greenfield inception

Context for a greenfield inception

Entry:

...

  • Is purpose separate from technology?

Goals: Capture context and quality goals

Expected artifact: Context diagram and quality goals

Context diagram and quality goals

Entry:

...

  • Are partners and quality expectations concrete?

Constraints: Record constraints

Expected artifact: Traceable constraints

Traceable constraints

Entry:

...

  • Is every constraint binding and verifiable?

Hypotheses: Record hypotheses and risks

Expected artifact: Hypotheses and technical challenges

Hypotheses and technical challenges

Entry:

...

  • Is a concrete check planned?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/architecture-inception-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.

architecture-inception-canvas-beispiel.md

Concrete filled scenario, fictional example

Fictional example: rental reservation

Business case: A regional rental company considers a reservation and pickup web service. The economic driver is an assumption to confirm.

Functional overview: Check availability, request a reservation, receive confirmation.

Business context: Customers and payment service communicate with the black-box system.

Quality goal: Reservation status remains understandable during concurrent requests; measurement scenario is still needed.

Constraint: Connect to the existing booking system; interface is unknown.

Hypothesis: Availability can be synchronized promptly; a spike checks freshness and outage behavior.

07

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

  1. Name system and business caseThe workshop starts with a stack debate.View in phase
  2. Capture context and quality goalsQuality wishes have no owner or scenario.View in phase
  3. Record constraintsPreference is treated as immutable.View in phase
  4. Record hypotheses and risksAn early option is treated as an approved decision.View in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

If business case, stakeholders or constraints are unknown, mark them open and assign clarification. This describes the AIC fields and is not a universal architecture standard.

Where to go next?

Paper illustration of two considered options leading to a decision record with a marked status and visible consequences.
Architecture
Architecture Decision Record

Records a named architecture hypothesis as its own decision.

Quality Attribute Workshop workspace showing the question, observations, and next decision.
Architecture
Quality Attribute Workshop

Deepens the prioritized quality goals into checkable scenarios.

View in playbookSafeguard Architecture Quality Before ImplementationMove from the guardrails of an architecture initiative through prioritized quality scenarios to a solution put up for review.

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profileMore methods