Social Network Analysis

Zweck

Jedes Unternehmen hat zwei Architekturen: Die Boxen auf dem PowerPoint des CTOs (das offizielle Organigramm) und das tatsächliche Spinnennetz der Menschen, die täglich versuchen, die Arbeit zu erledigen. "Social Network Analysis" (SNA) misst empirisch Letzteres. Es ist die Graphen-Theorie angewendet auf menschliche Interaktion. SNA enttarnt die wahren Engpässe, die geheimen Meinungsmacher, die absoluten Single-Points-of-Failure (SPOF) in der Belegschaft und die Teams, die komplett isoliert verhungern.

Einsatzkontext

Verwende SNA vor jeder größeren agilen Reorganisation (z.B. der Einführung des Spotify-Modells) oder bevor ein zentrales Architektur-Board die Entwickler-Tribes in neue Domain-Silos sperrt. Wenn die System-Architektur in Microservices zerbrochen wird, das Team aber sozial hochgradig aneinandergekettet bleiben muss ("Hidden Monolith"), diagnostiziert SNA, dass das Vorhaben in Wochen blutig scheitern wird. (Conway's Law Diagnostik pur).

Schritt für Schritt

1.Das Netzwerk scannen: Sammle Daten (Umfragen, Slack-Metadaten, Git-Commit-Kollaborationen). Frage: "An wen wendest du dich, um ein technisches Problem zu lösen, für das dein Team keine Kompetenz hat?"

2.Den Graphen zeichnen: Jeder Mitarbeiter oder jedes Team ist ein Knoten (Node). Jede Interaktion ist eine Kante (Edge).

3.Zentralität messen: Finde die Knotenpunkte mit den meisten Pfeilen.

4.Broker identifizieren: Finde die Personen, die als einzige Brücke zwischen zwei sonst isolierten Abteilungen (Silos) stehen.

5.Peripherie prüfen: Wer hängt ohne Verbindungen am äußeren Rand des Graphen?

Beispiel

Ein Architekt zeichnet das SNA-Diagramm für das 100-köpfige Backend-Departement. Das offizielle Diagramm zeigt 10 autonome Squads à 10 Personen. Das SNA-Diagramm zeigt hingegen einen gigantischen, chaotischen Wollknäuel. Alle Pfeile für "Fragen zur Datenbank-Migration" zeigen auf eine einzige Entwicklerin: Sarah. Sarah ist der absolute Broker und Informations-Flaschenhals der Firma, obwohl sie auf dem Papier nur ein normaler Dev in Squad 3 ist. Die Diagnose besagt: Wenn Sarah in den Urlaub geht, kollabiert die Delivery-Velocity des gesamten Departements um 50%. Das Architektur-Update muss lauten, das DB-Wissen von Sarah systemisch aufzubauen, statt noch mehr Entwickler einzustellen.

Diagramm

Wie aus Diagnose Handlung wird

Software-Ingenieure ignorieren oft die Soziologie. SNA zwingt sie, zu begreifen: Code wird von Netzwerken geschrieben. Wenn das Netzwerk kaputt ist, ist der Code kaputt. Netzwerke haben oft "Strukturelle Löcher" (Structural Holes) – Orte, wo zwei Teams *eigentlich* miteinander kommunizieren müssten (weil ihre Microservices harte API-Verträge haben), es aber im SNA Graphen keinerlei Verbindung gibt. Wenn du dieses Loch diagnostizierst, weißt du im Vorfeld, dass der API-Vertrag beim ersten Stress-Test beim Deployment brechen wird.

Wann diese Methode die richtige ist

Im Gegensatz zum *Dependency Mapping*, das oft die harten, blockierenden "Mein API Call muss auf deinen API Call warten" Kopplungen misst, misst SNA die weichen Faktoren menschlicher Kollaboration: "Wen frage ich um Rat?", "Wer blockiert meine Idee politisch?".

Wie du die Diagnose im Alltag einsetzt

Zerstöre in Architektur-Meetings sofort die Illusion, dass "Das Ops-Team" mit "Dem Dev-Team" redet. Teams reden nicht miteinander. Menschen reden miteinander. Führe als Lead regelmäßig radikal ehrliche "SNA-Puls Checks" beim Kaffee ein: "Ganz ehrlich, wenn dein Service heute Nacht brennt, wer ist die Person, die du privat auf Slack anschreibst, obwohl sie nicht auf dem Dienstplan steht?" Genau dort sind die versteckten Last-Strukturen deines Systems.

Erste Analyse-Schritte

Verwechsle Sichtbarkeit im Netzwerk nicht mit Produktivität. Ein Entwickler, der im SNA Graphen extrem zentral ist (viele Pfeile), ist oftmals kein Held, sondern ein Zeichen einer dysfunktionalen Architektur, die ständige manuelle Koordination (Helpdesk-Ticket-Ping-Pong) erfordert, anstatt saubere Self-Service-Interfaces zu bieten. Die besten Architekturen erzeugen offene, lose gekoppelte SNA-Graphen, keine dichten Wollknäuel.

Woran du eine brauchbare Diagnose erkennst

Wurde bei der Definition der "Domain Driven Design Bounded Contexts" geprüft, ob die Team-Grenzen exakt mit den realen menschlichen Kommunikations-Grenzen aus dem Slack-Social-Network übereinstimmen?

Quellen

Rob Cross & Andrew Parker — The Hidden Power of Social Networks (Harvard Business Press, 2004)

Valdis Krebs — Social Network Analysis (OrgNet)

Wikipedia: Social Network Analysis