Vorher abschließenKlarer Arbeitsrahmen
Verwende die verlinkte Version 1.0 von Patrick Roos als Feldreferenz; benenne Team, System, Datum und Iteration.
Ohne abgegrenzte Frage oder prüfbare Belege wird das Ergebnis unscharf.
MethodenanleitungArchitecture
Software Architecture Canvas
Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.
KomplexitätNiedrig
Zeit1-2 h
Teilnehmende3-10
FormatWorkshop
ReifegradEstablished
01
Vorbedingung
Was vorher fertig sein muss
02
Vorbereitung
Was vor Start vorliegen muss
Materialien
Patrick Roos’ Originalvorlage, Business Case, grober Funktionsüberblick und verifizierbare Constraints.
Personen / Rollen
Product/Business · Softwarearchitektur · Engineering · wichtige Stakeholder.
Vorabinfos
Material, Datenzugang und Teilnehmende vorab nach Forschungs- oder Entscheidungsfrage festlegen.
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.
03
Kernfrage
Die eine Frage, die diese Methode beantwortet
Welcher Geschäfts- und Funktionsrahmen begrenzt den Lösungsraum, und welche Architekturhypothesen müssen geprüft werden?
04
Ablauf
Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle
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.
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.
- 1
Anlass
Softwareinitiative und Rahmen benennen
Ziel
Gemeinsamer Architektur-Spielraum
Voraussetzungen für diesen Schritt
- 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.
Durchführung
- Fülle die Kopfzeile der Patrick-Roos-Vorlage aus und kläre Business Case vor technischen Optionsdebatten.
- Das Ergebnis „Gemeinsamer Architektur-Spielraum“ mit Belegstatus, Quelle oder offenem Prüfbedarf festhalten.
Ergebnis
Gemeinsamer Architektur-Spielraum
Gemeinsamer Architektur-Spielraum
Qualitätscheck
Verstehen Teammitglieder den Zweck des Vorhabens?
Stolperfalle
Technologiewahl beginnt ohne bekannten Geschäftstreiber. Erst Business Case und funktionalen Überblick klären.
Zeitlicher Rahmen: Etwa 10–20 Minuten; Daten- oder Klärungsarbeit separat planen.
- 2
Ziele
Goals-Bereich der Vorlage ausarbeiten
Ziel
Business Case und funktionaler Überblick
Voraussetzungen für diesen Schritt
- Gemeinsamer Architektur-Spielraum
- Patrick Roos’ Originalvorlage, Business Case, grober Funktionsüberblick und verifizierbare Constraints.
Durchführung
- Beschreibe Business Case und Functional Overview in der originalen Canvas-Struktur. Keine Felder aus anderen Canvas-Varianten ergänzen.
- Das Ergebnis „Business Case und funktionaler Überblick“ mit Belegstatus, Quelle oder offenem Prüfbedarf festhalten.
Ergebnis
Business Case und funktionaler Überblick
Business Case und funktionaler Überblick
Qualitätscheck
Sind gewünschte Ergebnisse aus Fachsicht nachvollziehbar?
Stolperfalle
Allgemeine Vision ersetzt den Kernnutzen. Auf eine überprüfbare Nutzungs- oder Geschäftsfrage verdichten.
Zeitlicher Rahmen: Etwa 10–20 Minuten; Daten- oder Klärungsarbeit separat planen.
- 3
Lösungsraum
Solution-Bereich mit den Originalfeldern konkretisieren
Ziel
Lösungsraum und begründete Hypothesen
Voraussetzungen für diesen Schritt
- Business Case und funktionaler Überblick
- Patrick Roos’ Originalvorlage, Business Case, grober Funktionsüberblick und verifizierbare Constraints.
Durchführung
- Erfasse Functional Overview, Quality Goals, Business Context, Organizational Constraints, Technical Constraints und Architectural Hypotheses entsprechend der veröffentlichten Vorlage.
- Das Ergebnis „Lösungsraum und begründete Hypothesen“ mit Belegstatus, Quelle oder offenem Prüfbedarf festhalten.
Ergebnis
Lösungsraum und begründete Hypothesen
Lösungsraum und begründete Hypothesen
Qualitätscheck
Sind Quality Goals stakeholderbezogen und Constraints belegt?
Stolperfalle
Canvas wird mit willkürlich ergänzten Feldern vermischt. Originalvorlage beibehalten; Annahmen und Belege getrennt markieren.
Zeitlicher Rahmen: Etwa 10–20 Minuten; Daten- oder Klärungsarbeit separat planen.
- 4
Risiken
Assessment-Teil und nächste Klärungen festlegen
Ziel
Assessment mit Risiken und nächstem Schritt
Voraussetzungen für diesen Schritt
- Lösungsraum und begründete Hypothesen
- Patrick Roos’ Originalvorlage, Business Case, grober Funktionsüberblick und verifizierbare Constraints.
Durchführung
- Dokumentiere Technical Challenges & Risks und wichtige Architectural Hypotheses. Leite Prüfungen statt unbestätigter Entscheidungen ab.
- Das Ergebnis „Assessment mit Risiken und nächstem Schritt“ mit Belegstatus, Quelle oder offenem Prüfbedarf festhalten.
Ergebnis
Assessment mit Risiken und nächstem Schritt
Assessment mit Risiken und nächstem Schritt
Qualitätscheck
Führt die Einschätzung zu einer prüfbaren nächsten Entscheidung?
Stolperfalle
Ein Canvas-Eintrag wird als endgültige Architekturentscheidung gelesen. Status, Verantwortliche und Validierungstermin hinzufügen; Entscheidung später separat festhalten.
Zeitlicher Rahmen: Etwa 10–20 Minuten; Daten- oder Klärungsarbeit separat planen.
05
Artefakt
Was am Ende rauskommt
Skizze: so sieht das Artefakt aus
Form
Versionierte Dokumentation mit Frage, Evidenz, Ergebnis, Unsicherheit, Verantwortlichen und nächstem Prüftermin.
Versionierung / Ownership
Datum, Scope, Quelle, Annahmen und Änderungen nachhalten; bei Praxis oder Vorhaben eine verantwortliche Person und Überprüfung festlegen.
Tool-Alternativen
- Papier und Stifte
- Whiteboard oder einfache Tabelle
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.
Ziele: Goals-Bereich der Vorlage ausarbeiten
- Gemeinsamer Architektur-Spielraum
- Patrick Roos’ Originalvorlage, Business Case, grober Funktionsüberblick und verifizierbare Constraints.
Lösungsraum: Solution-Bereich mit den Originalfeldern konkretisieren
- Business Case und funktionaler Überblick
- Patrick Roos’ Originalvorlage, Business Case, grober Funktionsüberblick und verifizierbare Constraints.
Risiken: Assessment-Teil und nächste Klärungen festlegen
- Lösungsraum und begründete Hypothesen
- Patrick Roos’ Originalvorlage, Business Case, grober Funktionsüberblick und verifizierbare Constraints.
Software Architecture Canvas Felder der Originalvorlage
Business Case
Beschreibe Geschäftszweck oder wirtschaftlichen Treiber.
...
Functional Overview
Liste die wichtigsten Funktionen auf hoher Ebene.
...
Quality Goals
Nenne drei priorisierte Architektur-Qualitätsziele.
...
Business Context
Trenne das System von Nutzenden und Nachbarsystemen.
...
Organisational Constraints
Erfasse Anforderungen, die Architekturspielraum einschränken.
...
Technical Constraints
Erfasse technische Anforderungen, die Optionen einschränken.
...
Architectural Hypotheses
Notiere wichtige oder riskante Entscheidungen mit Begründung.
...
Technical Challenges & Risks
Liste aktuell bekannte technische Risiken.
...
Software Architecture Canvas by Patrick Roos, version 1.0
Anlass: Softwareinitiative und Rahmen benennen
Erwartetes Artefakt: Gemeinsamer Architektur-Spielraum
Gemeinsamer Architektur-Spielraum
Eintrag:
...
- Verstehen Teammitglieder den Zweck des Vorhabens?
Ziele: Goals-Bereich der Vorlage ausarbeiten
Erwartetes Artefakt: Business Case und funktionaler Überblick
Business Case und funktionaler Überblick
Eintrag:
...
- Sind gewünschte Ergebnisse aus Fachsicht nachvollziehbar?
Lösungsraum: Solution-Bereich mit den Originalfeldern konkretisieren
Erwartetes Artefakt: Lösungsraum und begründete Hypothesen
Lösungsraum und begründete Hypothesen
Eintrag:
...
- Sind Quality Goals stakeholderbezogen und Constraints belegt?
Risiken: Assessment-Teil und nächste Klärungen festlegen
Erwartetes Artefakt: Assessment mit Risiken und nächstem Schritt
Assessment mit Risiken und nächstem Schritt
Eintrag:
...
- Führt die Einschätzung zu einer prüfbaren nächsten Entscheidung?
Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/software-architecture-canvas/run-sheet
06
Beispielausgabe
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.
software-architecture-canvas-beispiel.md
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Beispiel: Verleihplattform
Business Case: Die Plattform soll Reservierung und Abholung erleichtern. Der wirtschaftliche Treiber ist im Beispiel unbestätigt.
Functional Overview: Verfügbarkeit ansehen, Reservierung anfragen, Bestätigung erhalten.
Quality Goal: Status bei parallelen Anfragen nachvollziehbar halten; Messszenario muss das Betriebsteam definieren.
Business Context: Kundschaft und Zahlungsdienst.
Constraints: Anschluss an bestehendes Buchungssystem als zu bestätigende Vorgabe.
Architectural Hypothesis: Synchronisation ist praktikabel; ein Spike prüft Konfliktbehandlung.
Technical Challenge/Risk: Timeout könnte den Reservierungsstatus unklar lassen.
07
Stolperfallen
Symptome erkennen, gegensteuern
Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf
- Softwareinitiative und Rahmen benennenTechnologiewahl beginnt ohne bekannten Geschäftstreiber.In der Phase ansehen
- Goals-Bereich der Vorlage ausarbeitenAllgemeine Vision ersetzt den Kernnutzen.In der Phase ansehen
- Solution-Bereich mit den Originalfeldern konkretisierenCanvas wird mit willkürlich ergänzten Feldern vermischt.In der Phase ansehen
- Assessment-Teil und nächste Klärungen festlegenEin Canvas-Eintrag wird als endgültige Architekturentscheidung gelesen.In der Phase ansehen
Falle
Softwareinitiative und Rahmen benennen
Symptom
Technologiewahl beginnt ohne bekannten Geschäftstreiber.
Was tun
Erst Business Case und funktionalen Überblick klären.
Falle
Goals-Bereich der Vorlage ausarbeiten
Symptom
Allgemeine Vision ersetzt den Kernnutzen.
Was tun
Auf eine überprüfbare Nutzungs- oder Geschäftsfrage verdichten.
Falle
Solution-Bereich mit den Originalfeldern konkretisieren
Symptom
Canvas wird mit willkürlich ergänzten Feldern vermischt.
Was tun
Originalvorlage beibehalten; Annahmen und Belege getrennt markieren.
Falle
Assessment-Teil und nächste Klärungen festlegen
Symptom
Ein Canvas-Eintrag wird als endgültige Architekturentscheidung gelesen.
Was tun
Status, Verantwortliche und Validierungstermin hinzufügen; Entscheidung später separat festhalten.
08
Abbruchkriterien
Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest
Die Feldstruktur stammt aus Roos’ veröffentlichter Originalvorlage. arc42 nennt AIC als weitergeführte Greenfield-Variante. Felder nicht mit ACC oder einem selbst entworfenen Universal-Canvas austauschen.
Methodenanleitung durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.