Interdependence
Elemente in einem System sind wechselseitig abhängig; man kann keinen Teil isoliert verändern, ohne das Ganze zu beeinflussen.
Was ist das?
Elemente in einem System sind wechselseitig abhängig; man kann keinen Teil isoliert verändern, ohne das Ganze zu beeinflussen.
Warum relevant?
Nutze dieses Konzept, um beobachtbares Verhalten nicht nur zu benennen, sondern strukturell zu erklären.
Nächster Schritt
Prüfe danach, welcher Archetyp oder welche Diagnose das Muster im konkreten System sichtbar macht.

Definition
Interdependenz (Wechselseitige Abhängigkeit) drückt aus, dass in einem System alle Komponenten über verschiedene Grade der Kopplung miteinander verbunden sind. Das Handeln oder die Zustandsänderung eines Elements beeinflusst zwangsläufig andere Elemente, die ihrerseits wieder auf das erste Element oder Dritte zurückwirken. Solange starke Interdependenzen herrschen, sind lokale (isolierte) Lösungsansätze zwecklos oder sogar schädlich.
Systemmechanismus
Stell dir ein riesiges Spinnennetz vor. Zupfst du an einem äußeren Faden, vibriert sofort auch der Kern. In Organisationen und IT-Systemen bedeutet Interdependenz, dass Ressourcen geteilt (APIs, Datenbanken), Informationen ausgetauscht oder Ziele konkurrierend verfolgt werden. Eine lokale Optimierung auf der einen Seite zwingt fast immer eine Ausgleichsreaktion auf der anderen Seite des "Netzes" herbei.
Architekturbeispiel
In einer verteilten Microservice-Architektur ändert Team A das Schema eines vermeintlich lokalen Datenobjekts, um Schreiboperationen effizienter zu gestalten. Wegen tiefer, unbemerkter semantischer Interdependenzen (sogenannter "Distributed Monolith") bricht drei Tage später das monatliche Reporting in Team B ab, und Team C liefert falsche Berechnungsergebnisse im Checkout aus. Die Architektur hat es versäumt, die Interdependenzen durch klare, lose gekoppelte Verträge (Anti-Corruption Layers) zu steuern.
Organisationsbeispiel
Ein Unternehmen besteht zu oft aus rein vertikalen Silos (Dev, QA, Ops, Security), deren Ziele eigentlich stark interdependent sind. Die Dev-Abteilung wird für neue Features (Geschwindigkeit) belohnt, die Security-Abteilung für Null-Fehler-Toleranz. Diese tiefe Interdependenz im Wertstrom, gekoppelt mit gegensätzlichen Zielen, führt zu toxischen Konflikten bei jedem Release. Die Lösung liegt nicht im "besseren Kommunizieren", sondern in der Auflösung des Modells hin zu cross-funktionalen Teams.
Diagnosefragen
1.Wo versuchen wir gerade, eine "technische Komponente" isoliert zu optimieren, obwohl sie extrem an drei andere Systeme (und deren Teams) gekoppelt ist?
2.Wo gibt es versteckte Interdependenzen (z.B. geteilte Infrastruktur, geteiltes Wissen eines Senior-Entwicklers), die bei hohem Stress zum Flaschenhals werden?
3.Welche organisatorischen Teams hängen aneinander, obwohl ihre Zielvorgaben in völlig unterschiedliche Richtungen deuten?
Diagramm
Warum dieses Konzept in Architektur hilft
Architekten müssen Experten im Design von "Boundaries" (Grenzen) werden, um Interdependenzen handhabbar zu machen. Die Kunst ist es, die Architektur so zu schneiden (z.B. via Domain-Driven Design), dass Dinge, die eng miteinander interagieren müssen (hohe Kohäsion), zusammenliegen, und Dinge, die wenig Berührungspunkte haben, voneinander getrennt werden (lose Kopplung). Dadurch minimiert man destruktive Interdependenzen über Systemgrenzen hinweg.
Woran du das Konzept von ähnlichen Themen unterscheidest
Während sich die *Systemgrenzen* (System Boundaries) damit beschäftigen, was innerhalb oder außerhalb unserer Betrachtung liegt, betrachtet *Interdependenz* explizit den Vernetzungsgrad der Bestandteile untereinander. Der Archetyp *Accidental Adversaries* ist beispielsweise ein exzellentes Muster für völlig aus dem Ruder gelaufene Interdependenz.
Wie du das Konzept praktisch nutzt
Achte bei Architekturentscheidungen und Reorgs primär auf die Abhängigkeiten (Interfaces). Optimiere niemals den Zustand eines einzelnen Teils, wenn die Optimierung die Interaktionen mit anderen Teilen verschlechtert. Leitsatz von Russell Ackoff: "Die Leistungsfähigkeit eines Systems hängt davon ab, wie die Teile interagieren, nicht davon, wie sie unabhängig voneinander agieren."
Erste Umsetzungsschritte
Führe Techniken wie Dependency-Mapping oder Design Structure Matrices (DSM) ein, um die unsichtbare Vernetzung (und damit Interdependenz) zwischen Code-Modulen oder Entwicklungsteams grafisch sichtbar zu machen, bevor Großprojekte in die Konzeption gehen.
Woran du Wirkung erkennst
Wurde bei der Einführung des neuen Tools / Microservices dokumentiert, wer stromabwärts und stromaufwärts in direkter technischer oder fachlicher Abhängigkeit steht?
Quellen
Donella Meadows — Thinking in Systems, Kap. 3: System Interconnections
Russell Ackoff — Re-Creating the Corporation (Oxford UP, 1999)
Authors & Books
Zur ReferenzseitePassende Referenzen zum Thema Interdependence.
Concept Visual
Interdependence: Teilsysteme beeinflussen sich kontinuierlich gegenseitig.