Policy Structure Mapping

Zweck

In der Systemtheorie (insbesondere in *System Dynamics*) ist eine "Policy" keine textuelle Firmen-Richtlinie im Intranet, sondern die ungeschriebene mathematische Gleichung, nach der Akteure ihre täglichen Entscheidungen treffen. "Policy Structure Mapping" diagnostiziert, warum intelligente Entwickler oftmals dumme Systeme bauen. Es lenkt den Blick weg vom geschriebenen Code, hin zu den Belohnungs- und Bestrafungsregeln (Policies), die den Code hervorbringen. Es deckt auf, dass Architektur-Erosion selten ein technisches, sondern fast immer ein rationales Policy-Problem ist.

Einsatzkontext

Wenn das Management klagt: "Wir haben doch vor 6 Monaten beschlossen, dass wir Tech Debt abbauen, warum schreibt das Team immer noch so schmutzigen Code?", ist die Zeit für ein Policy Structure Mapping gekommen. Die geschriebene Policy ist "Qualität", aber die gelebte Policy ist "Feature-Delivery um jeden Preis". Das Mapping wird genutzt, um diese Diskrepanz brutal sichtbar zu machen.

Schritt für Schritt

1.Das Symptom benennen: Was ist das unerwünschte Verhalten der Organisation? (z.B. Niemand schreibt Dokumentation).

2.Die Informationsflüsse mappen: Welche Signale erhält ein Akteur in dem Moment, wo er die Entscheidung trifft? (Der Dev sieht: Der Release-Termin ist morgen, der Sprint blutet).

3.Die Ist-Zustand Policy formulieren: Schreibe die harte "If-Then" Regel auf, nach der der Akteur insgeheim handelt. (z.B. "IF Feature-Druck > Schamgefühl THEN überspringe Unit-Tests").

4.Den Leverage Point finden: Welche dieser Informations-Zuleitungen zur Policy können wir strukturell verändern, damit der Akteur eine bessere Entscheidung treffen *möchte*?

Beispiel

Die Architektur zerfällt, weil Plattform-Teams ständig Features für Produkt-Teams in den Kern einbauen, anstatt eine saubere API zur Verfügung zu stellen. Die Ist-Zustand-Policy des Plattform-Engineers lautet: "Wenn der Vertrieb Druck macht, baue ich den Hack selbst in mein Backend ein, weil das schneller geht, als zwei Wochen lang Schnittstellen-Design mit dem Frontend-Team zu verhandeln". Der Architekt betreibt Policy Mapping und ändert den Informationsfluss (Intervention): Ab sofort wird "Ticket-Speed" für das Plattform-Team nicht mehr gemessen. Die neue Policy-Regel für Boni lautet: "Anzahl der Self-Service-APIs, die externe Teams autark nutzen". Das Verhalten des Plattform-Teams dreht sich in einer Woche um 180 Grad.

Diagramm

Wie aus Diagnose Handlung wird

Architekten versagen oft, weil sie "Appelle" (Mahnungen in All-Hands-Meetings) mit "Policies" verwechseln. Ein Appell ändert nichts an der Struktur. Eine Policy ist eine verdrahtete Feedbackschleife. Wenn CTOs predigen "Wir müssen stabiler deployen", aber gleichzeitig den Entwicklern den Bonus kürzen, wenn ein neues Feature zu spät auf den Markt kommt, gewinnt immer die finanzielle Policy gegen den moralischen Appell. Policy Mapping holt diese Heuchelei in Diagramm-Form an das Whiteboard.

Wann diese Methode die richtige ist

*Causal Loop Diagrams (CLDs)* zeigen das gesamte Netzgewirr aller Variablen auf. Das *Policy Structure Mapping* zoomt jedoch wie ein Mikroskop auf einen einzigen, winzigen Knoten im CLD ("Die menschliche Entscheidung") und seziert, welche Hebel exakt in diesen Knoten hineinwirken.

Wie du die Diagnose im Alltag einsetzt

Akzeptiere nie die Erklärung "Menschliches Versagen" in Post-Mortem-Dokumenten. Wenn ein Senior Dev die Datenbank gelöscht hat, weil er das Skript nicht lokal getestet hat, frage nach der Policy: Wurden lokale Test-Environments aus Kostengründen abgeschafft? Wird das Team für "Heldentum" in Produktions-Ausfällen gefeiert, anstatt für langweilige, unauffällige Stabilität? Das System hat exakt das Verhalten produziert, auf das es konfiguriert war.

Erste Analyse-Schritte

Zeichne bei Policy-Workshops "Informations-Pfeile" (Was weiß der Agent?) strikt farblich getrennt von "physischen Pfeilen" (Was tut der Agent?). Eine schlechte Entscheidung wird immer dadurch getroffen, dass der Informations-Pfeil über die negativen Konsequenzen der Architektur (z.B. Latenz-Erhöhung für den Nutzer) nicht in das Armaturenbrett (Policy) des Backend-Entwicklers geroutet wurde.

Woran du eine brauchbare Diagnose erkennst

Können wir die tatsächliche Beförderungs- und Bonus-Logik unseres Unternehmens offen auf das Architektur-Board legen und prüfen, ob diese finanziellen "Regeln" unsere technischen Design-Prinzipien (z.B. "Decoupling") gerade heimlich sabotieren?

Quellen

John Sterman — Business Dynamics, Kap. 9: Policy Structure (McGraw-Hill, 2000)

Donella Meadows — Thinking in Systems, Kap. 5: System Traps and Policies

Wikipedia: System Dynamics