Meine Session planen

# Session Brief: arc42

## Ziel
Artefakt: Architecture Document

## Arbeitsfrage
Welche Architektur-Entscheidungen, Strukturen und Qualitätsmerkmale braucht der Leser, um das System verstehen, betreiben und weiterentwickeln zu können?

## Kontext
Aktuelle System-Übersicht; Liste der externen Schnittstellen; bekannte Qualitätsziele (möglichst aus Quality Attribute Workshop); Constraints (regulatorisch, technisch, organisatorisch); existierende Diagramme.

## Setup
- Format: Methoden-Session
- Dauer: 1-2 Tage initial, danach Pflege in 1-2 h pro Sprint
- Modus: Workshop oder async
- Teilnehmende: Ein Hauptverfasser (oft Architekt oder Tech Lead) als Owner; ein bis drei Reviewer aus Engineering und Ops; optional Stakeholder aus Business für Kapitel 1 (Ziele).
- Owner: Ein Hauptverfasser (oft Architekt oder Tech Lead) 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 Document hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
arc42-Template (Markdown-Variante von arc42/arc42-template auf GitHub); Diagramm-Tool (PlantUML, Structurizr, draw.io); Repo-Verzeichnis `docs/architecture/`; Glossar-Datei; Links auf ADR-Verzeichnis und ggf. C4-Diagramme.

## Vorbereitung
Template-Repository klonen, in `docs/architecture/` als Markdown-Struktur ablegen. Kapitel 1-12 als eigene Dateien oder eine zusammenhängende. Konvention für Diagrammeinbindung festlegen (z. B. PlantUML im Repo, gerendert beim Build).

## Agenda
1. Kapitel 1-2: Einführung, Ziele, Constraints (2-3 h)
   Owner: Facilitator
   Aktion: Aufgabenstellung in 5-10 Sätzen. Drei bis fünf Qualitätsziele in priorisierter Reihenfolge. Stakeholder-Tabelle mit Informationsbedarf. Constraints (technisch, organisatorisch, konventionell). Hinweis: Qualitätsziele müssen priorisiert sein. Wer alle Quality Attributes als „wichtig“ markiert, hat keine Entscheidungsgrundlage und das Dokument wird beliebig. 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 Document

2. Kapitel 3-4: Kontext und Lösungsstrategie (3-4 h)
   Owner: Facilitator
   Aktion: Business Context und Technical Context als Diagramm plus Tabelle. Lösungsstrategie (Architekturansatz, Top-Level-Entscheidungen, Frameworks) als 1-2-seitige Zusammenfassung. Hinweis: Kapitel 4 ist KEIN Detail-Design, sondern die Kurz-Antwort auf „wie ist das System gebaut“. Mehr als 2 Seiten ist zu viel, dann gehört es in Kapitel 5. 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: Context View

3. Kapitel 5: Bausteinsicht (3-5 h)
   Owner: Facilitator
   Aktion: Whitebox-Sicht in 2-3 Ebenen (C4-Container, C4-Component). Pro Baustein: Verantwortlichkeit, Schnittstellen, Erfüllte Anforderungen. Keine Code-Klassen. Hinweis: Nicht jeder Baustein braucht eine Whitebox. Nur die mit Komplexität oder Risiko. Sonst explodiert das Dokument und niemand liest weiter. 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: Runtime View

4. Kapitel 6-7: Laufzeitsicht und Verteilungssicht (3-4 h)
   Owner: Facilitator
   Aktion: Laufzeit: 3-5 wichtige Szenarien als Sequenzdiagramme. Verteilung: Hardware/Cloud-Topologie mit Knoten, Netzwerken, Deployment-Einheiten. Hinweis: Szenarien auswählen, die Architektur-Entscheidungen sichtbar machen (Failover, Skalierung, kritische Pfade). Happy-Path-Sequenz ist Beiwerk. 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: Deployment View

5. Kapitel 8-9: Querschnitt und Entscheidungen (2-3 h)
   Owner: Facilitator
   Aktion: Querschnittliche Konzepte (Sicherheit, Logging, Fehlerbehandlung, Persistenz). Architekturentscheidungen als Liste mit ADR-Links und kurzer Begründung. Hinweis: Konzepte konkret, nicht generisch. „Logging via ELK mit Trace-ID-Korrelation“ schlägt „Logging ist wichtig“. 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 Document

6. Kapitel 10-12: Qualität, Risiken, Glossar (2-3 h)
   Owner: Owner
   Aktion: Qualitätsszenarien (idealerweise aus QAW) tabellarisch. Technische Risiken und Schulden mit Owner und Eskalationsstand. Glossar mit Domain- und Tech-Begriffen. Hinweis: Risiken offen benennen. Eine arc42-Doku ohne Risiken-Kapitel ist Marketing-Material, kein Architekturdokument. 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: Context View

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 Document

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

# Architecture Document: arc42

## Arbeitsfrage
Welche Architektur-Entscheidungen, Strukturen und Qualitätsmerkmale braucht der Leser, um das System verstehen, betreiben und weiterentwickeln zu können?

## Kontext
Aktuelle System-Übersicht; Liste der externen Schnittstellen; bekannte Qualitätsziele (möglichst aus Quality Attribute Workshop); Constraints (regulatorisch, technisch, organisatorisch); existierende Diagramme.

## Beteiligte
- Owner: Ein Hauptverfasser (oft Architekt oder Tech Lead) als Owner
- Teilnehmende: Ein Hauptverfasser (oft Architekt oder Tech Lead) als Owner; ein bis drei Reviewer aus Engineering und Ops; optional Stakeholder aus Business für Kapitel 1 (Ziele).

## Input
arc42-Template (Markdown-Variante von arc42/arc42-template auf GitHub); Diagramm-Tool (PlantUML, Structurizr, draw.io); Repo-Verzeichnis `docs/architecture/`; Glossar-Datei; Links auf ADR-Verzeichnis und ggf. C4-Diagramme.

## Vorlage
# arc42 Arbeitsvorlage

## Ziel

Pragmatisches Template für strukturierte, lebendige Softwarearchitektur-Dokumentation.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- Architecture Document:
- Context View:
- Runtime View:
- Deployment View:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

## Fertigstellungscheck
- Architecture Document 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