Was vorher fertig sein muss
Ein konkreter Anlass fuer Architekturarbeit existiert (neues System, groesserer Umbau, Plattformstart), idealerweise mit Business-Sponsor.
Wesentliche Stakeholder fuer das System sind identifiziert, sodass Ziele, Constraints und Quality Attributes von der richtigen Seite kommen.
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit Canvas-Feldern (Ziele, Stakeholder, Constraints, Risiken, Quality Attributes, Systemgrenze, externe Schnittstellen, Annahmen, naechste Schritte); Stickies; Vorlage fuer ADR-Stub.
Ein Architekt als Owner; 3-6 Teilnehmende aus Engineering, Product, Operations, Security; ein Facilitator (kann der Architekt sein, idealerweise extern); Scribe.
Business-Goal des Systems; relevante Geschaeftsanforderungen; bestehende technische Landschaft; bekannte Constraints (Budget, Zeit, Technologie, Compliance); aehnliche Systeme als Referenz.
3-4 h
Canvas an die Wand. Pro Feld eine kurze Erklaerung. Regel: Felder nacheinander befuellen, nicht parallel. Fokus auf 10-Pages-Architektur, kein 100-Folien-Werk.
Die eine Frage, die diese Methode beantwortet
Welche minimale Architekturentscheidung deckt die Ziele, Constraints und Stakeholder-Anforderungen ab, ohne Optionen verfrueht zu schliessen?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Ziele und Systemzweck | 20 min | Zweck des Systems in 2-3 Saetzen. Top-3-Business-Ziele und ihre Messgroessen. Was wird sich aendern, wenn das System lebt. | Wenn Ziele nur „bessere Architektur“ sind, kommen sie aus dem Engineering. Geschaeftliche Outcomes einfordern. |
2Phase 2: Stakeholder und Quality Attributes | 30 min | Stakeholder als Liste mit Hauptanforderungen. Aus den Anforderungen die wichtigsten Quality Attributes ableiten (Performance, Availability, Security, Modifiability, etc.). | Wenn alle Quality Attributes High sind, war die Priorisierung nicht ernst. Forced Ranking durch Decider. |
3Phase 3: Systemgrenze und Schnittstellen | 30 min | Was ist im System (Boundary), was ist Umgebung. Externe Schnittstellen (Konsumenten, Lieferanten, Datenquellen) auflisten. | Klare Grenzen verhindern Scope Creep. Wenn Grenzen unscharf, oft auch Anforderungen unscharf. |
4Phase 4: Constraints, Risiken, Annahmen | 30 min | Constraints (Technik, Budget, Zeit, Compliance), Risiken (technisch, organisatorisch, Business), Annahmen explizit auflisten. Annahmen markieren, die fuer Architektur kritisch sind. | Annahmen sind oft die Stelle, wo Architekturen scheitern. Explizit halten und mit Datum/Verantwortlichen versehen, sodass sie revisit werden koennen. |
5Phase 5: Naechste Schritte und ADR-Stubs | 30 min | Top-3-Architekturentscheidungen identifizieren, die als ADR ausgearbeitet werden. Naechste Workshops (z. B. QAW, Software Architecture Canvas) terminieren. Owner pro Stub. | Canvas ist Inception, kein Endprodukt. Naechste Schritte muessen explizit terminiert sein, sonst verschwindet das Artefakt. |
Was am Ende rauskommt
Architecture Inception Canvas als Bild plus Markdown mit allen Feldern, gefuellt mit Stichpunkten, Tabellen und kurzen Erlaeuterungen. Ergaenzt um ADR-Stubs und Liste der naechsten Workshops.
Canvas mit Datum und Version. Aenderungen mit Begruendung. Bei groesseren Aenderungen neuer Eintrag, Vorgaenger archivieren. ADR-Stubs verlinken.
Kompakte Arbeitsvorlage für Architecture Inception Canvas mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Architecture Inception 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
- Inception Canvas:
- Risks:
- Goal List:
- Open Questions:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## Architecture Inception Canvas - Workspot Booking API v2, Mai 2026
**Systemzweck**: Buchungs-API, die Workspot- und Partner-Plattformen mit konsistenten Verfuegbarkeits- und Buchungsdaten versorgt.
**Ziele**
- 5x Buchungsvolumen in 12 Monaten skalierbar.
- Partner-Integration in unter 5 Personentagen pro Partner.
- p95 unter 300 ms fuer Suche, unter 600 ms fuer Buchung.
**Stakeholder und Top-Anforderungen**
- Internal Web/Mobile: niedrige Latenz, GraphQL bevorzugt.
- Partner: REST mit OAuth2, Sandbox-Umgebung.
- Compliance: GDPR Datenresidenz EU.
- SRE: Mehrregionen-HA, RPO 5 min.
**Quality Attributes (priorisiert)**
1. Availability (99.95% SLA)
2. Performance (siehe Ziele)
3. Modifiability (Partner-Onboarding)
4. Security (OAuth2, Rate Limiting)
5. Observability
**Systemgrenze**: Booking API plus Datenstores. Auth-Service extern. Notification-Service extern.
**Externe Schnittstellen**
- Identity Service (REST)
- Payment Provider (Webhook)
- Workspace-Owner App (GraphQL)
- Partner-API-Clients (REST mit OAuth2)
**Constraints**
- Cloud-Provider AWS, Region eu-central-1.
- Bestehende Datenbank Postgres 14, Migration in Phase 2.
- Budget Phase 1: 350k EUR.
**Risiken**
- Partner-Volumen-Spike bei Launch nicht prognostizierbar.
- Bestehende Coupling zur Inventory-Service-DB verhindert Multi-Region.
**Annahmen**
- Partner halten Rate Limit ein. Revisit bis 30.07.
- Auth-Service kann horizontal skaliert werden. Owner @marcus, validieren bis 15.06.
**Naechste Schritte**
- Quality Attribute Workshop am 25.05.
- Software Architecture Canvas am 02.06.
- ADR-014 Mehrregionen-Strategie, Owner @lisa.
- ADR-015 GraphQL vs. REST Internal, Owner @ben.Symptome erkennen, gegensteuern
Felder werden zu Mini-Dokumenten mit Detaildiagrammen.
Canvas ist Inception, jeder Eintrag in 1-3 Stichpunkten. Details in Folgedokumenten (ADR, SAC). Disziplin durch Facilitator.
Diskussion baut auf ungenannten Annahmen, die spaeter platzen.
Annahmen-Feld zwingend ausfuellen. Pro Annahme Validierungs-Owner und Datum. Bei kritischer Unsicherheit Spike planen.
Architekt kommt mit fertigem Bild, Workshop ist Show.
Optionen offen halten, mindestens zwei Alternativen pro Top-Entscheidung diskutieren. Canvas dient Optionenoffenheit.
Canvas ist gefuellt, nichts wird entschieden, Architekturarbeit stockt.
Top-3-Entscheidungen identifizieren, ADR-Stubs anlegen, Owner und Frist. Ohne diesen Schritt kein Canvas-Abschluss.
Nur Engineering im Raum, Quality Attributes nur technisch.
Mindestens Product, Operations und Security vertreten. Wenn nicht moeglich, separate Interviews vor Workshop und Ergebnisse mitbringen.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.