Merge pull request #590 from raifdmueller/feat/strategic-analysis-contract

feat(contracts): add Strategic Architecture Analysis contract

Author: rdmueller

docs/changelog.adoc

@@ -2,6 +2,12 @@
 
 A chronological record of all semantic anchors added to the catalog. Community contributors are credited with thanks.
 
+== 2026-06-09
+
+*New contracts:*
+
+* *Strategic Architecture Analysis* — a strategic-analysis recipe that combines four lenses with the questions they answer: Wardley Mapping (how each component evolves), the Cynefin Framework (match the response to the domain), a Morphological Box (explore the option space deliberately instead of anchoring on the first design), ATAM (weigh tradeoffs against the quality goals), and the Five Whys (drill to the root cause); for build-vs-buy decisions, architecture-fitness reviews, and strategic technology-radar reviews
+
 == 2026-06-08
 
 *Refined contracts:*

website/public/contracts.txt

@@ -1,6 +1,6 @@
 # Semantic Contracts
 
-> 18 composable contracts that define what terms mean in your project —
+> 19 composable contracts that define what terms mean in your project —
 > by composing established Semantic Anchors or by providing custom team definitions.
 > Add them to your AGENTS.md or CLAUDE.md.
 > Source: https://github.com/LLM-Coding/Semantic-Anchors
@@ -273,3 +273,21 @@ Composes: *TDD, London School*, *TDD, Chicago School*, *Red-Green-Refactor*, *IO
 Sources: https://ralfw.de/hamburg-style-tdd/, https://ralfw.de/tdd-how-it-can-be-done-right/
 
 *Referenced anchors: red-green-tdd, tdd-london-school, tdd-chicago-school, iosp*
+
+## Strategic Architecture Analysis
+
+_How we analyze architecture strategically — mapping evolution, classifying complexity, exploring the option space, and weighing tradeoffs_
+
+Strategic architecture analysis combines four lenses, each for a different question. Reach for it when evaluating build-vs-buy, assessing architecture fitness for changing requirements, or running a strategic technology-radar review.
+
+Map the value chain with Wardley Mapping to see how each component evolves — what is commodity, what is genesis, and where the strategic differentiation actually sits.
+
+Classify each challenge with the Cynefin Framework — Clear, Complicated, Complex, or Chaotic — so the response fits the domain instead of forcing one playbook onto every problem.
+
+When a decision has a wide solution space, lay the dimensions and their options out in a Morphological Box and combine them deliberately, rather than anchoring on the first design that comes to mind.
+
+Evaluate the shortlisted architectures against the quality goals with ATAM, naming the sensitivity points, the tradeoff points, and the risks each option carries.
+
+When the root cause of a problem stays unclear, drill down with the Five Whys before committing to a direction.
+
+*Referenced anchors: wardley-mapping, cynefin-framework, morphological-box, atam, five-whys*

website/public/data/contracts.json

@@ -213,5 +213,16 @@
     "template": "Design-led TDD recipe by Ralf Westphal — close the requirements/logic gap before writing code, then test at service boundaries with minimal mocking. Use it when the problem is too complex for pure micro-step Red-Green-Refactor.\n\n- **ACD cycle (Analyze → Design → Code)** precedes the test loop: first model the solution to close the gap between requirements and logic, only then code.\n- **\"Right from the start\" philosophy** — implement correctly the first time so refactoring is a correction, not routine cleanup.\n- **Service-level testing** — test behind the public API, independent of API technology.\n- **Minimal mocking** — closer to *TDD, Chicago School* than *London School*.\n- **IOSP (Integration Operation Segregation Principle)** — a function is either composition (Integration) or logic (Operation), never both; structural support for simple unit tests.\n- **Deep Work over Small Steps** — accept that some problems can't be sliced into tiny green increments; stay red longer when the design demands it.\n\nComposes: *TDD, London School*, *TDD, Chicago School*, *Red-Green-Refactor*, *IOSP*.\nSources: https://ralfw.de/hamburg-style-tdd/, https://ralfw.de/tdd-how-it-can-be-done-right/",
     "templateDe": "Design-geführtes TDD-Rezept nach Ralf Westphal — die Lücke zwischen Anforderungen und Logik vor dem Codieren schließen, dann an Servicegrenzen mit minimalem Mocking testen. Anwenden, wenn das Problem zu komplex für reines micro-step Red-Green-Refactor ist.\n\n- **ACD-Zyklus (Analyze → Design → Code)** geht dem Test-Loop voraus: zuerst die Lösung modellieren, um die Lücke zwischen Anforderungen und Logik zu schließen, erst dann codieren.\n- **\"Right from the start\"-Philosophie** — beim ersten Mal korrekt implementieren, sodass Refactoring eine Korrektur ist, keine Routinebereinigung.\n- **Service-Level-Testing** — hinter der öffentlichen API testen, unabhängig von der API-Technologie.\n- **Minimales Mocking** — näher an *TDD, Chicago School* als an *London School*.\n- **IOSP (Integration Operation Segregation Principle)** — eine Funktion ist entweder Komposition (Integration) oder Logik (Operation), niemals beides; strukturelle Unterstützung für einfache Unit-Tests.\n- **Deep Work statt Small Steps** — akzeptieren, dass manche Probleme nicht in kleine grüne Inkremente zerlegt werden können; länger rot bleiben, wenn das Design es erfordert.\n\nKomponiert: *TDD, London School*, *TDD, Chicago School*, *Red-Green-Refactor*, *IOSP*.\nQuellen: https://ralfw.de/hamburg-style-tdd/, https://ralfw.de/tdd-how-it-can-be-done-right/",
     "category": "development"
+  },
+  {
+    "id": "strategic-architecture-analysis",
+    "title": "Strategic Architecture Analysis",
+    "titleDe": "Strategische Architekturanalyse",
+    "description": "How we analyze architecture strategically — mapping evolution, classifying complexity, exploring the option space, and weighing tradeoffs",
+    "descriptionDe": "Wie wir Architektur strategisch analysieren — Evolution kartieren, Komplexität einordnen, den Optionsraum erkunden und Tradeoffs abwägen",
+    "anchors": ["wardley-mapping", "cynefin-framework", "morphological-box", "atam", "five-whys"],
+    "template": "Strategic architecture analysis combines four lenses, each for a different question. Reach for it when evaluating build-vs-buy, assessing architecture fitness for changing requirements, or running a strategic technology-radar review.\n\nMap the value chain with Wardley Mapping to see how each component evolves — what is commodity, what is genesis, and where the strategic differentiation actually sits.\n\nClassify each challenge with the Cynefin Framework — Clear, Complicated, Complex, or Chaotic — so the response fits the domain instead of forcing one playbook onto every problem.\n\nWhen a decision has a wide solution space, lay the dimensions and their options out in a Morphological Box and combine them deliberately, rather than anchoring on the first design that comes to mind.\n\nEvaluate the shortlisted architectures against the quality goals with ATAM, naming the sensitivity points, the tradeoff points, and the risks each option carries.\n\nWhen the root cause of a problem stays unclear, drill down with the Five Whys before committing to a direction.",
+    "templateDe": "Strategische Architekturanalyse kombiniert vier Perspektiven, jede für eine andere Frage. Anwenden bei Build-vs-Buy-Entscheidungen, bei der Bewertung der Architektur-Eignung für sich ändernde Anforderungen oder bei einem strategischen Technologie-Radar-Review.\n\nDie Wertschöpfungskette mit Wardley Mapping kartieren, um zu sehen, wie sich jede Komponente entwickelt — was Commodity ist, was Genesis, und wo die strategische Differenzierung tatsächlich liegt.\n\nJede Herausforderung mit dem Cynefin Framework einordnen — Clear, Complicated, Complex oder Chaotic — damit die Reaktion zur Domäne passt, statt jedem Problem dasselbe Vorgehen aufzuzwingen.\n\nHat eine Entscheidung einen weiten Lösungsraum, die Dimensionen und ihre Optionen in einem Morphologischen Kasten ausbreiten und bewusst kombinieren, statt sich am erstbesten Entwurf festzubeißen.\n\nDie verbleibenden Architekturen mit ATAM gegen die Qualitätsziele bewerten und dabei Sensitivitätspunkte, Tradeoff-Punkte und die Risiken jeder Option benennen.\n\nBleibt die Ursache eines Problems unklar, mit den Five Whys nachbohren, bevor eine Richtung festgelegt wird.",
+    "category": "architecture"
   }
 ]