methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session1-2 Tage initial, danach Pflege in 1-2 h pro SprintWorkshop oder asyncArchitecture Document

Session: arc42

Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Automatisch abgeleitet

Methoden-Session mit 1-4. Der Plan nutzt die vorhandene Methodenlogik und das Runsheet.

Runsheet
Beteiligungslogik
Teamrunde, gemeinsames Arbeiten und Alignment

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

Ergebnislogik
Artefakt fertigstellen

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

  1. 1

    Kapitel 1-2: Einführung, Ziele, Constraints

    2-3 h

    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.

    FacilitatorArchitecture Document
  2. 2

    Kapitel 3-4: Kontext und Lösungsstrategie

    3-4 h

    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.

    FacilitatorContext View
  3. 3

    Kapitel 5: Bausteinsicht

    3-5 h

    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.

    FacilitatorRuntime View
  4. 4

    Kapitel 6-7: Laufzeitsicht und Verteilungssicht

    3-4 h

    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.

    FacilitatorDeployment View
  5. 5

    Kapitel 8-9: Querschnitt und Entscheidungen

    2-3 h

    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“.

    FacilitatorArchitecture Document
  6. 6

    Kapitel 10-12: Qualität, Risiken, Glossar

    2-3 h

    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.

    OwnerContext View
  7. 7

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerArchitecture Document
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

session-brief.md

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. 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. 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. 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. 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“. 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. 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.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

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 Runsheets.

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
Vorlagenbasis

arc42 Arbeitsvorlage

Vorlage ansehenKompakte Arbeitsvorlage für arc42 mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
markdown

arc42-working-template.md

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

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 Runsheets.

Ergebnisartefakte

  • Architecture Document:
  • Context View:
  • Runtime View:
  • Deployment View:

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Architecture Document.
  • Doku versioniert im selben Repo wie der Code. Änderungen via Pull Request mit Architektur-Reviewer. Releases der Doku gekoppelt an System-Releases (Tag), sodass jede Code-Version eine passende Doku hat.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet