STfA
concepts

Interdependence

Elemente in einem System sind wechselseitig abhängig; man kann keinen Teil isoliert verändern, ohne das Ganze zu beeinflussen.

technologyteamsorganization·3 min Lesezeit

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.

~3 Min. Lesezeit
Hero Bild für Interdependence

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

Systemdiagramm für Interdependence
Diagramm: Interdependence

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)

Wikipedia: Interdependence

Authors & Books

Zur Referenzseite

Passende Referenzen zum Thema Interdependence.

Concept Visual

Service AService BTeam XPlatformTeam YEine Änderung an einem Knoten wirkt auf alle anderen

Interdependence: Teilsysteme beeinflussen sich kontinuierlich gegenseitig.