Run SheetArchitectureArchitecture Workshop Canvas

Software Architecture Canvas

KomplexitätLow

Zeit1-2 h

Teilnehmende3-10

FormatWorkshop

MaturityEstablished

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenArchitecture Inception Canvas

Ein Architecture Inception Canvas oder vergleichbares Inception-Artefakt liegt vor, sodass Ziele, Stakeholder und Constraints bekannt sind.

Ohne: Ohne Inception fehlt Kontext, der Canvas startet bei Null und produziert oberflaechliche Eintraege.

Vorher abschließenQuality Attribute Workshop

Top Quality Attributes und Szenarien sind ausgearbeitet, sodass der Canvas darauf aufbauen kann.

Ohne: Ohne QA-Szenarien werden Architekturentscheidungen nicht an konkreten Anforderungen kalibriert.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Whiteboard oder Miro mit Canvas-Feldern (Kontext, Ziele, Stakeholder, Quality Attributes, Komponenten, Schnittstellen, Datenmodell, Cross-Cutting Concerns, Entscheidungen, Risiken, Roadmap); Stickies; ADR-Vorlage.

Personen / Rollen

Ein Architekt als Owner; 3-5 Teilnehmende aus Engineering, Operations, Product, Security; Scribe; Decider fuer kritische Entscheidungen.

Vorabinfos

Inception Canvas, QA-Szenarien, bestehende Systemlandschaft, Technologie-Stack, bekannte Entscheidungen aus Vorprojekten, Budget und Zeitrahmen.

Zeitbedarf

1 Tag (6-8 h)

Setup

Canvas-Felder gross sichtbar. Pro Feld 30-45 min einplanen. Regel: jeder Eintrag traegt zur Architektur-Aussage bei, kein Vollstaendigkeits-Theater.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche Komponenten, Schnittstellen, Entscheidungen und Cross-Cutting Concerns ergeben gemeinsam eine konsistente Architektur, die die Quality Attribute Szenarien erfuellt?

Ablauf

Marker: Sektion

Schritt	Dauer	Aktion	Hinweis
1Sektion 1: Kontext und Ziele	30 min	Aus Inception uebernehmen: Systemzweck, Ziele, Top-Stakeholder, Boundary. Aktualisieren falls neuer Stand.	Wenn sich seit Inception viel geaendert hat, Inception zuerst aktualisieren. Sonst bauen Canvas-Felder auf veralteten Annahmen.
2Sektion 2: Quality Attributes und Trade-offs	45 min	Top-Szenarien aus QAW uebernehmen. Pro Szenario potenzielle Trade-offs identifizieren (z. B. Performance vs. Consistency).	Trade-offs explizit machen. Ohne sie wirkt Architektur als kostenlose Loesung, was sie nicht ist.
3Sektion 3: Komponenten und Schnittstellen	90 min	Hauptkomponenten identifizieren (5-12 Stueck). Pro Komponente Verantwortung, technologie, Kommunikationsmuster (synchron, asynchron). Schnittstellen explizit.	Wenn ueber 15 Komponenten entstehen, Granularitaet zu fein. Strategische Sicht, nicht Microservice-Sammlung.
4Sektion 4: Datenmodell und Persistenz	60 min	Hauptentitaeten und Datenfluesse skizzieren. Pro Datenspeicher Persistenzmuster (relational, dokumentenbasiert, Event Store). Ownership pro Daten-Domaene.	Shared Database zwischen Komponenten ist haeufige Anti-Pattern. Wenn unvermeidlich, explizit als Risiko.
5Sektion 5: Cross-Cutting Concerns	60 min	Authentication, Authorization, Observability, Logging, Konfiguration, Tracing, Resilience-Patterns. Pro Concern Loesungsansatz und Owner.	Cross-Cutting zu spaet zu adressieren ist teurer als von Anfang. Mindestens Auth, Logging, Tracing entschieden.
6Sektion 6: Entscheidungen, Risiken, Roadmap	60 min	Top-5-Architekturentscheidungen als ADR-Stubs. Top-5-Risiken mit Mitigation. Roadmap mit Phasen (z. B. MVP, Skalierung, Internationalisierung).	Roadmap nicht zu detailliert. Hauptphasen mit Quartals-Granularitaet, Details kommen aus Sprints.

Artefakt

Was am Ende rauskommt

Form

Software Architecture Canvas mit allen Sektionen, gefuellt mit Stichpunkten, Diagrammen (C4-light), Tabellen. Ergaenzt um ADRs, Risiken-Register und Roadmap. Insgesamt 5-15 Seiten je nach Tiefe.

Tool-Alternativen

Miro mit Canvas-Template
Markdown im docs/architecture-Ordner mit Diagrammen
Confluence-Space mit Canvas-Vorlage
Structurizr fuer C4-Diagramme im Canvas
draw.io oder Lucidchart fuer Komponentendiagramme

Versionierung / Ownership

Canvas mit Datum und Version. Aenderungen mit ADR-Verlinkung. Bei groesseren Aenderungen neuer Eintrag mit Diff zur Vorperiode. Quartals-Review.

canvas

Software Architecture Canvas Arbeitsvorlage

Kompakte Arbeitsvorlage für Software Architecture Canvas mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# Software Architecture Canvas Canvas

## Kontext

Wofür wird die Methode eingesetzt?

## Kernfrage

Welche Frage soll am Ende beantwortet sein?

## Input

Welche Daten, Beobachtungen oder Materialien liegen vor?

## Arbeitsfläche

- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:

## Ergebnisartefakte
- Architecture Canvas:
- Goals:
- Constraints:
- Quality Attributes:

## Offene Fragen

- ...

## Nächster Schritt

Owner, Datum, Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

software-architecture-canvas-beispiel.md

markdown

## Software Architecture Canvas - Booking API v2 Workspot, Mai 2026

**Kontext**: Booking API als Kernservice fuer Workspot Web/Mobile und Partner-Integrationen.

**Ziele**: 5x Volumen, p95 unter 600 ms, Partner-Onboarding in 5 PT.

**Top QA-Szenarien**
- QAS-01 Performance, QAS-02 Availability, QAS-03 Security (siehe QAW-Report).

**Hauptkomponenten**
- Booking Service (Domain Core, Kotlin Spring).
- Inventory Service (existierend, REST).
- Identity Service (existierend, OAuth2 Provider).
- Notification Service (asynchron via Kafka).
- Partner Gateway (REST mit OAuth2 Client Credentials).
- Internal GraphQL Gateway (Apollo Server).

**Schnittstellen**
- Partner Gateway -> Booking Service: REST/JSON.
- Internal GraphQL -> Booking Service: gRPC.
- Booking Service -> Notification Service: Kafka topic `bookings.events`.

**Datenmodell und Persistenz**
- Booking Aggregat: Postgres (relational, transaktional).
- Booking Events: Kafka mit 7 d Retention plus EventStore-Archiv in S3.
- Read Models: Redis-Cache fuer Verfuegbarkeit (TTL 60 s).

**Cross-Cutting Concerns**
- AuthZ: OAuth2 Scopes, pro Schnittstelle dokumentiert.
- Observability: OpenTelemetry mit Datadog Backend.
- Resilience: Circuit Breaker (Resilience4j), Retry mit Backoff, Bulkheads pro Downstream.
- Konfiguration: AWS Parameter Store, Feature Flags via LaunchDarkly.

**Top-Entscheidungen (ADRs)**
- ADR-014: Multi-Region eu-central + eu-west, aktiv-aktiv (Read-Replicas).
- ADR-015: GraphQL fuer Internal, REST fuer Partner.
- ADR-016: Event Driven via Kafka, kein synchroner Notification-Aufruf.
- ADR-017: Datenresidenz EU-only, Compliance bestaetigt.
- ADR-018: Cache via Redis mit TTL 60 s, Acceptance bei Inkonsistenz.

**Risiken**
- R1: Partner-Lastspikes nicht prognostizierbar -> Rate Limit + Burst Quota.
- R2: Multi-Region-Konsistenz bei Buchung -> sticky Region pro Mandant, async Replikation.
- R3: Kafka-Operations-Reife unklar -> SRE-Spike bis 15.06.

**Roadmap**
- Q2: MVP single-region, GraphQL plus Partner Gateway.
- Q3: Multi-Region, vollstaendige Observability.
- Q4: Self-Service Partner-Sandbox.

Was tun

Pro Top-Entscheidung ADR mit Optionen und Begruendung. Canvas verlinkt ADRs.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Inception oder QAW fehlt, Canvas ohne Grundlage.

Architektur-Decider nicht im Raum, Entscheidungen bleiben unverbindlich.

Quality Attributes nicht definiert, Komponentenauswahl willkuerlich.

Workshop wird auf unter 4 h komprimiert, Tiefen-Sektionen nicht erreichbar.

Architektur ist bereits gebaut und keine Aenderung moeglich, Canvas nur Doku ohne Wert.

Bereitschaft fuer ADR-Folge fehlt, Canvas verwaist.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden