Architecture Canvas

Software Architecture Canvas

Strukturiert frühe Architekturarbeit nach Patrick Roos anhand von Goals, Solution und Assessment.

Patrick Roos’ Software Architecture Canvas strukturiert frühe Architekturarbeit über Goals, Solution und Assessment; die Originalvorlage enthält konkrete Felder wie Business Case, Functional Overview, Quality Goals, Business Context, Constraints, Architectural Hypotheses und Technical Challenges & Risks.

Kernfrage

Welcher Geschäfts- und Funktionsrahmen begrenzt den Lösungsraum, und welche Architekturhypothesen müssen geprüft werden?

Arbeit planen Methodenanleitung

Vergleich starten

Feedback gebenHilft dir diese Methode?

Teilnehmende: 3-10
Zeit: 60–120 Minuten; Recherche, Sizing und technische Spikes separat.

Welcher Geschäfts- und Funktionsrahmen begrenzt den Lösungsraum, und welche Architekturhypothesen müssen geprüft werden?

Papierillustration der Methode Software Architecture Canvas mit einer klaren Arbeitsstruktur.

Anlass
Softwareinitiative und Rahmen benennen
Fülle die Kopfzeile der Patrick-Roos-Vorlage aus und kläre Business Case vor technischen Optionsdebatten.
Ziele
Goals-Bereich der Vorlage ausarbeiten
Beschreibe Business Case und Functional Overview in der originalen Canvas-Struktur. Keine Felder aus anderen Canvas-Varianten ergänzen.
Lösungsraum
Solution-Bereich mit den Originalfeldern konkretisieren
Erfasse Functional Overview, Quality Goals, Business Context, Organizational Constraints, Technical Constraints und Architectural Hypotheses entsprechend der veröffentlichten Vorlage.
Risiken
Assessment-Teil und nächste Klärungen festlegen
Dokumentiere Technical Challenges & Risks und wichtige Architectural Hypotheses. Leite Prüfungen statt unbestätigter Entscheidungen ab.

Aktualisiere die Arbeitsunterlage, wenn neue Belege, geänderte Rahmenbedingungen oder die vereinbarte Überprüfung eine Annahme verändern.

Geeignet, wenn

Für kollaborative Architekturarbeit an einer neuen Softwareinitiative, bevor einzelne Technologieoptionen dominieren. arc42 ordnet die Vorlage als Ursprung des Architecture Inception Canvas ein; beide Namen und Varianten nicht vermischen.

Ideal für

Architecture Inception
Communication
Project Kickoffs

Nicht gut für

Langfristige Governance allein
Detaillierte Specs

Ergebnisse

Gemeinsamer Architektur-Spielraum
Die ausgefüllte Kopfzeile ordnet das Vorhaben ein. Der geklärte Business Case bildet die Grundlage für die Diskussion technischer Optionen.
Business Case und funktionaler Überblick
Das Canvas beschreibt Business Case und Functional Overview in den Feldern der Originalvorlage von Patrick Roos.
Lösungsraum und begründete Hypothesen
Der Lösungsraum enthält Functional Overview, Quality Goals, Business Context, Organizational Constraints, Technical Constraints und Architectural Hypotheses entsprechend der veröffentlichten Vorlage.
Assessment mit Risiken und nächstem Schritt
Das Assessment dokumentiert technische Herausforderungen, Risiken und wichtige Architekturhypothesen. Es benennt die Prüfungen, die für fundierte Entscheidungen noch nötig sind.

Software Architecture Canvas Felder der Originalvorlage

Fictional example

Nur die Felder der veröffentlichten Vorlage; nutze die verlinkte Fassung. Das Beispiel ist fiktiv, die Arbeitsfläche bleibt leer.

Business Case

Beschreibe Geschäftszweck oder wirtschaftlichen Treiber.

Die Plattform soll Buchungen vereinfachen; der Treiber ist noch unbestätigt.

Functional Overview

Liste die wichtigsten Funktionen auf hoher Ebene.

Verfügbarkeit ansehen, Reservierung anfragen, Bestätigung erhalten.

Quality Goals

Nenne drei priorisierte Architektur-Qualitätsziele.

Reservierungsstatus bei parallelen Anfragen verständlich halten; Messung offen.

Business Context

Trenne das System von Nutzenden und Nachbarsystemen.

Kundschaft und Zahlungsdienst liegen außerhalb.

Organisational Constraints

Erfasse Anforderungen, die Architekturspielraum einschränken.

Vorhandenen Buchungsbetrieb als mögliche Vorgabe prüfen.

Technical Constraints

Erfasse technische Anforderungen, die Optionen einschränken.

Schnittstelle des Buchungssystems ist bis zur Recherche unbekannt.

Architectural Hypotheses

Notiere wichtige oder riskante Entscheidungen mit Begründung.

Synchronisation in einem technischen Spike prüfen.

Technical Challenges & Risks

Liste aktuell bekannte technische Risiken.

Ein Timeout kann den Reservierungsstatus mehrdeutig machen.

Software Architecture Canvas by Patrick Roos, version 1.0

Erster Schritt

Verwende die verlinkte Version 1.0 von Patrick Roos als Feldreferenz; benenne Team, System, Datum und Iteration.

Zur Methodenanleitung

Wie geht es weiter?

Papierillustration mit zwei betrachteten Optionen, die zu einem Entscheidungsdokument mit markiertem Status und sichtbaren Konsequenzen führen.

Architecture

Architecture Decision Record

Hält eine dokumentierte Architectural Hypothesis als eigene Entscheidung fest.

Architecture

Quality Attribute Workshop

Vertieft die Quality Goals des Canvas zu prüfbaren Szenarien.

Vertiefung

Zweck

Die Software Architecture Canvas reduziert ein System auf die wichtigsten Architekturentscheidungen, Randbedingungen und Schnittstellen. Sie ist nützlich, wenn Teams schnell ein belastbares Gesamtbild brauchen.

Funktionsweise

Zunächst werden Ziele, Nutzer, technische Constraints und Kernbausteine gesammelt. Danach werden Abhängigkeiten, Qualitätsziele und offene Risiken sichtbar gemacht, bevor das Team die wichtigsten Architekturannahmen festhält. So entsteht ein kompaktes Bild, das Gespräche und spätere Detaillierung trägt.

Im Detail

Die Software Architecture Canvas trägt, weil sie wesentliche Architekturentscheidungen auf einer verdichteten Fläche zusammenzieht und damit frühe gemeinsame Orientierung schafft. Gute Nutzung priorisiert Kernaussagen zu Systemzweck, Strukturen, Risiken und Leitprinzipien, statt jede Box formal zu füllen. Sie ist besonders wertvoll, wenn Teams ein gemeinsames Startbild brauchen, das Diskussion lenkt und spätere Detailarbeit sinnvoll vorbereitet.

Durchführung

Gehe mit einem klaren Problemraum und wenigen harten Rahmenbedingungen hinein, damit die Verdichtung Substanz bekommt. Schärfer wird das Gespräch genau dann, wenn eine Box offenlegt, dass ein anderes Feld auf stillen Annahmen beruht. Schließe mit einem lesbaren Überblick, offenen Architekturwetten und einem klaren Übergang zu tieferer Dokumentation oder Entscheidung.

Die Methodenanleitung führt mit 4 Phasen, Zeitrahmen, 4 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Methodenanleitung öffnen

Deine Einschätzung

Hilft dir diese Methode für dein Vorhaben?

Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.

Quellen und Themen

Themen

Canvas Architektur Abstimmung Workshop

Quellen

Software Architecture Canvas by Patrick Roos, version 1.0workingsoftware.devPatrick Roos’ version 1.0 defines this specific canvas; arc42 notes that AIC is based on the original work. Field set is not generalized.Canvas overview | arc42canvas.arc42.orgPatrick Roos’ version 1.0 defines this specific canvas; arc42 notes that AIC is based on the original work. Field set is not generalized.

Artefakt-Vorlagen

Software Architecture Canvas: ArbeitsvorlagePlane die Sitzung oder das Vorhaben passend zum tatsächlichen Arbeitsumfang.

canvas

software-architecture-canvas-working-template.md

Plane die Sitzung oder das Vorhaben passend zum tatsächlichen Arbeitsumfang.

Software Architecture Canvas: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Vollständige Methode vorbereiten Zeit: 60–120 Minuten; Recherche, Sizing und technische Spikes separat.

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: Patrick Roos’ Originalvorlage, Business Case, grober Funktionsüberblick und verifizierbare Constraints.
Rollen: Product/Business · Softwarearchitektur · Engineering · wichtige Stakeholder.
Vorab-Infos: Material, Datenzugang und Teilnehmende vorab nach Forschungs- oder Entscheidungsfrage festlegen.
Gesamter Zeitbedarf: 60–120 Minuten; Recherche, Sizing und technische Spikes separat.
Setup: Arbeitsfläche mit der methodenspezifischen Struktur öffnen. Fiktive Beispiele dienen nur der Orientierung; Arbeitsvorlage und eigene Befunde bleiben getrennt.

Für die Arbeitsschritte bereitstellen

Anlass: Softwareinitiative und Rahmen benennen

Verwende die verlinkte Version 1.0 von Patrick Roos als Feldreferenz; benenne Team, System, Datum und Iteration.
Patrick Roos’ Originalvorlage, Business Case, grober Funktionsüberblick und verifizierbare Constraints.