Meine Session planen

# Session Brief: Software Architecture Canvas

## Ziel
Artefakt: Architecture Canvas

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

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

## Setup
- Format: Methoden-Session
- Dauer: 1 Tag (6-8 h)
- Modus: Workshop
- Teilnehmende: Ein Architekt als Owner; 3-5 Teilnehmende aus Engineering, Operations, Product, Security; Scribe; Decider fuer kritische Entscheidungen.
- Owner: Ein Architekt als Owner
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Architecture Canvas hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

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

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

## Agenda
1. Sektion 1: Kontext und Ziele (30 min)
   Owner: Facilitator
   Aktion: Aus Inception uebernehmen: Systemzweck, Ziele, Top-Stakeholder, Boundary. Aktualisieren falls neuer Stand. Hinweis: Wenn sich seit Inception viel geaendert hat, Inception zuerst aktualisieren. Sonst bauen Canvas-Felder auf veralteten Annahmen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Architecture Canvas

2. Sektion 2: Quality Attributes und Trade-offs (45 min)
   Owner: Facilitator
   Aktion: Top-Szenarien aus QAW uebernehmen. Pro Szenario potenzielle Trade-offs identifizieren (z. B. Performance vs. Consistency). Hinweis: Trade-offs explizit machen. Ohne sie wirkt Architektur als kostenlose Loesung, was sie nicht ist. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Goals

3. Sektion 3: Komponenten und Schnittstellen (90 min)
   Owner: Facilitator
   Aktion: Hauptkomponenten identifizieren (5-12 Stueck). Pro Komponente Verantwortung, technologie, Kommunikationsmuster (synchron, asynchron). Schnittstellen explizit. Hinweis: Wenn ueber 15 Komponenten entstehen, Granularitaet zu fein. Strategische Sicht, nicht Microservice-Sammlung. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Constraints

4. Sektion 4: Datenmodell und Persistenz (60 min)
   Owner: Facilitator
   Aktion: Hauptentitaeten und Datenfluesse skizzieren. Pro Datenspeicher Persistenzmuster (relational, dokumentenbasiert, Event Store). Ownership pro Daten-Domaene. Hinweis: Shared Database zwischen Komponenten ist haeufige Anti-Pattern. Wenn unvermeidlich, explizit als Risiko. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Quality Attributes

5. Sektion 5: Cross-Cutting Concerns (60 min)
   Owner: Facilitator
   Aktion: Authentication, Authorization, Observability, Logging, Konfiguration, Tracing, Resilience-Patterns. Pro Concern Loesungsansatz und Owner. Hinweis: Cross-Cutting zu spaet zu adressieren ist teurer als von Anfang. Mindestens Auth, Logging, Tracing entschieden. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Architecture Canvas

6. Sektion 6: Entscheidungen, Risiken, Roadmap (60 min)
   Owner: Owner
   Aktion: Top-5-Architekturentscheidungen als ADR-Stubs. Top-5-Risiken mit Mitigation. Roadmap mit Phasen (z. B. MVP, Skalierung, Internationalisierung). Hinweis: Roadmap nicht zu detailliert. Hauptphasen mit Quartals-Granularitaet, Details kommen aus Sprints. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Goals

7. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Architecture Canvas

## Abschluss
- Ergebnisartefakt aktualisieren: Architecture Canvas
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Architecture Canvas: Software Architecture Canvas

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

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

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

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

## Vorlage
# 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.

## Fertigstellungscheck
- Architecture Canvas ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren