![art.svg](/annotations/asset/1180)
![art.png](/annotations/asset/1181)

# QS-Checkliste für Praktiken und Anforderungen im Grundschutz++

## Einleitung
ℹ️ Diese Checkliste bildet einen vollständigen QS-Prozess für Praktiken und deren Anforderungen im Grundschutz++ ab – von der konzeptionellen Überprüfung bis zur technischen/formalen Dokumentation und Nachverfolgbarkeit.

ℹ️ Die Checkliste kann sowohl für eine Community-QS des Grundschutzes++ als auch für eigene/ergänzende Praktiken und Anforderungen einer Organisation oder anderer Standards in der Informationssicherheit verwendet werden, sofern diese im [OSCAL-Format](https://wiki.isms-ratgeber.info/wiki/OSCAL "OSCAL") mit den zukünftigen ISMS-Tools verarbeitet werden sollen.

## Überprüfung der Praktik als Ganzes

### 1. Vollständigkeitsprüfung
✅ Ist sichergestellt, dass alle relevanten Aspekte der Praktik in expliziten Anforderungen abgebildet werden (Prozesse, Zielobjekte, Modalverben, Ereignisse, Maßnahmen)?

✅ Wurden aktuelle Technologien oder Bedrohungslagen (z. B. Cloud, KI, IoT) sowie organisatorische, technische und personelle Aspekte berücksichtigt?

✅ Decken die Anforderungen verschiedene Schutzbedarfsszenarien (Basis, Standard, erhöhter Bedarf) ab?

### 2. Redundanz- und Konsistenzprüfung
⚠️ Gibt es Dopplungen oder widersprüchliche Anforderungen innerhalb der Praktik oder im Vergleich zu anderen Praktiken?

⚠️ Ist die Zuordnung der Anforderungen zu Praktik und Zielobjekt logisch und konsistent?

### 3. Abdeckung der Schutzziele
🔒 Sind Vertraulichkeit, Integrität und Verfügbarkeit durch die Anforderungen angemessen adressiert?

📊 Sind die jeweiligen Leistungskennzahlen plausibel und nachvollziehbar verteilt?

## QS der einzelnen Anforderungen der Praktik

### 1. Formale Prüfung nach Satzschablone
📋 Entspricht die Beschreibung der Anforderung der Vorgabe (Praktik, Zielobjekt, Modalverb, Ereignis, Handlungswort, Tags, Hinweise)?

🔗 Ist das Modalverb korrekt gesetzt und spiegelt die gewünschte Verbindlichkeit (MUSS/SOLLTE/KANN) angemessen wider?

✅ Sind alle Pflichtfelder (z. B. Zielobjekt, Handlungswort) eindeutig ausgefüllt?

🏷️ Sind Tags und Hinweise sinnvoll und helfen sie bei der Einordnung?

### 2. Inhaltsprüfung
📝 Ist die Anforderung klar, prägnant und widerspruchsfrei formuliert?

🎯 Ist deren Sinnhaftigkeit für die jeweilige Praktik nachvollziehbar begründet?

⚖️ Spiegelt sie aktuelle regulatorische/technische Anforderungen und bekannte gute Praxis wider?

👥 Wurde bei der Erstellung auf die Community-Reviews und gängige Umsetzungsbeispiele Bezug genommen?

### 3. Plausibilitätsprüfung
🧩 Ist die Anforderung generell umsetzbar, auch für Organisationen unterschiedlicher Größe/Komplexität?

⚖️ Passt das ausgewählte Modalverb zur tatsächlichen Kritikalität und zum Risiko?

📊 Sind die Leistungskennzahlen in Bezug auf die Schutzziele angemessen gesetzt?

### 4. Verständlichkeit und Nachvollziehbarkeit
🧾 Ist die Anforderung für Dritte eindeutig verständlich (kein Interpretationsspielraum, keine Mehrdeutigkeiten)?

🎯 Wird die Zielgruppe adressatengerecht angesprochen?

🏷️ Unterstützen Tags und Hinweise die Anwendung?

### 5. Prüfbarkeit und Nachweisbarkeit
🔍 Ist objektiv überprüfbar, ob die Anforderung erfüllt ist (z. B. durch Dokumentation, Test, Audit, Kontrollmechanismus)?

📈 Ist erkennbar, wie der Erfüllungsgrad anhand von Leistungskennzahlen ermittelt werden kann?

🚧 Gibt es klare Abgrenzungskriterien zu benachbarten Anforderungen?

### 6. Sinnhaftigkeit und Zweckmäßigkeit
🎯 Trägt die Anforderung messbar zur Erreichung der Schutzziele und Praktikziele bei?

💡 Gibt es einen erkennbaren Mehrwert der Anforderung außerhalb reiner Regelerfüllung?

⚠️ Vermeidet die Anforderung einen unnötigen Mehraufwand („Overengineering“)?

## Nachbearbeitung und Monitoring
📚 Sind die Reviews und Korrekturen der Community dokumentiert und eingepflegt?

📝 Wurde für die Anforderung ein Änderungs- und Versionsverlauf festgehalten?

✅ Ist die Anforderung mit einer QSV-Freigabe versehen (inkl. Autor/in, Prüfer/in, Datum der letzten Prüfung)?

## Demo annotation — STM.2.1.4

**Modellierung der Anforderungen mit Zielobjektkategorie** (MUSS)

- Practice: Strukturmodellierung → Anforderungspaket
- Security level: normal-SdT
- Effort level: 0

> Strukturmodellierung MUSS die den Zielobjektkategorien zugehörigen Anforderungen auf die zugewiesenen Assets modellieren.


![around_the_world.svg](/annotations/asset/1182)
![around_the_world.png](/annotations/asset/1183)

---
date: Juli 2025
title: "![arc42](images/arc42-logo.png) Template"
---

# <System Name> Architekturdokumentation

**Über arc42**

ℹ️ arc42 ist das Template zur Dokumentation von Software- und  
Systemarchitekturen.

Template Version 9.0-DE (basiert auf AsciiDoc), Juli 2025.

Created, maintained and © by  
Dr. Peter Hruschka, Dr. Gernot Starke und Contributors.  
Siehe <https://arc42.org>.

:::: note
::: title
Diese Version enthält Hilfen und Erläuterungen.
:::

ℹ️ Diese Version dient der Einarbeitung in arc42  
und dem Verständnis der Konzepte.  
Für eigene Systeme verwenden Sie besser die *plain* Version.
::::

# Einführung und Ziele {#section-introduction-and-goals}

🧩 Beschreibt die wesentlichen Anforderungen und treibenden Kräfte,  
die bei Umsetzung der Softwarearchitektur und Entwicklung berücksichtigt  
werden müssen.

Dazu gehören:

- zugrunde liegende Geschäftsziele  
- wesentliche Aufgabenstellungen  
- wesentliche funktionale Anforderungen  
- Qualitätsziele für die Architektur  
- relevante Stakeholder und deren Erwartungshaltung  

## Aufgabenstellung {#_aufgabenstellung}

::: formalpara-title
**Inhalt**
:::

📋 Kurzbeschreibung der fachlichen Aufgabenstellung, treibenden Kräfte,  
Extrakt (oder Abstract) der Anforderungen.

Verweis auf (hoffentlich vorliegende) Anforderungsdokumente  
(mit Versionsbezeichnungen und Ablageorten).

::: formalpara-title
**Motivation**
:::

🎯 Aus Sicht der späteren Nutzung ist die Unterstützung einer  
fachlichen Aufgabe oder Verbesserung der Qualität der eigentliche  
Beweggrund, ein neues System zu schaffen oder ein bestehendes  
zu modifizieren.

::: formalpara-title
**Form**
:::

📄 Kurze textuelle Beschreibung, eventuell in tabellarischer  
Use-Case Form.

Sofern vorhanden, sollte die Aufgabenstellung Verweise auf die  
entsprechenden Anforderungsdokumente enthalten.

Halten Sie diese Auszüge so knapp wie möglich und wägen Sie  
Lesbarkeit und Redundanzfreiheit gegeneinander ab.

::: formalpara-title
**Weiterführende Informationen**
:::

🔗 Siehe [Anforderungen und Ziele](https://docs.arc42.org/section-1/)  
in der online-Dokumentation (auf Englisch!).

## Qualitätsziele {#_qualitätsziele}

::: formalpara-title
**Inhalt**
:::

🎯 Die Top-3 bis Top-5 der Qualitätsanforderungen für die Architektur,  
deren Erfüllung oder Einhaltung den maßgeblichen Stakeholdern  
besonders wichtig ist.

Gemeint sind hier wirklich Qualitätsziele, die nicht unbedingt mit den  
Zielen des Projekts übereinstimmen. Beachten Sie den Unterschied.

Hier ein Überblick möglicher Themen (basierend auf ISO 25010):

![Kategorien von
Qualitätsanforderungen](images/01_2_iso-25010-topics-DE.drawio.png)

::: formalpara-title
**Motivation**
:::

⚠️ Weil Qualitätsziele grundlegende Architekturentscheidungen oft  
maßgeblich beeinflussen, sollten Sie die für Ihre Stakeholder  
relevanten Qualitätsziele kennen.

Möglichst konkret und operationalisierbar halten.

::: formalpara-title
**Form**
:::

📊 Tabellarische Darstellung der Qualitätsziele mit möglichst konkreten  
Szenarien, geordnet nach Prioritäten.

## Stakeholder {#_stakeholder}

::: formalpara-title
**Inhalt**
:::

👥 Expliziter Überblick über die Stakeholder des Systems –  
über alle Personen, Rollen oder Organisationen –, die:

- die Architektur kennen sollten oder  
- von der Architektur überzeugt werden müssen  
- mit der Architektur oder dem Code arbeiten (z. B. Schnittstellen nutzen)  
- die Dokumentation der Architektur für ihre eigene Arbeit benötigen  
- Entscheidungen über das System und dessen Entwicklung treffen  

::: formalpara-title
**Motivation**
:::

⚠️ Sie sollten die Projektbeteiligten und -betroffenen kennen,  
sonst erleben Sie später im Entwicklungsprozess Überraschungen.

Diese Stakeholder bestimmen unter anderem Umfang und  
Detaillierungsgrad der von Ihnen zu leistenden Arbeit und Ergebnisse.

::: formalpara-title
**Form**
:::

📋 Tabelle mit Rollen- oder Personennamen, sowie deren  
Erwartungshaltung bezüglich der Architektur und deren Dokumentation.

+-----------------+-----------------+-----------------------------------+
| Rolle           | Kontakt         | Erwartungshaltung                 |
+=================+=================+===================================+
| *<Rolle-1>*     | *<Kontakt-1>*   | *<Erwartung-1>*                   |
+-----------------+-----------------+-----------------------------------+
| *<Rolle-2>*     | *<Kontakt-2>*   | *<Erwartung-2>*                   |
+-----------------+-----------------+-----------------------------------+

# Randbedingungen {#section-architecture-constraints}

::: formalpara-title
**Inhalt**
:::

📏 Randbedingungen und Vorgaben, die Ihre Freiheiten bezüglich Entwurf,  
Implementierung oder Ihres Entwicklungsprozesses einschränken.

Diese Randbedingungen gelten manchmal organisations- oder firmenweit  
über die Grenzen einzelner Systeme hinweg.

::: formalpara-title
**Motivation**
:::

🧭 Für eine tragfähige Architektur sollten Sie genau wissen,  
wo Ihre Freiheitsgrade bezüglich der Entwurfsentscheidungen liegen  
und wo Sie Randbedingungen beachten müssen.

Sie können Randbedingungen vielleicht noch verhandeln,  
zunächst sind sie aber da.

::: formalpara-title
**Form**
:::

📊 Einfache Tabellen der Randbedingungen mit Erläuterungen.  
Bei Bedarf unterscheiden Sie:

- technische Randbedingungen  
- organisatorische Randbedingungen  
- politische Randbedingungen  
- übergreifende Konventionen  
  (z. B. Programmier- oder Versionierungsrichtlinien,  
   Dokumentations- oder Namenskonventionen)

::: formalpara-title
**Weiterführende Informationen**
:::

🔗 Siehe [Randbedingungen](https://docs.arc42.org/section-2/)  
in der online-Dokumentation (auf Englisch!).

# Kontextabgrenzung {#section-context-and-scope}

::: formalpara-title
**Inhalt**
:::

🔲 Die Kontextabgrenzung grenzt das System gegen alle  
Kommunikationspartner (Nachbarsysteme und Benutzerrollen) ab.

Sie legt damit die externen Schnittstellen fest und zeigt damit  
auch die Verantwortlichkeit (scope) Ihres Systems:  
Welche Verantwortung trägt das System und welche Verantwortung  
übernehmen die Nachbarsysteme?

Differenzieren Sie fachlichen (Ein- und Ausgaben) und technischen  
Kontext (Kanäle, Protokolle, Hardware), falls nötig.

::: formalpara-title
**Motivation**
:::

⚠️ Die fachlichen und technischen Schnittstellen zur Kommunikation  
gehören zu den kritischsten Aspekten eines Systems.

Stellen Sie sicher, dass Sie diese komplett verstanden haben.

::: formalpara-title
**Form**
:::

📋 Verschiedene Optionen:

- Diverse Kontextdiagramme  
- Listen von Kommunikationsbeziehungen mit deren Schnittstellen  

::: formalpara-title
**Weiterführende Informationen**
:::

🔗 Siehe [Kontextabgrenzung](https://docs.arc42.org/section-3/)  
in der online-Dokumentation (auf Englisch!).

## Fachlicher Kontext {#_fachlicher_kontext}

::: formalpara-title
**Inhalt**
:::

🌐 Festlegung **aller** Kommunikationsbeziehungen (Nutzer, IT-Systeme, ...)  
mit Erklärung der fachlichen Ein- und Ausgabedaten oder Schnittstellen.

Zusätzlich (bei Bedarf) fachliche Datenformate oder Protokolle der  
Kommunikation mit den Nachbarsystemen.

::: formalpara-title
**Motivation**
:::

👥 Alle Beteiligten müssen verstehen, welche fachlichen Informationen  
mit der Umwelt ausgetauscht werden.

::: formalpara-title
**Form**
:::

📊 Alle Diagrammarten, die das System als Blackbox darstellen und  
die fachlichen Schnittstellen zu den Nachbarsystemen beschreiben.

Alternativ oder ergänzend können Sie eine Tabelle verwenden.  
Der Titel gibt den Namen Ihres Systems wieder; die drei Spalten sind:  
Kommunikationsbeziehung, Eingabe, Ausgabe.

**<Diagramm und/oder Tabelle>**

**<optional: Erläuterung der externen fachlichen Schnittstellen>**

## Technischer Kontext {#_technischer_kontext}

::: formalpara-title
**Inhalt**
:::

🔌 Technische Schnittstellen (Kanäle, Übertragungsmedien) zwischen dem  
System und seiner Umwelt.

Zusätzlich eine Erklärung (mapping), welche fachlichen Ein- und  
Ausgaben über welche technischen Kanäle fließen.

::: formalpara-title
**Motivation**
:::

🧱 Viele Stakeholder treffen Architekturentscheidungen auf Basis der  
technischen Schnittstellen des Systems zu seinem Kontext.

Insbesondere bei der Entwicklung von Infrastruktur oder Hardware  
sind diese technischen Schnittstellen durchaus entscheidend.

::: formalpara-title
**Form**
:::

📊 Beispielsweise UML Deployment-Diagramme mit den Kanälen zu  
Nachbarsystemen, begleitet von einer Tabelle, die Kanäle auf  
Ein-/Ausgaben abbildet.

**<Diagramm oder Tabelle>**

**<optional: Erläuterung der externen technischen Schnittstellen>**

**<Mapping fachliche auf technische Schnittstellen>**

# Lösungsstrategie {#section-solution-strategy}

::: formalpara-title
**Inhalt**
:::

🧩 Kurzer Überblick über die grundlegenden Entscheidungen und  
Lösungsansätze, die Entwurf und Implementierung des Systems prägen.

Hierzu gehören:

- Technologieentscheidungen  
- Entscheidungen über die Top-Level-Zerlegung des Systems,  
  beispielsweise die Verwendung gesamthaft prägender Entwurfs-  
  oder Architekturmuster  
- Entscheidungen zur Erreichung der wichtigsten Qualitätsanforderungen  
- relevante organisatorische Entscheidungen, beispielsweise für  
  bestimmte Entwicklungsprozesse oder Delegation bestimmter Aufgaben  
  an andere Stakeholder  

::: formalpara-title
**Motivation**
:::

🏗️ Diese wichtigen Entscheidungen bilden wesentliche „Eckpfeiler"  
der Architektur.

Von ihnen hängen viele weitere Entscheidungen oder  
Implementierungsregeln ab.

::: formalpara-title
**Form**
:::

📝 Fassen Sie die zentralen Entwurfsentscheidungen **kurz** zusammen.

Motivieren Sie, ausgehend von Aufgabenstellung, Qualitätszielen und  
Randbedingungen, was Sie entschieden haben und warum Sie so  
entschieden haben.

Vermeiden Sie redundante Beschreibungen und verweisen Sie eher  
auf weitere Ausführungen in Folgeabschnitten.

::: formalpara-title
**Weiterführende Informationen**
:::

🔗 Siehe [Lösungsstrategie](https://docs.arc42.org/section-4/)  
in der online-Dokumentation (auf Englisch!).

# Bausteinsicht {#section-building-block-view}

::: formalpara-title
**Inhalt**
:::

🏗️ Die Bausteinsicht zeigt die statische Zerlegung des Systems in  
Bausteine (Module, Komponenten, Subsysteme, Klassen, Schnittstellen,  
Pakete, Bibliotheken, Frameworks, Schichten, Partitionen, Tiers,  
Funktionen, Makros, Operationen, Datenstrukturen, ...) sowie deren  
Abhängigkeiten (Beziehungen, Assoziationen, ...).

Diese Sicht sollte in jeder Architekturdokumentation vorhanden sein.  
In der Analogie zum Hausbau bildet die Bausteinsicht den *Grundrissplan*.

::: formalpara-title
**Motivation**
:::

🧩 Behalten Sie den Überblick über den Quellcode, indem Sie die  
statische Struktur des Systems durch Abstraktion verständlich machen.

Damit ermöglichen Sie Kommunikation auf abstrakterer Ebene,  
ohne zu viele Implementierungsdetails offenlegen zu müssen.

::: formalpara-title
**Form**
:::

📊 Die Bausteinsicht ist eine hierarchische Sammlung von Blackboxen und  
Whiteboxen (siehe Abbildung unten) und deren Beschreibungen.

![Hierarchie in der Bausteinsicht](images/05_building_blocks-DE.png)

**Ebene 1** ist die Whitebox-Beschreibung des Gesamtsystems,  
zusammen mit Blackbox-Beschreibungen der darin enthaltenen Bausteine.

**Ebene 2** zoomt in einige Bausteine der Ebene 1 hinein.  
Sie enthält somit die Whitebox-Beschreibungen ausgewählter  
Bausteine der Ebene 1, jeweils zusammen mit Blackbox-Beschreibungen  
darin enthaltener Bausteine.

**Ebene 3** zoomt in einige Bausteine der Ebene 2 hinein, usw.

::: formalpara-title
**Weiterführende Informationen**
:::

🔗 Siehe [Bausteinsicht](https://docs.arc42.org/section-5/)  
in der online-Dokumentation (auf Englisch!).

## Whitebox Gesamtsystem {#_whitebox_gesamtsystem}

An dieser Stelle beschreiben Sie die Zerlegung des Gesamtsystems  
anhand des nachfolgenden Whitebox-Templates. Dieses enthält:

- Ein Übersichtsdiagramm  
- die Begründung dieser Zerlegung  
- Blackbox-Beschreibungen der hier enthaltenen Bausteine.  
  Dafür haben Sie verschiedene Optionen:

  - in *einer* Tabelle: kurzer und pragmatischer Überblick über  
    die enthaltenen Bausteine sowie deren Schnittstellen  
  - als Liste von Blackbox-Beschreibungen der Bausteine, gemäß  
    dem Blackbox-Template (siehe unten). Diese Liste können Sie,  
    je nach Werkzeug, etwa in Form von Unterkapiteln (Text),  
    Unter-Seiten (Wiki) oder geschachtelten Elementen  
    (Modellierungswerkzeug) darstellen  

- (optional:) wichtige Schnittstellen, die nicht bereits im  
  Blackbox-Template eines der Bausteine erläutert werden, aber  
  für das Verständnis der Whitebox von zentraler Bedeutung sind.  
  Aufgrund der vielfältigen Möglichkeiten oder Ausprägungen von  
  Schnittstellen geben wir hierzu kein weiteres Template vor.  
  Im schlimmsten Fall müssen Sie Syntax, Semantik, Protokolle,  
  Fehlerverhalten, Restriktionen, Versionen, Qualitätseigenschaften,  
  notwendige Kompatibilitäten und vieles mehr spezifizieren oder  
  beschreiben. Im besten Fall kommen Sie mit Beispielen oder  
  einfachen Signaturen zurecht.

***<Übersichtsdiagramm>***

Begründung

:   *<Erläuternder Text>*

Enthaltene Bausteine

:   *<Beschreibung der enthaltenen Bausteine (Blackboxen)>*

Wichtige Schnittstellen

:   *<Beschreibung wichtiger Schnittstellen>*

Hier folgen jetzt Erläuterungen zu Blackboxen der Ebene 1.

Falls Sie die tabellarische Beschreibung wählen, so werden Blackboxen  
darin nur mit Name und Verantwortung nach folgendem Muster beschrieben:

+----------------------+-----------------------------------------------+
| **Name**             | **Verantwortung**                             |
+======================+===============================================+
| *<Blackbox 1>*       |  *<Text>*                                     |
+----------------------+-----------------------------------------------+
| *<Blackbox 2>*       |  *<Text>*                                     |
+----------------------+-----------------------------------------------+

Falls Sie die ausführliche Liste von Blackbox-Beschreibungen wählen,  
beschreiben Sie jede wichtige Blackbox in einem eigenen  
Blackbox-Template. Dessen Überschrift ist jeweils der Namen dieser  
Blackbox.

### <Name Blackbox 1> {#_name_blackbox_1}

Beschreiben Sie die <Blackbox 1> anhand des folgenden  
Blackbox-Templates:

- Zweck/Verantwortung  
- Schnittstelle(n), sofern diese nicht als eigenständige  
  Beschreibungen herausgezogen sind. Hierzu gehören eventuell auch  
  Qualitäts- und Leistungsmerkmale dieser Schnittstelle.  
- (Optional) Qualitäts-/Leistungsmerkmale der Blackbox,  
  beispielsweise Verfügbarkeit, Laufzeitverhalten o. Ä.  
- (Optional) Ablageort/Datei(en)  
- (Optional) Erfüllte Anforderungen, falls Sie Traceability zu  
  Anforderungen benötigen.  
- (Optional) Offene Punkte/Probleme/Risiken  

*<Zweck/Verantwortung>*

*<Schnittstelle(n)>*

*<(Optional) Qualitäts-/Leistungsmerkmale>*

*<(Optional) Ablageort/Datei(en)>*

*<(Optional) Erfüllte Anforderungen>*

*<(optional) Offene Punkte/Probleme/Risiken>*

### <Name Blackbox 2> {#_name_blackbox_2}

*<Blackbox-Template>*

### <Name Blackbox n> {#_name_blackbox_n}

*<Blackbox-Template>*

### <Name Schnittstelle 1> {#_name_schnittstelle_1}

...

### <Name Schnittstelle m> {#_name_schnittstelle_m}

## Ebene 2 {#_ebene_2}

Beschreiben Sie den inneren Aufbau (einiger) Bausteine aus Ebene 1  
als Whitebox.

Welche Bausteine Ihres Systems Sie hier beschreiben, müssen Sie selbst  
entscheiden. Bitte stellen Sie dabei Relevanz vor Vollständigkeit.

Skizzieren Sie wichtige, überraschende, riskante, komplexe oder  
besonders volatile Bausteine. Normale, einfache oder standardisierte  
Teile sollten Sie weglassen.

### Whitebox <Baustein 1> {#_whitebox_baustein_1}

...zeigt das Innenleben von *Baustein 1*.

*<Whitebox-Template>*

### Whitebox <Baustein 2> {#_whitebox_baustein_2}

*<Whitebox-Template>*

...

### Whitebox <Baustein m> {#_whitebox_baustein_m}

*<Whitebox-Template>*

## Ebene 3 {#_ebene_3}

Beschreiben Sie den inneren Aufbau (einiger) Bausteine aus Ebene 2  
als Whitebox.

Bei tieferen Gliederungen der Architektur kopieren Sie diesen Teil  
von arc42 für die weiteren Ebenen.

### Whitebox <_Baustein x.1_> {#_whitebox_baustein_x_1}

...zeigt das Innenleben von *Baustein x.1*.

*<Whitebox-Template>*

### Whitebox <_Baustein x.2_> {#_whitebox_baustein_x_2}

*<Whitebox-Template>*

### Whitebox <_Baustein y.1_> {#_whitebox_baustein_y_1}

*<Whitebox-Template>*

# Laufzeitsicht {#section-runtime-view}

::: formalpara-title
**Inhalt**
:::

⚙️ Diese Sicht erklärt konkrete Abläufe und Beziehungen zwischen  
Bausteinen in Form von Szenarien aus den folgenden Bereichen:

- Wichtige Abläufe oder Features: Wie führen die Bausteine der  
  Architektur die wichtigsten Abläufe durch?  
- Interaktionen an kritischen externen Schnittstellen: Wie arbeiten  
  Bausteine mit Nutzern und Nachbarsystemen zusammen?  
- Betrieb und Administration: Inbetriebnahme, Start, Stop.  
- Fehler- und Ausnahmeszenarien  

Anmerkung: Das Kriterium für die Auswahl der möglichen Szenarien  
(d. h. Abläufe) des Systems ist deren Architekturrelevanz. Es geht  
nicht darum, möglichst viele Abläufe darzustellen, sondern eine  
angemessene Auswahl zu dokumentieren.

::: formalpara-title
**Motivation**
:::

🧱 Sie sollten verstehen, wie (Instanzen von) Bausteine(n) Ihres  
Systems ihre jeweiligen Aufgaben erfüllen und zur Laufzeit  
miteinander kommunizieren.

Nutzen Sie diese Szenarien in der Dokumentation hauptsächlich für  
eine verständlichere Kommunikation mit denjenigen Stakeholdern,  
die die statischen Modelle (z. B. Bausteinsicht, Verteilungssicht)  
weniger verständlich finden.

::: formalpara-title
**Form**
:::

📊 Für die Beschreibung von Szenarien gibt es zahlreiche  
Ausdrucksmöglichkeiten. Nutzen Sie beispielsweise:

- Nummerierte Schrittfolgen oder Aufzählungen in Umgangssprache  
- Aktivitäts- oder Flussdiagramme  
- Sequenzdiagramme  
- BPMN (Geschäftsprozessmodell und -notation) oder EPKs  
  (Ereignis-Prozessketten)  
- Zustandsautomaten  
- ...

::: formalpara-title
**Weiterführende Informationen**
:::

🔗 Siehe [Laufzeitsicht](https://docs.arc42.org/section-6/)  
in der online-Dokumentation (auf Englisch!).

## <Bezeichnung Laufzeitszenario 1> {#_bezeichnung_laufzeitszenario_1}

- <hier Laufzeitdiagramm oder Ablaufbeschreibung einfügen>  
- <hier Besonderheiten bei dem Zusammenspiel der Bausteine in diesem  
  Szenario erläutern>  

## <Bezeichnung Laufzeitszenario 2> {#_bezeichnung_laufzeitszenario_2}

...

## <Bezeichnung Laufzeitszenario n> {#_bezeichnung_laufzeitszenario_n}

...

# Verteilungssicht {#section-deployment-view}

::: formalpara-title
**Inhalt**
:::

🌐 Die Verteilungssicht beschreibt:

1. die technische Infrastruktur, auf der Ihr System ausgeführt wird,  
   mit Infrastrukturelementen wie Standorten, Umgebungen, Rechnern,  
   Prozessoren, Kanälen und Netztopologien sowie sonstigen  
   Bestandteilen, und  

2. die Abbildung von (Software-)Bausteinen auf diese Infrastruktur.

Häufig laufen Systeme in unterschiedlichen Umgebungen, beispielsweise  
Entwicklung-/Test- oder Produktionsumgebungen. In solchen Fällen sollten  
Sie alle relevanten Umgebungen aufzeigen.

Nutzen Sie die Verteilungssicht insbesondere dann, wenn Ihre Software  
auf mehr als einem Rechner, Prozessor, Server oder Container abläuft  
oder Sie Ihre Hardware sogar selbst konstruieren.

Aus Softwaresicht genügt es, auf die Aspekte zu achten, die für die  
Softwareverteilung relevant sind. Insbesondere bei der  
Hardwareentwicklung kann es notwendig sein, die Infrastruktur mit  
beliebigen Details zu beschreiben.

::: formalpara-title
**Motivation**
:::

⚠️ Software läuft nicht ohne Infrastruktur. Diese zugrundeliegende  
Infrastruktur beeinflusst Ihr System und/oder querschnittliche  
Lösungskonzepte, daher müssen Sie diese Infrastruktur kennen.

::: formalpara-title
**Form**
:::

📊 Das oberste Verteilungsdiagramm könnte bereits in Ihrem technischen  
Kontext enthalten sein, mit Ihrer Infrastruktur als EINE Blackbox.  
Jetzt zoomen Sie in diese Infrastruktur mit weiteren  
Verteilungsdiagrammen hinein:

- Die UML stellt mit Verteilungsdiagrammen (Deployment diagrams)  
  eine Diagrammart zur Verfügung, um diese Sicht auszudrücken.  
  Nutzen Sie diese, evtl. auch geschachtelt, wenn Ihre  
  Verteilungsstruktur es verlangt.  

- Falls Ihre Infrastruktur-Stakeholder andere Diagrammarten  
  bevorzugen, die beispielsweise Prozessoren und Kanäle zeigen,  
  sind diese hier ebenfalls einsetzbar.

::: formalpara-title
**Weiterführende Informationen**
:::

🔗 Siehe [Verteilungssicht](https://docs.arc42.org/section-7/)  
in der online-Dokumentation (auf Englisch!).

## Infrastruktur Ebene 1 {#_infrastruktur_ebene_1}

An dieser Stelle beschreiben Sie (als Kombination von Diagrammen mit  
Tabellen oder Texten):

- die Verteilung des Gesamtsystems auf mehrere Standorte, Umgebungen,  
  Rechner, Prozessoren o. Ä., sowie die physischen Verbindungskanäle  
  zwischen diesen,  
- wichtige Begründungen für diese Verteilungsstruktur,  
- Qualitäts- und/oder Leistungsmerkmale dieser Infrastruktur,  
- Zuordnung von Softwareartefakten zu Bestandteilen der Infrastruktur  

Für mehrere Umgebungen oder alternative Deployments kopieren Sie  
diesen Teil von arc42 für alle wichtigen Umgebungen/Varianten.

***<Übersichtsdiagramm>***

Begründung

:   *<Erläuternder Text>*

Qualitäts- und/oder Leistungsmerkmale

:   *<Erläuternder Text>*

Zuordnung von Bausteinen zu Infrastruktur

:   *<Beschreibung der Zuordnung>*

## Infrastruktur Ebene 2 {#_infrastruktur_ebene_2}

An dieser Stelle können Sie den inneren Aufbau (einiger)  
Infrastrukturelemente aus Ebene 1 beschreiben.

Für jedes Infrastrukturelement kopieren Sie die Struktur aus Ebene 1.

### <Infrastrukturelement 1> {#_infrastrukturelement_1}

*<Diagramm + Erläuterungen>*

### <Infrastrukturelement 2> {#_infrastrukturelement_2}

*<Diagramm + Erläuterungen>*

...

### <Infrastrukturelement n> {#_infrastrukturelement_n}

*<Diagramm + Erläuterungen>*

# Querschnittliche Konzepte {#section-concepts}

::: formalpara-title
**Inhalt**
:::

🧩 Dieser Abschnitt beschreibt übergreifende, prinzipielle Regelungen  
und Lösungsansätze, die an mehreren Stellen (=querschnittlich) relevant  
sind.

Solche Konzepte betreffen oft mehrere Bausteine. Dazu können vielerlei  
Themen gehören, wie beispielsweise die Themen aus dem nachfolgenden  
Diagramm:

![Mögliche Themen für querschnittliche
Konzepte](images/08-concepts-DE.drawio.png)

::: formalpara-title
**Motivation**
:::

🏗️ Konzepte bilden die Grundlage für *konzeptionelle Integrität*  
(Konsistenz, Homogenität) der Architektur und damit eine wesentliche  
Grundlage für die innere Qualität Ihrer Systeme.

Dieser Abschnitt im Template ist der richtige Ort für die konsistente  
Behandlung solcher Themen.

Viele solche Konzepte beeinflussen oder beziehen sich auf mehrerer  
Ihrer Bausteine.

::: formalpara-title
**Form**
:::

📊 Kann vielfältig sein:

- Konzeptpapiere mit beliebiger Gliederung  
- beispielhafte Implementierung speziell für technische Konzepte  
- übergreifende Modelle/Szenarien mit Notationen, die Sie auch in  
  den Architektursichten nutzen  

::: formalpara-title
**Struktur**
:::

🎯 Wählen Sie **nur** die wichtigsten Themen für Ihr System und erklären  
das jeweilige Konzept dann unter einer Level-2 Überschrift dieser  
Sektion (z. B. 8.1, 8.2 etc).

Beschränken Sie sich auf die wichtigen, und versuchen **auf keinen  
Fall** alle oben dargestellten Themen zu bearbeiten.

::: formalpara-title
**Weiterführende Informationen**
:::

ℹ️ Einige Themen innerhalb von Systemen betreffen oft mehrere Bausteine,  
Hardwareelemente oder Prozesse. Es könnte einfacher sein, solche  
*Querschnittsthemen* an einer zentralen Stelle zu kommunizieren oder zu  
dokumentieren, anstatt sie in der Beschreibung der betreffenden  
Bausteine, Hardwareelemente oder Entwicklungsprozesse zu wiederholen.

Bestimmte Konzepte können **alle** Elemente eines Systems betreffen,  
andere sind vielleicht nur für einige wenige relevant.

🔗 Siehe [Querschnittliche Konzepte](https://docs.arc42.org/section-8/)  
in der online-Dokumentation (auf Englisch).

## <Konzept 1> {#_konzept_1}

*<Erklärung>*

## <Konzept 2> {#_konzept_2}

*<Erklärung>*

...

## <Konzept n> {#_konzept_n}

*<Erklärung>*

# Architekturentscheidungen {#section-design-decisions}

::: formalpara-title
**Inhalt**
:::

🏁 Wichtige, teure, große oder riskante Architektur- oder  
Entwurfsentscheidungen inklusive der jeweiligen Begründungen.

Mit "Entscheidungen" meinen wir hier die Auswahl einer von mehreren  
Alternativen unter vorgegebenen Kriterien.

Wägen Sie ab, inwiefern Sie Entscheidungen hier zentral beschreiben,  
oder wo eine lokale Beschreibung (z. B. in der Whitebox-Sicht von  
Bausteinen) sinnvoller ist. Vermeiden Sie Redundanz. Verweisen Sie evtl.  
auf Abschnitt 4, wo schon grundlegende strategische Entscheidungen  
beschrieben wurden.

::: formalpara-title
**Motivation**
:::

👥 Stakeholder des Systems sollten wichtige Entscheidungen verstehen und  
nachvollziehen können.

::: formalpara-title
**Form**
:::

📊 Verschiedene Möglichkeiten:

- ADR ([Documenting Architecture  
  Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions))  
  für jede wichtige Entscheidung  
- Liste oder Tabelle, nach Wichtigkeit und Tragweite der  
  Entscheidungen geordnet  
- ausführlicher in Form einzelner Unterkapitel je Entscheidung  

::: formalpara-title
**Weiterführende Informationen**
:::

🔗 Siehe [Architekturentscheidungen](https://docs.arc42.org/section-9/)  
in der arc42 Dokumentation (auf Englisch!). Dort finden Sie Links und  
Beispiele zum Thema ADR.

# Qualitätsanforderungen {#section-quality-scenarios}

::: formalpara-title
**Inhalt**
:::

📋 Dieser Abschnitt enthält alle relevanten Qualitätsanforderungen.

Die wichtigsten davon haben Sie bereits in Abschnitt 1.2  
(Qualitätsziele) hervorgehoben, daher soll hier nur auf sie verwiesen  
werden. In diesem Abschnitt 10 sollten Sie auch Qualitätsanforderungen  
mit geringerer Bedeutung erfassen, deren Nichterfüllung keine großen  
Risiken birgt (die aber *nice-to-have* sein könnten).

::: formalpara-title
**Motivation**
:::

⚠️ Weil Qualitätsanforderungen die Architekturentscheidungen oft  
maßgeblich beeinflussen, sollten Sie die für Ihre Stakeholder  
relevanten Qualitätsanforderungen kennen.

Möglichst konkret und operationalisiert halten.

- Siehe [Qualitätsanforderungen](https://docs.arc42.org/section-10/)  
  in der online-Dokumentation (auf Englisch!).  
- Siehe auch das ausführliche [Q42 Qualitätsmodell auf  
  https://quality.arc42.org](https://quality.arc42.org).

## Übersicht der Qualitätsanforderungen {#_übersicht_der_qualitätsanforderungen}

::: formalpara-title
**Inhalt**
:::

📊 Eine Übersicht oder Zusammenfassung der Qualitätsanforderungen.

::: formalpara-title
**Motivation**
:::

🧩 Oft stößt man auf Dutzende (oder sogar Hunderte) von detaillierten  
Qualitätsanforderungen für ein System. In diesem Abschnitt sollten Sie  
versuchen, sie zusammenzufassen, z. B. durch die Beschreibung von  
Kategorien oder Themen (wie z. B. von ISO 25010:2023 oder Q42  
vorgeschlagen).

Wenn diese Kurzbeschreibungen oder Zusammenfassungen bereits präzise,  
spezifisch und messbar sind, können Sie Abschnitt 10.2 auslassen.

::: formalpara-title
**Form**
:::

📋 Verwenden Sie eine einfache Tabelle, in der jede Zeile eine Kategorie  
oder ein Thema und eine kurze Beschreibung der Qualitätsanforderung  
enthält. Alternativ können Sie auch eine Mindmap verwenden, um diese  
Qualitätsanforderungen zu strukturieren. In der Literatur (insb.  
[Bass+21]) ist die Idee eines *Quality Attribute Utility Tree* (auf  
Deutsch manchmal kurz als *Qualitätsbaum* bezeichnet) beschrieben  
worden, der den Oberbegriff „Qualität" als Wurzel hat und eine  
baumartige Verfeinerung des Begriffs „Qualität" verwendet.

## Qualitätsszenarien {#_qualitätsszenarien}

::: formalpara-title
**Inhalt**
:::

🎯 Qualitätsszenarien konkretisieren Qualitätsanforderungen und ermöglichen  
es zu entscheiden, ob sie erfüllt sind (im Sinne von Akzeptanzkriterien).

Stellen Sie sicher, dass Ihre Szenarien spezifisch und messbar sind.

Zwei Arten von Szenarien finden wir besonders nützlich:

- **Nutzungsszenarien** (auch bekannt als Anwendungs- oder  
  Anwendungsfallszenarien) beschreiben, wie das System zur Laufzeit  
  auf einen bestimmten Auslöser reagieren soll. Hierunter fallen auch  
  Szenarien zur Beschreibung von Effizienz oder Performance. Beispiel:  
  Das System beantwortet eine Benutzeranfrage innerhalb einer Sekunde.  

- **Änderungsszenarien** beschreiben die gewünschte Wirkung einer  
  Änderung oder Erweiterung des Systems oder seiner unmittelbaren  
  Umgebung. Beispiel: Zusätzliche Funktionalität wird implementiert  
  oder Anforderungen an ein Qualitätsmerkmal ändern sich, und der  
  Aufwand oder die Dauer der Änderung wird gemessen.  

::: formalpara-title
**Form**
:::

📊 Typische Informationen für detaillierte Szenarien sind die folgenden:

In Kurzform (bevorzugt im Q42-Modell):

- **Kontext/Hintergrund**: Um welche Art von System oder Komponente  
  handelt es sich, wie sieht die Umgebung oder Situation aus?  
- **Quelle/Stimulus**: Wer oder was initiiert oder löst ein Verhalten,  
  eine Reaktion oder eine Aktion aus?  
- **Metrik/Akzeptanzkriterien**: Eine Reaktion einschließlich einer  
  *Maßnahme* oder *Metrik*  

Die Langform von Szenarien (die von der SEI und [Bass+21] bevorzugt  
wird) ist detaillierter und enthält die folgenden Informationen:

- **Szenario-ID**: Ein eindeutiger Bezeichner für das Szenario.  
- **Szenario-Name**: Ein kurzer, beschreibender Name für das Szenario.  
- **Quelle**: Die Entität (Benutzer, System oder Ereignis), die das  
  Szenario auslöst.  
- **Stimulus**: Das auslösende Ereignis oder die Bedingung, auf die  
  das System reagieren muss.  
- **Umgebung**: Der betriebliche Kontext oder die Bedingungen, unter  
  denen das System den Stimulus erlebt.  
- **Artefakt**: Die Bausteine oder anderen Elemente des Systems, die  
  von dem Stimulus betroffen sind.  
- **Reaktion**: Das Ergebnis oder Verhalten, das das System als  
  Reaktion auf den Stimulus zeigt.  
- **Antwortmaß**: Das Kriterium oder die Metrik, nach der die Antwort  
  des Systems bewertet wird.  

::: formalpara-title
**Beispiele**
:::

🔗 Ausführliche Beispiele für Qualitätsanforderungen finden Sie auf [der  
Website zum Qualitätsmodell Q42](https://quality.arc42.org).

- Len Bass, Paul Clements, Rick Kazman: „Software Architecture in  
  Practice", 4. Auflage, Addison-Wesley, 2021.  

# Risiken und technische Schulden {#section-technical-risks}

::: formalpara-title
**Inhalt**
:::

⚠️ Eine nach Prioritäten geordnete Liste der erkannten Architekturrisiken  
und/oder technischen Schulden.

> Risikomanagement ist Projektmanagement für Erwachsene.  
> — Tim Lister, Atlantic Systems Guild

Unter diesem Motto sollten Sie Architekturrisiken und/oder technische  
Schulden gezielt ermitteln, bewerten und Ihren Management-Stakeholdern  
(z. B. Projektleitung, Product-Owner) transparent machen.

::: formalpara-title
**Form**
:::

📋 Liste oder Tabelle von Risiken und/oder technischen Schulden, eventuell  
mit vorgeschlagenen Maßnahmen zur Risikovermeidung, Risikominimierung  
oder dem Abbau der technischen Schulden.

::: formalpara-title
**Weiterführende Informationen**
:::

🔗 Siehe [Risiken und technische  
Schulden](https://docs.arc42.org/section-11/) in der  
online-Dokumentation (auf Englisch!).

# Glossar {#section-glossary}

::: formalpara-title
**Inhalt**
:::

📖 Die wesentlichen fachlichen und technischen Begriffe, die Stakeholder  
im Zusammenhang mit dem System verwenden.

Nutzen Sie das Glossar ebenfalls als Übersetzungsreferenz, falls Sie in  
mehrsprachigen Teams arbeiten.

::: formalpara-title
**Motivation**
:::

⚠️ Sie sollten relevante Begriffe klar definieren, so dass alle Beteiligten:

- diese Begriffe identisch verstehen, und  
- vermeiden, mehrere Begriffe für die gleiche Sache zu haben.  

::: formalpara-title
**Form**
:::

📋 Zweispaltige Tabelle mit <Begriff> und <Definition>.

Eventuell weitere Spalten mit Übersetzungen, falls notwendig.

::: formalpara-title
**Weiterführende Informationen**
:::

🔗 Siehe [Glossar](https://docs.arc42.org/section-12/) in der  
online-Dokumentation (auf Englisch!).

+----------------------+-----------------------------------------------+
| Begriff              | Definition                                    |
+======================+===============================================+
| *<Begriff-1>*        | *<Definition-1>*                              |
+----------------------+-----------------------------------------------+
| *<Begriff-2>*        | *<Definition-2>*                              |
+----------------------+-----------------------------------------------+

# Emoji-Legende

ℹ️ Bedeutung der in diesem Template verwendeten Emojis:

| Emoji | Bedeutung |
|-------|-----------|
| ℹ️ | Info / Hinweis |
| 🧩 | Kontext / Problem / Konzept |
| 🎯 | Ziel / Motivation |
| 📋 | Liste / Übersicht / Form |
| 📄 | Dokument / Formale Prüfung |
| 📊 | Tabelle / Diagramm / Form |
| 🔗 | Weiterführende Informationen |
| ⚠️ | Achtung / Risiko / Motivation |
| 🧭 | Richtung / Motivation |
| 🏗️ | Architektur / Struktur |
| 🧱 | Baustein / Struktur |
| 🏁 | Entscheidung / Outcome |
| 👥 | Stakeholder / Personen |
| 🌐 | Fachlicher Kontext / Netzwerk |
| 🔌 | Technischer Kontext / Schnittstelle |
| 📝 | Text / Beschreibung |
| 🏛️ | Infrastruktur / deployment |
| ⚙️ | Laufzeit / Verhalten |
| 📖 | Glossar / Begriffe |
| ✅ | geprüft / erfüllt |
| 🔒 | Sicherheit / Schutzziele |
| 📈 | Metrik / Leistung |
| 🚧 | Abgrenzung / Grenzen |
| 💡 | Mehrwert / Idee |
| 🏷️ | Tags |


---
date: July 2025
title: "![arc42](images/arc42-logo.png) Template"
---

# <System Name> Architecture Documentation

**About arc42**

ℹ️ arc42 is the template for documentation of software and system architecture.

Template Version 9.0-EN (based on AsciiDoc), July 2025.

Created, maintained, and © by  
Dr. Peter Hruschka, Dr. Gernot Starke and contributors.  
See <https://arc42.org>.

:::: note
::: title
This version contains help and explanations.
:::

ℹ️ This version is for familiarization with arc42 and its concepts.  
For your own system, use the *plain* version instead.
::::

# Introduction and Goals {#section-introduction-and-goals}

🧩 Describes the relevant requirements and driving forces that architects  
and the development team must consider. These include:

- underlying business goals  
- essential features  
- essential functional requirements  
- quality goals for the architecture  
- relevant stakeholders and their expectations  

## Requirements Overview {#_requirements_overview}

::: formalpara-title
**Contents**
:::

📋 Short description of functional requirements, driving forces,  
and an extract (or abstract) of requirements.

Link to (hopefully existing) requirements documents  
(with version number and where to find them).

::: formalpara-title
**Motivation**
:::

🎯 From the end users’ point of view, a system is created or modified  
to improve support of a business activity and/or improve quality.

::: formalpara-title
**Form**
:::

📄 Short textual description, probably in tabular use-case format.  
If requirements documents exist, this overview should refer to them.

Keep these excerpts as short as possible.  
Balance readability of this document with potential redundancy  
w.r.t. requirements documents.

::: formalpara-title
**Further Information**
:::

🔗 See [Introduction and Goals](https://docs.arc42.org/section-1/)  
in the arc42 documentation.

## Quality Goals {#_quality_goals}

::: formalpara-title
**Contents**
:::

🎯 The top three (max five) quality goals for the architecture  
whose fulfillment is of highest importance to the major stakeholders.

We really mean quality goals for the architecture.  
Do not confuse them with project goals. They are not necessarily identical.

Consider this overview of potential topics (based on ISO 25010):

![Categories of Quality
Requirements](images/01_2_iso-25010-topics-EN-2023.drawio.png)

::: formalpara-title
**Motivation**
:::

⚠️ You should know the quality goals of your most important stakeholders,  
since they will influence fundamental architectural decisions.

Make sure to be very concrete about these qualities;  
avoid buzzwords. If you as an architect do not know how  
the quality of your work will be judged...

::: formalpara-title
**Form**
:::

📊 A table with quality goals and concrete scenarios, ordered by priority.

## Stakeholders {#_stakeholders}

::: formalpara-title
**Contents**
:::

👥 Explicit overview of stakeholders of the system: all persons, roles,  
or organizations that:

- should know the architecture  
- have to be convinced of the architecture  
- have to work with the architecture or with code  
- need the documentation of the architecture for their work  
- have to come up with decisions about the system or its development  

::: formalpara-title
**Motivation**
:::

⚠️ You should know all parties involved in development of the system  
or affected by the system. Otherwise, you may get nasty surprises later.

These stakeholders determine the extent and level of detail  
of your work and its results.

::: formalpara-title
**Form**
:::

📋 Table with role names, person names, and their expectations  
with respect to the architecture and its documentation.

+-------------+---------------------------+---------------------------+
| Role/Name   | Contact                   | Expectations              |
+=============+===========================+===========================+
| *           | *<Contact-1>*             | *<Expectation-1>*         |
| <Role-1>    |                           |                           |
+-------------+---------------------------+---------------------------+
| *           | *<Contact-2>*             | *<Expectation-2>*         |
| <Role-2>    |                           |                           |
+-------------+---------------------------+---------------------------+

# Architecture Constraints {#section-architecture-constraints}

::: formalpara-title
**Contents**
:::

📏 Any requirement that constrains software architects in their freedom of  
design and implementation decisions, or decisions about the development process.

These constraints sometimes go beyond individual systems and are valid for  
whole organizations and companies.

::: formalpara-title
**Motivation**
:::

🧭 Architects should know exactly where they are free in their design  
decisions and where they must adhere to constraints.

Constraints must always be dealt with; they may be negotiable, though.

::: formalpara-title
**Form**
:::

📊 Simple tables of constraints with explanations.  
If needed, you can subdivide them into:

- technical constraints  
- organizational and political constraints  
- conventions (e.g. programming or versioning guidelines,  
  documentation or naming conventions)

::: formalpara-title
**Further Information**
:::

🔗 See [Architecture Constraints](https://docs.arc42.org/section-2/)  
in the arc42 documentation.

# Context and Scope {#section-context-and-scope}

::: formalpara-title
**Contents**
:::

🔲 Context and scope - as the name suggests - delimits your system  
(i.e. your scope) from all its communication partners  
(neighboring systems and users, i.e. the context of your system).

It thereby specifies the external interfaces.

If necessary, differentiate the business context (domain-specific inputs  
and outputs) from the technical context (channels, protocols, hardware).

::: formalpara-title
**Motivation**
:::

⚠️ The domain interfaces and technical interfaces to communication partners  
are among your system's most critical aspects.

Make sure that you completely understand them.

::: formalpara-title
**Form**
:::

📋 Various options:

- Context diagrams  
- Lists of communication partners and their interfaces

::: formalpara-title
**Further Information**
:::

🔗 See [Context and Scope](https://docs.arc42.org/section-3/)  
in the arc42 documentation.

## Business Context {#_business_context}

::: formalpara-title
**Contents**
:::

🌐 Specification of **all** communication partners (users, IT-systems, ...)  
with explanations of domain-specific inputs and outputs or interfaces.

Optionally, you can add domain-specific formats or communication protocols.

::: formalpara-title
**Motivation**
:::

👥 All stakeholders should understand which data are exchanged  
with the environment of the system.

::: formalpara-title
**Form**
:::

📊 All kinds of diagrams that show the system as a black box  
and specify the domain interfaces to communication partners.

Alternatively (or additionally) you can use a table.  
The title of the table is the name of your system.  
The three columns contain:

- name of the communication partner  
- inputs  
- outputs

**<Diagram or Table>**

**<optionally: Explanation of external domain interfaces>**

## Technical Context {#_technical_context}

::: formalpara-title
**Contents**
:::

🔌 Technical interfaces (channels and transmission media) linking your  
system to its environment.

In addition, a mapping of domain-specific input/output to the channels,  
i.e. an explanation which I/O uses which channel.

::: formalpara-title
**Motivation**
:::

🧱 Many stakeholders make architectural decisions based on the technical  
interfaces between the system and its context. Especially infrastructure  
or hardware designers decide these technical interfaces.

::: formalpara-title
**Form**
:::

📊 E.g. UML deployment diagram describing channels to neighboring systems,  
together with a mapping table showing relationships between channels  
and input/output.

**<Diagram or Table>**

**<optionally: Explanation of technical interfaces>**

**<Mapping Input/Output to Channels>**

# Solution Strategy {#section-solution-strategy}

::: formalpara-title
**Contents**
:::

🧩 A short summary and explanation of the fundamental decisions and  
solution strategies that shape system architecture. It includes:

- technology decisions  
- decisions about the top-level decomposition of the system, e.g.  
  usage of an architectural pattern or design pattern  
- decisions on how to achieve key quality goals  
- relevant organizational decisions, e.g. selecting a development  
  process or delegating certain tasks to third parties

::: formalpara-title
**Motivation**
:::

🏗️ These decisions form the cornerstones for your architecture.  
They are the foundation for many other detailed decisions or implementation rules.

::: formalpara-title
**Form**
:::

📝 Keep the explanations of such key decisions short.

Motivate what was decided and why it was decided that way, based upon  
problem statement, quality goals, and key constraints. Refer to details  
in the following sections.

::: formalpara-title
**Further Information**
:::

🔗 See [Solution Strategy](https://docs.arc42.org/section-4/)  
in the arc42 documentation.

# Building Block View {#section-building-block-view}

::: formalpara-title
**Content**
:::

🏗️ The building block view shows the static decomposition of the system  
into building blocks (modules, components, subsystems, classes, interfaces,  
packages, libraries, frameworks, layers, partitions, tiers, functions,  
macros, operations, data structures, ...) as well as their dependencies  
(relationships, associations, ...).

This view is mandatory for every architecture documentation.  
In analogy to a house, this is the *floor plan*.

::: formalpara-title
**Motivation**
:::

🧩 Maintain an overview of your source code by making its structure  
understandable through abstraction.

This allows you to communicate with your stakeholders on an abstract  
level without disclosing implementation details.

::: formalpara-title
**Form**
:::

📊 The building block view is a hierarchical collection of black boxes  
and white boxes (see figure below) and their descriptions.

![Hierarchy of building blocks](images/05_building_blocks-EN.png)

**Level 1** is the white box description of the overall system together  
with black box descriptions of all contained building blocks.

**Level 2** zooms into some building blocks of level 1. Thus it contains  
the white box description of selected building blocks of level 1, together  
with black box descriptions of their internal building blocks.

**Level 3** zooms into selected building blocks of level 2, and so on.

::: formalpara-title
**Further Information**
:::

🔗 See [Building Block View](https://docs.arc42.org/section-5/)  
in the arc42 documentation.

## Whitebox Overall System {#_whitebox_overall_system}

Here you describe the decomposition of the overall system using the  
following white box template. It contains:

- an overview diagram  
- a motivation for the decomposition  
- black box descriptions of the contained building blocks. For these  
  we offer you alternatives:

  - use *one* table for a short and pragmatic overview of all  
    contained building blocks and their interfaces  
  - use a list of black box descriptions of the building blocks  
    according to the black box template (see below). Depending on  
    your choice of tool this list could be sub-chapters (in text  
    files), sub-pages (in a Wiki) or nested elements (in a modeling  
    tool)

- (optional:) important interfaces, that are not explained in the  
  black box templates of a building block, but are very important for  
  understanding the white box. Since there are so many ways to specify  
  interfaces, why do not provide a specific template for them. In the  
  worst case you have to specify and describe syntax, semantics,  
  protocols, error handling, restrictions, versions, qualities,  
  necessary compatibilities and many things more. In the best case you  
  will get away with examples or simple signatures.

***<Overview Diagram>***

Motivation

:   *<text explanation>*

Contained Building Blocks

:   *<Description of contained building block (black boxes)>*

Important Interfaces

:   *<Description of important interfaces>*

Insert your explanations of black boxes from level 1:

If you use tabular form, you will only describe your black boxes with  
name and responsibility according to the following schema:

+----------------------+-----------------------------------------------+
| **Name**             | **Responsibility**                            |
+======================+===============================================+
| *<black box 1>*      |  *<Text>*                                     |
+----------------------+-----------------------------------------------+
| *<black box 2>*      |  *<Text>*                                     |
+----------------------+-----------------------------------------------+

If you use a list of black box descriptions, then you fill in a separate  
black box template for every important building block. Its headline is  
the name of the black box.

### <Name black box 1> {#_name_black_box_1}

Here you describe <black box 1> according to the following black box template:

- Purpose/Responsibility  
- Interface(s), when they are not extracted as separate paragraphs.  
  This interfaces may include qualities and performance characteristics.  
- (Optional) Quality-/Performance characteristics of the black box,  
  e.g. availability, run time behavior, ...  
- (Optional) directory/file location  
- (Optional) Fulfilled requirements (if you need traceability to  
  requirements)  
- (Optional) Open issues/problems/risks

*<Purpose/Responsibility>*

*<Interface(s)>*

*<(Optional) Quality/Performance Characteristics>*

*<(Optional) Directory/File Location>*

*<(Optional) Fulfilled Requirements>*

*<(optional) Open Issues/Problems/Risks>*

### <Name black box 2> {#_name_black_box_2}

*<black box template>*

### <Name black box n> {#_name_black_box_n}

*<black box template>*

### <Name interface 1> {#_name_interface_1}

...

### <Name interface m> {#_name_interface_m}

## Level 2 {#_level_2}

Here you can specify the inner structure of (some) building blocks from  
level 1 as white boxes.

You have to decide which building blocks of your system are important  
enough to justify such a detailed description. Please prefer relevance  
over completeness. Specify important, surprising, risky, complex or  
volatile building blocks. Leave out normal, simple, boring or  
standardized parts of your system.

### White Box <building block 1> {#_white_box_building_block_1}

...describes the internal structure of *building block 1*.

*<white box template>*

### White Box <building block 2> {#_white_box_building_block_2}

*<white box template>*

...

### White Box <building block m> {#_white_box_building_block_m}

*<white box template>*

## Level 3 {#_level_3}

Here you can specify the inner structure of (some) building blocks from  
level 2 as white boxes.

When you need more detailed levels of your architecture, please copy this  
part of arc42 for additional levels.

### White Box <_building block x.1_> {#_white_box_building_block_x_1}

Specifies the internal structure of *building block x.1*.

*<white box template>*

### White Box <_building block x.2_> {#_white_box_building_block_x_2}

*<white box template>*

### White Box <_building block y.1_> {#_white_box_building_block_y_1}

*<white box template>*

# Runtime View {#section-runtime-view}

::: formalpara-title
**Contents**
:::

⚙️ The runtime view describes concrete behavior and interactions of the  
system's building blocks in form of scenarios from the following areas:

- important use cases or features: how do building blocks execute them?  
- interactions at critical external interfaces: how do building blocks  
  cooperate with users and neighboring systems?  
- operation and administration: launch, start-up, stop  
- error and exception scenarios

Remark: The main criterion for the choice of possible scenarios  
(sequences, workflows) is their **architectural relevance**. It is  
**not** important to describe a large number of scenarios. You should  
rather document a representative selection.

::: formalpara-title
**Motivation**
:::

🧱 You should understand how (instances of) building blocks of your system  
perform their job and communicate at runtime. You will mainly capture  
scenarios in your documentation to communicate your architecture to  
stakeholders that are less willing or able to read and understand the  
static models (building block view, deployment view).

::: formalpara-title
**Form**
:::

📊 There are many notations for describing scenarios, e.g.:

- numbered list of steps (in natural language)  
- activity diagrams or flow charts  
- sequence diagrams  
- BPMN or EPCs (event process chains)  
- state machines  
- ...

::: formalpara-title
**Further Information**
:::

🔗 See [Runtime View](https://docs.arc42.org/section-6/)  
in the arc42 documentation.

## <Runtime Scenario 1> {#_runtime_scenario_1}

- *<insert runtime diagram or textual description of the scenario>*  
- *<insert description of the notable aspects of the interactions  
  between the building block instances depicted in this diagram.>*

## <Runtime Scenario 2> {#_runtime_scenario_2}

## ...

## <Runtime Scenario n> {#_runtime_scenario_n}

# Deployment View {#section-deployment-view}

::: formalpara-title
**Content**
:::

🌐 The deployment view describes:

1. technical infrastructure used to execute your system, with  
   infrastructure elements like geographical locations, environments,  
   computers, processors, channels and net topologies as well as other  
   infrastructure elements and  
2. mapping of (software) building blocks to that infrastructure elements.

Often systems are executed in different environments, e.g.  
development environment, test environment, production environment.  
In such cases you should document all relevant environments.

Especially document a deployment view if your software is executed as  
distributed system with more than one computer, processor, server or  
container or when you design and construct your own hardware processors  
and chips.

From a software perspective, it is sufficient to capture only those  
elements of an infrastructure that are needed to show a deployment of  
your building blocks. Hardware architects can go beyond that and  
describe an infrastructure to any level of detail they need to capture.

::: formalpara-title
**Motivation**
:::

⚠️ Software does not run without hardware. This underlying infrastructure  
can and will influence a system and/or some cross-cutting concepts.  
Therefore, there is a need to know the infrastructure.

::: formalpara-title
**Form**
:::

📊 Maybe a highest-level deployment diagram is already contained in section  
3.2 as technical context with your own infrastructure as ONE black box.  
In this section one can zoom into this black box using additional  
deployment diagrams:

- UML offers deployment diagrams to express that view. Use it,  
  probably with nested diagrams, when your infrastructure is more complex.  
- When your (hardware) stakeholders prefer other kinds of diagrams  
  rather than a deployment diagram, let them use any kind that is able  
  to show nodes and channels of the infrastructure.

::: formalpara-title
**Further Information**
:::

🔗 See [Deployment View](https://docs.arc42.org/section-7/)  
in the arc42 documentation.

## Infrastructure Level 1 {#_infrastructure_level_1}

Describe (usually in a combination of diagrams, tables, and text):

- distribution of a system to multiple locations, environments,  
  computers, processors, .., as well as physical connections between them  
- important justifications or motivations for this deployment structure  
- quality and/or performance features of this infrastructure  
- mapping of software artifacts to elements of this infrastructure

For multiple environments or alternative deployments, please copy and  
adapt this section of arc42 for all relevant environments.

***<Overview Diagram>***

Motivation

:   *<explanation in text form>*

Quality and/or Performance Features

:   *<explanation in text form>*

Mapping of Building Blocks to Infrastructure

:   *<description of the mapping>*

## Infrastructure Level 2 {#_infrastructure_level_2}

Here you can include the internal structure of (some) infrastructure  
elements from level 1.

Please copy the structure from level 1 for each selected element.

### <Infrastructure Element 1> {#_infrastructure_element_1}

*<diagram + explanation>*

### <Infrastructure Element 2> {#_infrastructure_element_2}

*<diagram + explanation>*

...

### <Infrastructure Element n> {#_infrastructure_element_n}

*<diagram + explanation>*

# Cross-cutting Concepts {#section-concepts}

::: formalpara-title
**Content**
:::

🧩 This section describes cross-cutting concepts (practices, patterns,  
regulations or solution ideas). Such concepts are often related to  
multiple building blocks. They may include many different topics, such  
as the topics shown in the following diagram:

![Possible topics for crosscutting
concepts](images/08-concepts-EN.drawio.png)

::: formalpara-title
**Motivation**
:::

🏗️ Concepts form the basis for *conceptual integrity* (consistency,  
homogeneity) of the architecture. Thus, they are an important  
contribution to achieve inner qualities of your system.

This is the place in the template that we provided for a cohesive  
specification of such concepts.

Many of these concepts relate to or influence several of your building blocks.

::: formalpara-title
**Form**
:::

📊 The form can be varied:

- concept papers with any kind of structure  
- example implementations, especially for technical concepts  
- cross-cutting model excerpts or scenarios using notations of the  
  architecture views

::: formalpara-title
**Structure**
:::

🎯 Pick **only** the most-needed topics for your system and assign each a  
level-2 heading in this section (e.g. 8.1, 8.2, etc).

DO NOT ATTEMPT to cover all of the topics of the aforementioned diagram.

::: formalpara-title
**Further Information**
:::

ℹ️ Some topics within systems often concern multiple building blocks,  
hardware elements or development processes. It might be easier to  
communicate or document such *cross-cutting* topics at a central  
location, instead of repeating them in the description of the concerned  
building blocks, hardware elements or development processes.

Certain concepts might concern **all** elements of a system, others  
might only be relevant for a few. In the diagram above, logging concerns  
all three components, whereas security is relevant only for two components.

🔗 See [Concepts](https://docs.arc42.org/section-8/)  
in the arc42 documentation.

## <Concept 1> {#_concept_1}

*<explanation>*

## <Concept 2> {#_concept_2}

*<explanation>*

...

## <Concept n> {#_concept_n}

*<explanation>*

# Architecture Decisions {#section-design-decisions}

::: formalpara-title
**Contents**
:::

🏁 Important, expensive, large-scale or risky architecture decisions  
including rationales. With "decisions" we mean selecting one  
alternative based on given criteria.

Please use your judgement to decide whether an architectural decision  
should be documented here in this central section or whether you better  
document it locally (e.g. within the white box template of one building block).

Avoid redundancy. Refer to section 4, where you already captured the  
most important decisions of your architecture.

::: formalpara-title
**Motivation**
:::

👥 Stakeholders of your system should be able to comprehend and retrace  
your decisions.

::: formalpara-title
**Form**
:::

📊 Various options:

- ADR ([Documenting Architecture  
  Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions))  
  for every important decision  
- List or table, ordered by importance and consequences or:  
- more detailed in form of separate sections per decision

::: formalpara-title
**Further Information**
:::

🔗 See [Architecture Decisions](https://docs.arc42.org/section-9/)  
in the arc42 documentation. There you will find links and examples about ADR.

# Quality Requirements {#section-quality-scenarios}

::: formalpara-title
**Content**
:::

📋 This section contains all relevant quality requirements.

The most important of these requirements have already been described in  
section 1.2 (quality goals), therefore they should only be referenced  
here. In this section 10, you should also capture quality requirements  
with lesser importance, which will not create high risks when they are  
not fully achieved (but might be *nice-to-have*).

::: formalpara-title
**Motivation**
:::

⚠️ Since quality requirements will have a lot of influence on architectural  
decisions, you should know what qualities are really important for your  
stakeholders, in a specific and measurable way.

- See [Quality Requirements](https://docs.arc42.org/section-10/) in  
  the arc42 documentation.  
- See the extensive [Q42 quality model on  
  https://quality.arc42.org](https://quality.arc42.org).

## Quality Requirements Overview {#_quality_requirements_overview}

::: formalpara-title
**Content**
:::

📊 An overview or summary of quality requirements.

::: formalpara-title
**Motivation**
:::

🧩 Often we encounter dozens (or even hundreds) of detailed quality  
requirements. In this overview section you should try to summarize, e.g.  
by describing categories or topics (as suggested by [ISO  
25010:2023](https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-2:v1:en)  
or [Q42](https://quality.arc42.org)).

If these summary descriptions are already precise, specific enough and  
measurable, you may skip section 10.2.

::: formalpara-title
**Form**
:::

📋 Use a simple table in which each line contains a category or topic and a  
short description of the quality requirement. Alternatively, you may use  
a mindmap to structure these quality requirements. In literature, the  
idea of a *quality attribute tree* has also been described, which puts  
the generic term "quality" as the root and uses a tree-like refinement  
of the term "quality". [Bass+21] introduced the term "Quality  
Attribute Utility Tree" for this purpose.

## Quality Scenarios {#_quality_scenarios}

::: formalpara-title
**Content**
:::

🎯 Quality scenarios make quality requirements concrete and allow to decide  
whether they are fulfilled (in the sense of acceptance criteria). Ensure  
that your scenarios are specific and measurable.

Two kinds of scenarios are especially useful:

- *Usage scenarios* (also called application scenarios or use case  
  scenarios) describe the system's runtime reaction to a certain stimulus.  
  This also includes scenarios that describe the system's efficiency or  
  performance. Example: The system reacts to a user's request within one second.  
- *Change scenarios* describe the desired effect of a modification or  
  extension of the system or of its immediate environment. Example:  
  Additional functionality is implemented or requirements for a  
  quality attribute change, and the effort or duration of the change  
  is measured.

::: formalpara-title
**Form**
:::

📊 Typical information for detailed scenarios include the following:

In short form (favoured in the Q42 model):

- **Context/Background**: What kind of system or component, what is  
  the environment or situation?  
- **Source/Stimulus**: Who or what initiates or triggers a behaviour,  
  reaction or action.  
- **Metric/Acceptance Criteria**: A response including a *measure* or  
  *metric*

The long form of scenarios (favoured by the SEI and [Bass+21]) is more  
detailed and includes the following information:

- **Scenario ID**: A unique identifier for the scenario.  
- **Scenario Name**: A short, descriptive name for the scenario.  
- **Source**: The entity (user, system, or event) that initiates the scenario.  
- **Stimulus**: The triggering event or condition the system must address.  
- **Environment**: The operational context or condition under which  
  the system experiences the stimulus.  
- **Artifact**: The building-blocks or other elements of the system  
  affected by the stimulus.  
- **Response**: The outcome or behavior the system exhibits in reaction  
  to the stimulus.  
- **Response Measure**: The criteria or metric by which the system's  
  response is evaluated.

::: formalpara-title
**Examples**
:::

🔗 See [the Q42 quality model website](https://quality.arc42.org) for  
detailed examples of quality requirements.

- Len Bass, Paul Clements, Rick Kazman: "Software Architecture in  
  Practice", 4th Edition, Addison-Wesley, 2021.

# Risks and Technical Debts {#section-technical-risks}

::: formalpara-title
**Contents**
:::

⚠️ A list of identified technical risks or technical debts, ordered by priority.

::: formalpara-title
**Motivation**
:::

🎯 "Risk management is project management for grown-ups" (Tim Lister,  
Atlantic Systems Guild.)

This should be your motto for systematic detection and evaluation of  
risks and technical debts in the architecture, which will be needed by  
management stakeholders (e.g. project managers, product owners) as part  
of the overall risk analysis and measurement planning.

::: formalpara-title
**Form**
:::

📋 List of risks and/or technical debts, probably including suggested  
measures to minimize, mitigate or avoid risks or reduce technical debts.

::: formalpara-title
**Further Information**
:::

🔗 See [Risks and Technical Debt](https://docs.arc42.org/section-11/)  
in the arc42 documentation.

# Glossary {#section-glossary}

::: formalpara-title
**Contents**
:::

📖 The most important domain and technical terms that your stakeholders use  
when discussing the system.

You can also see the glossary as source for translations if you work in  
multi-language teams.

::: formalpara-title
**Motivation**
:::

⚠️ You should clearly define your terms, so that all stakeholders

- have an identical understanding of these terms  
- do not use synonyms and homonyms

::: formalpara-title
**Form**
:::

📋 A table with columns `<Term>` and `<Definition>`.

Potentially more columns in case you need translations.

::: formalpara-title
**Further Information**
:::

🔗 See [Glossary](https://docs.arc42.org/section-12/)  
in the arc42 documentation.

+----------------------+-----------------------------------------------+
| Term                 | Definition                                    |
+======================+===============================================+
| *<Term-1>*           | *<definition-1>*                              |
+----------------------+-----------------------------------------------+
| *<Term-2>*           | *<definition-2>*                              |
+----------------------+-----------------------------------------------+


![airport.svg](/annotations/asset/1184)
![airport.png](/annotations/asset/1185)

# Titel: Kurz, aussagekräftig

## Status
✅ Accepted | ⚠️ Proposed | 🗑️ Deprecated | 🔄 Superseded

Wählen Sie den aktuellen Status dieser ADR und erklären Sie kurz,
falls nötig (z. B. wann sie akzeptiert oder deprecated wurde).

## Kontext und Problemstellung
🧩 Beschreiben Sie die Situation und das Problem, das Sie lösen wollen.

Erklären Sie:
- Was ist der aktuelle Kontext?
- Welches Problem haben wir?
- Warum braucht dies eine Architektur-Entscheidung?

## Entscheidungs-Drivers
🔑 Listen Sie die Schlüsselfaktoren auf, die die Entscheidung leiten.

Beispiele:
- Leistungsanforderungen
- Sicherheits constraints
- Kosten limits
- Wartbarkeit und Skalierbarkeit
- Team-Expertise

## Betrachtete Optionen
📋 Listen Sie alle Optionen auf, die Sie evaluiert haben.

- Option 1
- Option 2
- Option 3

Halten Sie diese Liste kurz, aber vollständig genug,
um den Trade-Space zu verstehen.

## Entscheidungs-Outcome
🏁 Gewählte Option: **"Option 1"**, weil sie die
Decision-Drivers bestmöglich erfüllt.

Erklären Sie kurz, warum diese Option gewählt wurde.
Sie können die Drivers explizit zitieren.

### Konsequenzen
➕ Gut:
- Gut, weil ...
- Gut, weil ...

➖ Schlecht:
- Schlecht, weil ...
- Schlecht, weil ...

⚪ Neutral:
- Neutral, weil ...
- Neutral, weil ...

Beschreiben Sie die Hauptwirkungen dieser Entscheidung,
sowohl positiv als auch negativ.

### Bestätigung
🔍 Beschreiben Sie, wie Sie prüfen, dass die Implementierung
diese ADR befolgt.

Beispiele:
- Code-Review-Checks
- Automatisierte Tests
- Dokumentations-Updates
- Architektur-Reviews

## Pros und Cons der Optionen

### Option 1
⭐ Pros:
- Gut, weil ...
- Gut, weil ...

⚪ Neutral:
- Neutral, weil ...

❌ Cons:
- Schlecht, weil ...
- Schlecht, weil ...

### Option 2
⭐ Pros:
- Gut, weil ...
- Gut, weil ...

⚪ Neutral:
- Neutral, weil ...

❌ Cons:
- Schlecht, weil ...
- Schlecht, weil ...

### Option 3
⭐ Pros:
- Gut, weil ...
- Gut, weil ...

⚪ Neutral:
- Neutral, weil ...

❌ Cons:
- Schlecht, weil ...
- Schlecht, weil ...

Führen Sie eine detaillierte Trade-off-Analyse für jede Option.

## Weitere Informationen
📚 Fügen Sie Links, Referenzen, verwandte ADRs oder
zusätzliche Notizen hier hinzu.

Beispiele:
- Links zu RFCs, Design-Docs oder Issue-Trackern
- Verwandte Architektur-Entscheidungen
- Referenzen zu Standards oder Best Practices
- Zusätzlicher Kontext, der nicht anderswo passt

## Emoji-Legende
ℹ️ Bedeutung der in dieser ADR verwendeten Emojis:

- ✅ = Accepted
- ⚠️ = Proposed
- 🗑️ = Deprecated
- 🔄 = Superseded
- 🧩 = Kontext/Problem
- 🔑 = Entscheidungs-Driver
- 📋 = Option
- 🏁 = Entscheidungs-Outcome
- 🔍 = Bestätigung
- 📚 = Weitere Informationen


# Title: Short, representative title

## Status
✅ Accepted | ⚠️ Proposed | 🗑️ Deprecated | 🔄 Superseded

Choose the current status of this ADR and explain briefly if needed (e.g., when it was accepted or deprecated).

## Context and Problem Statement
🧩 Describe the situation and the problem you are trying to solve.

Explain:
- What is the current context?
- What problem are we facing?
- Why does this need an architectural decision?

## Decision Drivers
🔑 List the key factors that guide the decision.

Examples:
- Performance requirements
- Security constraints
- Cost limits
- Maintainability and scalability
- Team expertise

## Considered Options
📋 List all options you evaluated.

- Option 1
- Option 2
- Option 3

Keep this list concise but complete enough to understand the trade space.

## Decision Outcome
🏁 Chosen option: **"Option 1"**, because it best satisfies the decision drivers.

Briefly explain why this option was chosen. You can reference the drivers explicitly.

### Consequences
➕ Good:
- Good, because ...
- Good, because ...

➖ Bad:
- Bad, because ...
- Bad, because ...

⚪ Neutral:
- Neutral, because ...
- Neutral, because ...

Describe the main impacts of this decision, both positive and negative.

### Confirmation
🔍 Describe how you will verify that the implementation follows this ADR.

Examples:
- Code review checks
- Automated tests
- Documentation updates
- Architecture reviews

## Pros and Cons of the Options

### Option 1
⭐ Pros:
- Good, because ...
- Good, because ...

⚪ Neutral:
- Neutral, because ...

❌ Cons:
- Bad, because ...
- Bad, because ...

### Option 2
⭐ Pros:
- Good, because ...
- Good, because ...

⚪ Neutral:
- Neutral, because ...

❌ Cons:
- Bad, because ...
- Bad, because ...

### Option 3
⭐ Pros:
- Good, because ...
- Good, because ...

⚪ Neutral:
- Neutral, because ...

❌ Cons:
- Bad, because ...
- Bad, because ...

Provide a more detailed trade-off analysis for each option.

## More Information
📚 Add links, references, related ADRs, or extra notes here.

Examples:
- Links to RFCs, design docs, or issue trackers
- Related architectural decisions
- References to standards or best practices
- Extra context that doesn’t fit elsewhere

## Emoji Legend
ℹ️ Meaning of emojis used in this ADR:

- ✅ = Accepted
- ⚠️ = Proposed
- 🗑️ = Deprecated
- 🔄 = Superseded
- 🧩 = Context/problem
- 🔑 = Decision driver
- 📋 = Option
- 🏁 = Decision outcome
- 🔍 = Confirmation
- 📚 = More information


> Demo note: generated by `--seed-demo` for demonstration only — replace it with your own assessment.

![analysis.svg](/annotations/asset/1186)
![analysis.png](/annotations/asset/1187)

_Maturity Level 2 - Managed._

_Maturity Level 3 - Established._

_Maturity Level 4 - Predictable._

_Maturity Level 5 - Innovating._

_Maturity Level 1 - Performed._

_Maturity Level 4 - Predictable._