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