diagnostics

Dependency Mapping

Visualisierung von technischen und organisatorischen Verstrickungen, um Flaschenhälse (Bottlenecks) und tödliche Kopplungen offenzulegen.

technologyorganization·3 min Lesezeit

Was ist das?

Visualisierung von technischen und organisatorischen Verstrickungen, um Flaschenhälse (Bottlenecks) und tödliche Kopplungen offenzulegen.

Warum relevant?

Diagnostik macht aus Vermutungen belastbare Strukturhypothesen fuer Architektur und Organisation.

Nächster Schritt

Leite im Anschluss Interventionen ab, die gezielt Regeln, Grenzen oder Feedback-Loops veraendern.

~4 Min. Lesezeit

Zweck

"Dependency Mapping" (Abhängigkeits-Kartierung) ist die chirurgische Diagnose der verteilten Architektur. Es deckt auf, dass "Microservices" in der Realität oftmals nur verteilte monolithische Gordische Knoten sind. Teams denken fälschlicherweise in Boxen ("Das ist mein Service"). Das Dependency Mapping zwingt sie, in *Pfeilen* zu denken ("Ich kann nicht ausliefern, wenn Service B down ist"). Es diagnostiziert den wahren Grad der systemischen Freiheit (Autonomie) einer Organisation.

Einsatzkontext

Wenn das Mantra lautet: "Wir sind agil", aber jede Release-Bereitstellung 4 Wochen Vorlaufzeit in "Release-Train Synchro-Meetings" benötigt und ein triviales Frontend-Feld-Update 3 Backend-Dienste anpassen muss, dann herrscht tödliche Kopplung. Dependency Mapping wird gezogen, bevor man Teams skaliert, um zu prüfen, ob die Architektur diese Skalierung überhaupt überlebt (Conway's Law Diagnostik).

Schritt für Schritt

1.Inventur starten: Liste die Kernkomponenten oder die Squads auf.

2.Hard-Dependencies (Blocker): Ziehe rote Pfeile für synchrone Blockaden (Service A stürzt ab, wenn Service B nicht in echten 100ms antwortet).

3.Soft-Dependencies: Ziehe blaue Pfeile für asynchrone Verbindungen (Service A legt eine Message in Kafka für Service B ab).

4.Organisatorische Dependencies: Lege eine Folie darüber: "Team A darf keinen Code in Produktion stellen, bevor das Ops-Team C manuell die Firewall-Regel genehmigt hat".

5.Zählen der Kanten: Zähle die Eingangs- und Ausgangspfeile pro Squad. Der Node mit den meisten eingehenden Abhängigkeiten ist der Flaschenhals des Unternehmens.

Beispiel

Die Produkt-Velocity ist extrem asymmetrisch. Squad A liefert wöchentlich, Squad C braucht Monate. Ein Dependency-Mapping wird vom Checkout-Prozess bis hin zur Datenbank erstellt. Die Zeichnung offenbart einen massiven organischen "Spaghetti-Knoten" bei "Team B (Das Auth-Backend)". Nahezu alle 20 Feature-Teams haben organisatorische (Schnittstellen-Diskussionen) und technische (Synchrone REST Calls) Hard-Links zu diesem Auth-Team. Team B erstickt unter der kognitiven Last hunderter Pull-Requests. Squad C ist deshalb langsam, weil es in der "Warteschlange" vor Team B festhängt.

Diagramm

Wie aus Diagnose Handlung wird

Der Architekt Sam Newman hat es geprägt: Jede synchrone Abhängigkeit ist in einem verteilten System eine potenzielle Waffe gegen deine Verfügbarkeit (Availability). Die Formel lautet: 99.9% Uptime Servie A * 99.9% Uptime Service B = 99.8% System Uptime. Jedes Dependency-Map-Kreuz kostet die Organisation Cash durch Koordinations-Meetings. Gute Architekturen sehen auf dem Papier isoliert aus ("Shared-Nothing Architecture"). Die Diagnostik entlarvt die Lügen der Organigramme.

Wann diese Methode die richtige ist

Im Gegensatz zu extrem breiten *Causal Loop Diagrams*, die abstrakte Soziologie ("Druck", "Motivation") zulassen, ist Dependency Mapping brutal pragmatisch und hart: API-Verbindungen, Code-Paket-Abhängigkeiten (npm/maven), und Ticket-Übergabe-Silos zwischen Jira-Boards.

Wie du die Diagnose im Alltag einsetzt

Architekten müssen Abwägungen treffen. Das Ziel ist niemals "0 Abhängigkeiten" (denn das ist ein unfassbar ineffizienter Monolith). Das Ziel ist asynchrone Kausalität. Wenn Node A down geht, darf System B den User nicht blockieren (Circuit Breaker, Fallbacks). Zerschneide in der Architektur-Runde aktiv Pfeile auf dem Diagramm und frage das Team: "Wie designen wir den Code so um, dass dieser synchrone Pfeil zu einem asynchronen Event-Publishing Pfeil mutiert, auf den ich nicht mehr warten muss?" (Structural Decoupling).

Erste Analyse-Schritte

Verwende das Framework aus "Team Topologies": Jede Abhängigkeit, die nicht als glasklares "X-as-a-Service" (voll automatisierte Bereitstellung) definiert ist, ist per Definition eine blockierende Collaboration oder Facilitation-Abhängigkeit, die immense menschliche Bandbreite kostet.

Woran du eine brauchbare Diagnose erkennst

Wird bei einem System-Review-Ticket (Pull Request für neue Architektur) nicht nur der neue Container begutachtet, sondern radikal hinterfragt, ob durch diesen Container drei *neue* Hard-Dependencies ins Leben gerufen werden, die unser Gesamtrisiko vervielfältigen?