Explicit Tradeoff Policies

Systemproblem

In der Systemtheorie gibt es keine "Lösungen", es gibt nur "Trade-offs" (Kompromisse/Preise, die gezahlt werden müssen). Wenn das Management ein Projekt fordert, das "Maximale Security, in Rekordzeit, ohne zusätzliche Kosten" liefert, fordert es ein physikalisches Märchen. Entwickler beugen sich oft diesem Druck und bauen ein Frankenstein-System (Big Ball of Mud), das heimlich an allen Ecken blutet, weil die inhärenten Widersprüche nie offen auf den Tisch gelegt wurden. Wenn Trade-offs implizit bleiben, crasht das System unerwartet in der Produktion.

Intervention

"Explicit Tradeoff Policies" (Explizite Kompromiss-Regeln) ist der Zwang zur brutalen Ehrlichkeit. Jedes *Architecture Decision Record (ADR)*, jedes Feature-Konzept und jedes Management-Meeting muss zwingend mit der Nennung des "Preises" beginnen. Wenn ein Architekt vorschlägt: "Wir machen jetzt Microservices für bessere Skalierbarkeit", muss er im selben Atemzug die Policy deklarieren: "Unser Trade-Off ist die Aufgabe von ACID-Datenbank-Eigenschaften. Wir akzeptieren Daten-Inkonsistenz für 5 Minuten."

Erwartete Wirkung

Die Qualität der strategischen Debatte im Unternehmen explodiert. Das ständige "Finger-Pointing" zwischen IT und Business hört auf. Wenn das Business 6 Monate später klagt "Warum sind die Kundendaten asynchron?", zieht die IT das unterschriebene Dokument aus der Tasche: "Hier ist eure Unterschrift unter der Trade-off Policy von damals. Wir haben Konsistenz geopfert, um eure geforderte Black-Friday Performance zu erreichen." Es entsteht eine reife, erwachsene Ingenieurskultur.

Nebenwirkungen und Risiken

Es erfordert immenses Rückgrat von CTOs und Architekten. Die Politik vieler Firmen bestraft Überbringer schlechter Nachrichten. Ein Architekt, der dem Vorstand sagt "Wir können das Feature A nicht bauen, ohne die Stabilität B zu gefährden", läuft Gefahr, als "Bedenkenträger" blockiert zu werden. Die Intervention kann nur gelingen, wenn das Management systemisch geschult wurde und akzeptiert, dass Softwarearchitektur einem "Nullsummenspiel" gleicht.

Diagramm

Wann diese Intervention wirksam wird

Mark Richards und Neal Ford ("Fundamentals of Software Architecture") nennen das Abwägen von Qualitäten (Die "-ilities": Scalability, Security, Maintainability) den absoluten Kernberuf des Architekten. Die genialste Methode, Trade-offs explizit zu machen, ist der Schieberegler (Slider-Methode). Gib dem Product Owner 100 Punkte. Er muss sie auf "Time to Market", "Security" und "Performance" verteilen. Wenn er eines hochzieht, *muss* er ein anderes herunterziehen. Das visualisiert die physikalischen Grenzen des Systems.

Wodurch sich diese Intervention von anderen Hebeln unterscheidet

*Boundary Reframing* zwingt Stakeholder, ihre Augen für Dinge außerhalb ihres Silos zu öffnen. *Explicit Tradeoff Policies* ist der noch härtere Schritt: Es zwingt Stakeholder formal zu akzeptieren, dass ihr neu entdeckter Wunsch "X" zwingend die Zerstörung von Eigenschaft "Y" zur Folge haben wird.

Wie du die Intervention sauber einleitest

Akzeptiere keine Jira-Tickets oder Epic-Stories, die nur positive Ziele ("User kann sich schneller einloggen") formulieren. Ergänze im Ticket-Template zwingend das Feld "Negative Side Effects (Trade-offs) wir sind bereit in Kauf zu nehmen". Wenn dieses Feld leer bleibt, hat der Ticket-Autor das kybernetische System nicht verstanden und das Ticket wird abgelehnt.

Erste Umsetzungsschritte

Verwende das "CAP Theorem" (Consistency, Availability, Partition Tolerance) als das perfekte Lehrbeispiel für Trade-offs. Zeige Entwicklern: "Selbst die klügsten Mathematiker der Welt können das CAP-Theorem nicht umgehen. Ihr müsst 2 aus 3 wählen. Also hört auf so zu tun, als könnten wir alle drei haben. Wählt eure 2 aus."

Woran du Wirkung erkennst

Haben wir die "Trade-Offs" unserer Kernarchitektur (z.B. "Wir optimieren auf Entwickler-Geschwindigkeit, auf Kosten von Cloud-Computing-Rechnungen") nicht nur im Kopf der Architekten, sondern als verschriftlichtes Leitbild im Onboarding-Prozess jedes neuen Entwicklers verankert?

Quellen

Gregor Hohpe — The Software Architect Elevator, Kap. 8: Tradeoffs (O'Reilly, 2020)

Mark Richards & Neal Ford — Fundamentals of Software Architecture (O'Reilly, 2020)

Wikipedia: Trade-Off