vault backup: 2026-01-19 20:14:22

.obsidian/types.json

@@ -54,6 +54,9 @@
     "gilde": "multitext",
     "gekauft": "checkbox",
     "Erstaustrahlung_USA": "date",
-    "Folge": "number"
+    "Folge": "number",
+    "deciders": "multitext",
+    "consulted": "multitext",
+    "informed": "multitext"
   }
 }

Resources/Templates/process-architectural-decision-record.md

@@ -0,0 +1,56 @@
+---
+title:
+status:
+date:
+deciders:
+consulted:
+informed:
+---
+# Title
+## Context and Problem Statement
+
+## Decision Drivers
+
+## Considered Options
+
+## Chosen Option/Decision Outcome
+
+## Consequences
+
+## Validation/Confirmation
+
+## More Information
+
+
+# AD: System Decomposition into Logical Layers
+
+## Context and Problem Statement
+
+Which concept is used to decompose the system under construction into logical building blocks?
+
+## Decision Drivers
+
+* Desire to divide the overall system into manageable parts to reduce complexity
+* Ability to exchange system parts without affecting others
+
+## Considered Options
+
+1. Layers pattern 
+2. Pipes-and-filters
+3. Workflow
+
+## Decision Outcome
+
+We decided to apply the Layers pattern and neglected other decomposition pattern such as pipes-and-filters or workflow because the system under construction and its capabilities do not suggest an organization by data flow or control flow. Technology is expected to be primary driver of change during system evolution. 
+
+### Consequences
+
+* Good, because the Layers pattern provides high flexibility regarding technology selections within the layers (changeability) and enables teams to work on system parts in parallel.
+* Bad, because there might be a performance penalty for each level of indirection and some undesired replication of implementation artifacts.
+
+## More Information
+
+* The three decomposition options come from the Cloud Computing Pattern [Distributed Application](https://www.cloudcomputingpatterns.org/distributed_application/).
+* The Layers pattern is featured in POSA Volume 1, see <http://www.dre.vanderbilt.edu/~schmidt/POSA-tutorial.pdf>
+
+A follow-on decision will be required to assign logical layers to physical tiers.

Übersicht/SOP/Architektur Entscheidungen.md

@@ -0,0 +1,29 @@
+---
+tags:
+  - process/sop
+---
+
+# Ziel und Zweck
+
+Die Nachverfolgung der Architektur Entscheidungen soll über Architecture Decision Records (ADR) erfolgen.
+Die Beschreibung der Erzeugung von ADR ist in den  [[Architektur Entscheidungen#Referenzen|Referenzen]] beschrieben.
+
+Die Erzeugung von ADR mit Hilfe eines Templates ([[process-architectural-decision-record]]) unterstützt.
+
+# Referenzen
+
+- [Gut dokumentiert: Architecture Decision Records](https://www.heise.de/hintergrund/Gut-dokumentiert-Architecture-Decision-Records-4664988.html?seite=all)
+- https://github.com/npryce/adr-tools
+- https://adr.github.io/
+- https://medium.com/olzzio/how-to-create-architectural-decision-records-adrs-and-how-not-to-93b5b4b33080
+- https://medium.com/olzzio/how-to-review-architectural-decision-records-adrs-and-how-not-to-2707652db196
+- [The Markdown ADR (MADR) Template Explained and Distilled](https://www.ozimmer.ch/practices/2022/11/22/MADRTemplatePrimer.html)
+
+# Weitergehende Informationen
+
+Ausschnitt aus [The Markdown ADR (MADR) Template Explained and Distilled](https://www.ozimmer.ch/practices/2022/11/22/MADRTemplatePrimer.html):
+ADRs help you keep **CALM** because they ease AD making and capturing:
+- **C**ollaborative content creation is enabled.
+- **A**ccountability is supported and unnecessary reconsideration of issues avoided.
+- **L**earning opportunities are provided, both for newcomers and for the experienced.
+- **M**anagement likes them too because it is used to making and executing decisions.

Übersicht/SOP/Journal SOP.md

@@ -1,6 +1,5 @@
 ---
 id: Journal SOP
-aliases: []
 tags:
   - process/sop
 rework: true