Boundary Reframing

Systemproblem

In gescheiterten Projekten lautet der Satz oft: "Die Architektur funktioniert nicht wie gewollt". Das wahre Problem liegt aber meist darin, dass die Problem-Grenze (Boundary) in das falsche Bezugssystem gesetzt wurde. Wenn Entwickler klagen "Unsere Datenbank ist zu langsam" und das Management anordnet "Kauft größere Server", liegt der Fokus ("Frame") rein auf Hardware. Wenn die Wurzel des Problems aber ein fehlerhaftes UX-Design auf der Webseite ist, das User zu endlosen Klick-Orgien und Query-Spamming zwingt, ist der Rahmen zu eng gewählt.

Intervention

"Boundary Reframing" zwingt alle Stakeholder, den Zoom-Faktor des Problemraums brutal aufzuziehen oder zu verschieben. Es ist die kognitive Weigerung des Architekten, ein isoliertes Symptom als eigenständiges Problem zu akzeptieren. Du verschiebst die Boundary aktiv von "Technik" auf "Organisation" oder von "Mein Team" auf "Der gesamte Konzern". Du zwingst das Management, die externen, weggewischten Variablen (Externalities) wieder in die Gleichung aufzunehmen.

Erwartete Wirkung

Plötzlich verschwindet das unlösbare lokale Problem, weil es auf einer höheren systemischen Ebene aufgelöst wird. Das ständige Debuggen der überlasteten Datenbank stoppt, weil durch das Reframing auf den Bereich "User UX" die überflüssigen Requests auf Seiten des Frontends komplett herausdesigned werden. Riesige Budgets, die für lokales "Fire-Fighting" reserviert waren, können stattdessen für strukturelle, radikale Verbesserungen ausgegeben werden.

Nebenwirkungen und Risiken

"Scope Creep" ist die gefährlichste Nebenwirkung. Wenn man den Rahmen von "Die Datenbank ist kaputt" auf "Der gesamte Geschäftsprozess der Firma ist fehlerhaft" vergrößert, riskiert man "Boiling the Ocean". Das Team fühlt sich plötzlich für Probleme verantwortlich, die so gigantisch sind, dass sie handlungsunfähig werden (Analysis Paralysis). Führungskräfte reagieren zudem oft sehr politisch und allergisch auf Reframing, wenn man zeigt, dass "ihr" lokales Problem in Wahrheit die Schuld auf "eine andere Abteilung" schiebt.

Diagramm

Wann diese Intervention wirksam wird

Einer der stärksten Hebel in der Systemtheorie ist das "Transcending Paradigms" (Transzendieren von Systemen). Boundary Reframing ist die Vorbereitung dazu. Es verhindert den klassischen Architekten-Wahn der "Sub-Optimierung" (Sub-Optimization), bei der ein einzelnes Microservice-Team seinen Algorithmus um 0,5 Millisekunden optimiert, während der HTTP-Aufruf im Netzwerk ohnehin 200 Millisekunden Delay des Gesamt-End-Users ausmacht.

Wodurch sich diese Intervention von anderen Hebeln unterscheidet

*Boundary Design* (die physische Restrukturierung von Code und Teams) kann erst stattfinden, NACHDEM das *Boundary Reframing* stattgefunden hat. Reframing ist der mentale Klick-Moment im Gehirn des Managements. Es holt das Problem aus der falschen Schublade heraus. Erst wenn alle zustimmen: "Ja, dies ist kein Ops-Problem, das ist ein Requirement-Engineering Problem", beginnt das Boundary Design.

Wie du die Intervention sauber einleitest

Wenn jemand auf einem Meeting ruft "Das liegt außerhalb unseres Scopes!", antworte sofort: "Dann haben wir den Scope fundamental falsch definiert." Zwinge das Projektteam, einmal im Monat das Whiteboard zu nehmen und alle Dinge aufzulisten, die sie insgeheim unter die Teppichkante der Ignoranz kehren ("Da können wir eh nichts dran ändern"). Wähle das schlimmste dieser Themen aus und hole es per Reframing aktiv in die Verantwortung des Projektplans zurück.

Erste Umsetzungsschritte

Nutze die Metapher von "Upstream" VS "Downstream". Wenn das Operations-Team ständig ertrinkt (Downstream), ist das Flicken von Booten die falsche Boundary. Das Reframing erfordert es, den Fluss hinauf (Upstream) zu den Developern zu wandern und dort die Qualitätssicherung der Code-Übergaben als echtes, gemeinsames System-Ziel zu deklarieren.

Woran du Wirkung erkennst

Gibt es einen klaren Moderations-Prozess in unseren Architekturengpässen, der verhindert, dass wir Millionen in ein technisches "Fixes that Fail" Szenario pumpen, nur weil wir uns weigern, den organisatorischen Systemrahmen größer aufzuziehen?

Quellen

Gerald Midgley — Systemic Intervention, Kap. 5: Boundary Judgments (Springer, 2000)

Werner Ulrich — Critical Heuristics of Social Planning (Haupt, 1983)

Wikipedia: Framing (Social Sciences))