Architekturqualität vor Umsetzung absichern

# Architecture Inception Canvas: Arbeitsvorlage

## Fragestellung
Noch zu klären

## Gewünschtes Ergebnis
Noch zu klären

## Rahmen
Vollständige Methode vorbereiten
Zeit: 60–120 Minuten für vorbereitete Teilnehmende; fehlende Requirements oder technische Recherche separat.

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

## Vorbereitung für diesen Umfang

### Methodische Grundausstattung
- **Materialien:** Offizielle Canvas-Vorlage, fachliche Ziele, Kommunikationspartner, bekannte Vorgaben und Zugang zu entscheidenden Stakeholdern.
- **Rollen:** Product/Business · Softwarearchitektur · Engineering · Stakeholder mit Qualitätsverantwortung; Moderation nur bei Bedarf.
- **Vorab-Infos:** Material, Datenzugang und Teilnehmende vorab nach Forschungs- oder Entscheidungsfrage festlegen.
- **Gesamter Zeitbedarf:** 60–120 Minuten für vorbereitete Teilnehmende; fehlende Requirements oder technische Recherche separat.
- **Setup:** Arbeitsfläche mit der methodenspezifischen Struktur öffnen. Fiktive Beispiele dienen nur der Orientierung; Arbeitsvorlage und eigene Befunde bleiben getrennt.

### Für die Arbeitsschritte bereitstellen

#### System: System und Anlass benennen
- Arbeite die veröffentlichte Architecture Inception Canvas aus; notiere System, Team, Workshopdatum und Iteration.
- Offizielle Canvas-Vorlage, fachliche Ziele, Kommunikationspartner, bekannte Vorgaben und Zugang zu entscheidenden Stakeholdern.

#### Ziele: Business-Kontext und Qualitätsziele erfassen
- Kontext für eine Greenfield-Inception
- Offizielle Canvas-Vorlage, fachliche Ziele, Kommunikationspartner, bekannte Vorgaben und Zugang zu entscheidenden Stakeholdern.

#### Vorgaben: Organisatorische und technische Constraints dokumentieren
- Kontextbild und priorisierte Quality Goals
- Offizielle Canvas-Vorlage, fachliche Ziele, Kommunikationspartner, bekannte Vorgaben und Zugang zu entscheidenden Stakeholdern.

#### Hypothesen: Architekturhypothesen und Risiken festhalten
- Nachvollziehbare Constraints
- Offizielle Canvas-Vorlage, fachliche Ziele, Kommunikationspartner, bekannte Vorgaben und Zugang zu entscheidenden Stakeholdern.


## Architecture Inception Canvas Felder der Originalvorlage

### Business Case
Beschreibe den geschäftlichen oder wirtschaftlichen Treiber.

...

### Functional Overview
Liste die wichtigsten Funktionen auf hoher Ebene.

...

### Business Context
Zeige das System als Black Box mit Kommunikationspartnern.

...

### Organisational Constraints
Erfasse organisatorische Grenzen für Architekturentscheidungen.

...

### Quality Goals
Nenne die drei wichtigsten Qualitätsziele aus Stakeholdersicht.

...

### Technical Constraints
Erfasse technische Anforderungen, die Entscheidungen begrenzen.

...

### Architectural Hypotheses
Notiere folgenreiche Architekturhypothesen mit Begründung.

...

### Technical Challenges & Risks
Liste bekannte technische Herausforderungen und Risiken.

...

[Architecture Inception Canvas (official PDF)](https://canvas.arc42.org/downloads/architecture-inception-canvas.pdf)


## System: System und Anlass benennen
Erwartetes Artefakt: Kontext für eine Greenfield-Inception

Kontext für eine Greenfield-Inception

Eintrag:

...

- [ ] Ist der Systemzweck von einer Lösungstechnologie getrennt?

## Ziele: Business-Kontext und Qualitätsziele erfassen
Erwartetes Artefakt: Kontextbild und priorisierte Quality Goals

Kontextbild und priorisierte Quality Goals

Eintrag:

...

- [ ] Sind Partner und Qualitätserwartungen konkret?

## Vorgaben: Organisatorische und technische Constraints dokumentieren
Erwartetes Artefakt: Nachvollziehbare Constraints

Nachvollziehbare Constraints

Eintrag:

...

- [ ] Ist jede Vorgabe tatsächlich bindend und verifizierbar?

## Hypothesen: Architekturhypothesen und Risiken festhalten
Erwartetes Artefakt: Hypothesen und technische Herausforderungen

Hypothesen und technische Herausforderungen

Eintrag:

...

- [ ] Sind offene Annahmen als Hypothesen markiert?

## Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/architecture-inception-canvas/run-sheet

# Quality Attribute Workshop: Arbeitsvorlage

## Fragestellung
Noch zu klären

## Gewünschtes Ergebnis
Noch zu klären

## Rahmen
Vollständigen Ablauf planen
Zeit: Nach Umfang und verfügbaren Belegen festlegen

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

## Vorbereitung für diesen Umfang

### Methodische Grundausstattung
- **Materialien:** Gemeinsame Arbeitsfläche, zugängliche Quellen und Notiz für Entscheidungen.
- **Rollen:** Facilitator · Stakeholder · Architektur · Scribe
- **Vorab-Infos:** Frage, Zeitraum, Datenzugriff, beteiligte Rollen und bekannte Unsicherheiten vorab klären.
- **Gesamter Zeitbedarf:** Ein ganzer moderierter Workshop; zusätzliche Stakeholdergruppen können weitere Workshops benötigen.
- **Setup:** Eine gemeinsame Version anlegen. Fakten, Annahmen und Entscheidung getrennt kennzeichnen.

### Für die Arbeitsschritte bereitstellen

#### Treiber: Treiber und Beteiligte verstehen
- Geschäftstreiber, Nutzer und Systemkontext

#### Szenarien: Qualitätsszenarien sammeln
- Stakeholderbedürfnisse und Qualitätsszenarien

#### Priorisierung: Szenarien bündeln und priorisieren
- Szenarien mit Priorisierungsgrund

#### Verfeinerung: Wichtige Szenarien verfeinern
- Verfeinerte Stimulus-Umgebung-Reaktion-Maße


## Priorisierte Qualitätsszenarien, keine fertige Architektur

### Treiber
Notiere Geschäftsziele, Systemkontext und vertretene Rollen.

...

### Szenario
Schreibe konkrete Stimulus-, Kontext- und Reaktionsszenarien.

...

### Priorität
Erfasse konsolidierte Szenarien und Priorisierungsgrund.

...

### Klärung
Ergänze Quelle, betroffene Qualität und prüfbare Reaktion.

...

Leere Vorlage: beginne mit einer abgegrenzten Frage. Trage nur erhobene Fakten ein, markiere Annahmen und halte offene Fragen sowie Quellen fest.

[Quality Attribute Workshop Collection · Software Engineering Institute](https://www.sei.cmu.edu/library/quality-attribute-workshop-collection/)


## Treiber: Treiber und Beteiligte verstehen
Erwartetes Artefakt: Konsolidierte Geschäfts- und Architekturtreiber

Konsolidierte Geschäfts- und Architekturtreiber

Eintrag:

...

- [ ] Sind wesentliche Perspektiven vertreten?

## Szenarien: Qualitätsszenarien sammeln
Erwartetes Artefakt: Qualitätsszenarien aus Stakeholderperspektiven

Qualitätsszenarien aus Stakeholderperspektiven

Eintrag:

...

- [ ] Sind Szenarien beobachtbar und kontextgebunden?

## Priorisierung: Szenarien bündeln und priorisieren
Erwartetes Artefakt: Priorisierte Szenarien mit Begründung

Priorisierte Szenarien mit Begründung

Eintrag:

...

- [ ] Sind Konflikte und Trade-offs sichtbar?

## Verfeinerung: Wichtige Szenarien verfeinern
Erwartetes Artefakt: Verfeinerte Stimulus-Umgebung-Reaktion-Messung

Verfeinerte Stimulus-Umgebung-Reaktion-Messung

Eintrag:

...

- [ ] Sind Ergebnisse nutzbar für Architektur, Prototypen oder Tests?

## Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/quality-attribute-workshop/run-sheet

# Risk Storming: Arbeitsvorlage

## Fragestellung
Noch zu klären

## Gewünschtes Ergebnis
Noch zu klären

## Rahmen
Vollständiger Durchlauf
Zeit: 90–150 Minuten für eine Architekturansicht; Maßnahmenverfolgung separat.

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

## Vorbereitung für diesen Umfang

### Methodische Grundausstattung
- **Materialien:** Aktuelle C4-/Architekturdiagramme, Qualitätsziele und Constraints, Risiko-Stickies, Evidenz, Maßnahmen- und Entscheidungslog
- **Rollen:** Architecture/Tech Lead · Entwickler:innen · Operations/Security · Domain/Product · Facilitator · Risk Owner
- **Vorab-Infos:** Architekturgrenze, aktuelle Diagrammversion, Qualitätsziele und betrachteten Betriebszustand festlegen; notwendige Perspektiven einladen.
- **Gesamter Zeitbedarf:** 90–150 Minuten für eine Architekturansicht; Maßnahmenverfolgung separat.
- **Setup:** Arbeitsfläche mit Kontext · Allein · Teilen · Einordnen · Behandeln · Review vorbereiten; Beispiel und eigene Daten trennen.

### Für die Arbeitsschritte bereitstellen

#### Kontext: Geteilte Karte
- Architekturgrenze, aktuelle Diagrammversion, Qualitätsziele und betrachteten Betriebszustand festlegen; notwendige Perspektiven einladen.
- Aktuelle C4-/Architekturdiagramme, Qualitätsziele und Constraints, Risiko-Stickies, Evidenz, Maßnahmen- und Entscheidungslog

#### Allein: Risikostickies
- Geteilte Karte

#### Teilen: Risikocluster
- Risikostickies

#### Einordnen: Prioritätsbild
- Risikocluster

#### Behandeln: Behandlungsplan
- Prioritätsbild

#### Review: Risikoentscheid
- Behandlungsplan


## Risk Storming · Arbeitsstruktur

| Risiko | Ort | Szenario | Qualitätsziel | Evidenz | Exposition | Behandlung | Owner/Review |
| --- | --- | --- | --- | --- | --- | --- | --- |
| R1 · Payment-Latenz |   |   |   |   |   |   |   |
| R2 · Retry-Sturm |   |   |   |   |   |   |   |

- **R1 · Payment-Latenz:** Evidenz und Begründung ergänzen.
- **R2 · Retry-Sturm:** Evidenz und Begründung ergänzen.

Die leere Vorlage enthält nur Arbeitsimpulse.

[Fachquelle · eigene Lehrdarstellung](https://simonbrown.je/workshops/)


## Kontext: Geteilte Karte
Erwartetes Artefakt: Geteilte Karte

Diagramm, Scope, Qualitätsziele und Annahmen gemeinsam lesen; Verständnisfragen schließen.

Eintrag:

...

- [ ] Verstehen alle Elemente, Beziehungen und kritischen Qualitätsziele gleich?

## Allein: Risikostickies
Erwartetes Artefakt: Risikostickies

Jede Person identifiziert still konkrete Risikoszenarien und verortet sie an Element oder Beziehung.

Eintrag:

...

- [ ] Enthält jeder Hinweis Auslöser, Ereignis und Auswirkung?

## Teilen: Risikocluster
Erwartetes Artefakt: Risikocluster

Hinweise nacheinander erklären, Duplikate clustern und unterschiedliche Perspektiven erhalten.

Eintrag:

...

- [ ] Bleiben unabhängige Szenarien getrennt und gemeinsame Ursachen sichtbar?

## Einordnen: Prioritätsbild
Erwartetes Artefakt: Prioritätsbild

Exposition qualitativ aus plausibler Eintrittslage und Konsequenz begründen; Evidenz und Unbekanntes markieren.

Eintrag:

...

- [ ] Ist hohe Exposition mit Szenario und Evidenz begründet statt aus Punkten errechnet?

## Behandeln: Behandlungsplan
Erwartetes Artefakt: Behandlungsplan

Für wesentliche Risiken vermeiden, reduzieren, übertragen oder akzeptieren; Experiment/ADR und Owner setzen.

Eintrag:

...

- [ ] Hat jede Maßnahme erwartete Risikowirkung und Nachweis?

## Review: Risikoentscheid
Erwartetes Artefakt: Risikoentscheid

Rest-Risiko abnehmen, Diagramm/ADR aktualisieren und Trigger für erneutes Risk Storming festlegen.

Eintrag:

...

- [ ] Ist Akzeptanz durch befugten Owner und mit Reviewdatum dokumentiert?

## Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/risk-storming/run-sheet

# Request for Comments: Arbeitsvorlage

## Fragestellung
Noch zu klären

## Gewünschtes Ergebnis
Noch zu klären

## Rahmen
Praxis einrichten und überprüfen
Zeit: 2–10 Arbeitstage je Tragweite

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

## Vorbereitung für diesen Umfang

### Methodische Grundausstattung
- **Materialien:** Problem und Constraints, Designentwurf und Alternativen, Reviewer und Decision Owner, gemeinsame Arbeitsfläche, Quellenlinks und Entscheidungslog.
- **Rollen:** Author · Reviewers · Decision Owner · affected implementers
- **Vorab-Infos:** Problem und Constraints, Designentwurf und Alternativen, Reviewer und Decision Owner vorab zusammentragen und offene Annahmen markieren.
- **Gesamter Zeitbedarf:** 2–10 Arbeitstage je Tragweite
- **Setup:** versionierter Vorschlag mit offener Reviewfrist, adressierten Kommentaren und explizitem Status sichtbar vorbereiten und Bewertungsbegriffe vor Beginn kalibrieren.

### Für die Arbeitsschritte bereitstellen

#### Draft: Draft
- Problem und Constraints
- Designentwurf und Alternativen
- Reviewer und Decision Owner

#### Review: Review
- RFC Draft
- Designentwurf und Alternativen
- Reviewer und Decision Owner

#### Decision: Decision
- Review Record
- Designentwurf und Alternativen
- Reviewer und Decision Owner

#### Lifecycle: Lifecycle
- RFC Decision
- Designentwurf und Alternativen
- Reviewer und Decision Owner


## RFC Record

### Problem/Goals
Festzuhaltende Problem/Goals-Angaben

...

### Proposal/Alternatives
Festzuhaltende Proposal/Alternatives-Angaben

...

### Review/Decision
Festzuhaltende Review/Decision-Angaben

...

### Migration/Status
Festzuhaltende Migration/Status-Angaben

...

Nur reale Angaben, Quellen und Entscheidungen eintragen.

[IETF RFC 2026: The Internet Standards Process](https://www.rfc-editor.org/rfc/rfc2026)


## Draft: Draft
Erwartetes Artefakt: RFC Draft

RFC Draft · Quelle · Unsicherheit · nächster Entscheid

Eintrag:

...

- [ ] Sind Trade-offs statt nur Vorteile enthalten?

## Review: Review
Erwartetes Artefakt: Review Record

Review Record · Quelle · Unsicherheit · nächster Entscheid

Eintrag:

...

- [ ] Sind Security, Operations und Consumer vertreten?

## Decision: Decision
Erwartetes Artefakt: RFC Decision

RFC Decision · Quelle · Unsicherheit · nächster Entscheid

Eintrag:

...

- [ ] Ist jeder wesentliche Einwand beantwortet?

## Lifecycle: Lifecycle
Erwartetes Artefakt: RFC Lifecycle

RFC Lifecycle · Quelle · Unsicherheit · nächster Entscheid

Eintrag:

...

- [ ] Spiegelt Status den realen Stand?

## Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/rfc/run-sheet