Viability Audit with VSM

Zweck

Das "Viability Audit" ist die operative Checkliste des Viable System Model (VSM) von Stafford Beer. In der Tech-Industrie skalieren Firmen von 10 auf 500 Entwickler, indem sie einfach "mehr Tribles" oder "mehr Microservices" hinzufügen. Das führt zu deutlichem Kontrollverlust. Das Viability Audit prüft, ob eine Organsiation oder ein Software-Service exakt die 5 cybernetischen Organe (Systeme 1-5) besitzt, die für ein autonomes "Überleben" in einer anspruchsvollen Umwelt (Markt, Hacking, Outages) strukturell erforderlich sind.

Einsatzkontext

Das Audit wird als Notbremse vor großen "Hyper-Growth" Phasen, Carve-Outs oder konsequenten "Autonomie-Initiativen" (DevOps / You build it, you run it) genutzt. Wenn der CEO sagt "Die Squads sind jetzt komplett autonom, wir streichen das Mittelmanagement", zieht der Architekt das Audit, um zu prüfen, ob die Teams diese Autonomie überhaupt steuern können.

Schritt für Schritt (Das VSM Audit)

Der Auditor prüft konsequent die Existenz der 5 Systeme auf jeder logischen Skalierungsebene:

1.System 1 (Operation): Erledigt die Einheit überhaupt Kernarbeit (z.B. Feature Coden)? Oder verwalten sie nur sich selbst (Overhead)?

2.System 2 (Koordination): Gibt es Mechanismen (Swagger-Docs, CI/CD-Pipelines), die verhindern, dass System-1-Einheiten sich gegenseitig beeinträchtigen (Oszillation/Merge-Konflikte)?

3.System 3 (Kontrolle): Gibt es ein Dashboard (APM, Datadog, Management), das in Echtzeit das "Hier und Jetzt" überwacht und Budgets gerecht zuteilt? Gibt es den "Sporadischen Audit" (System 3*), der ins System funkt, um die Wahrheit der Dashboards zu prüfen?

4.System 4 (Entwicklung): Schauen ausreichend viele Hirnzellen der Organisation nach Außen und in die Zukunft (Das "Da und Morgen")? (Z.B. Tech-Radar Forschung, R&D).

5.System 5 (Identität/Policy): Gibt es eine finale Entscheidungsinstanz (Architektur-Board), die bei unlösbaren Konflikten zwischen "Jetzt" (System 3) und "Zukunft" (System 4) die Firmenidentität ("Wir sind eine Quality-First Firma!") erzwingt?

Beispiel

Ein Audit wird auf ein Feature-Tribe (100 Personen) angewendet, das außergewöhnlich viel Code in Produktion pumpt, aber die Fehlerquote steigt stark an. Das Audit diagnostiziert sofort: System 1 (Feature Coden) arbeitet auf 150%. Aber System 2 (Koordination) fehlt weitgehend (Keine automatisierten End-to-End Tests zwischen den Services). Gleichzeitig dominiert System 3 (Tagesgeschäft-Druck aus dem Vertrieb) die Einheit komplett, während System 4 (Forschung, Architektur-Hygiene, Vorbereitung auf Kubernetes v2) zu 100% mit 0 FTE besetzt wurde. Das Audit-Ergebnis ist binär: Dieser Tribe ist nicht viable (nicht lebensfähig). Er wird sich in 6 Monaten selbst beeinträchtigen, weil er keine Zukunftssensorik besitzt.

Diagramm

Wie aus Diagnose Handlung wird

Einer der schmerzhaftesten Punkte in VSM-Audits ist der Kampf zwischen System 3 (Inside-and-Now) und System 4 (Outside-and-Then). Architekten sollten eigentlich in System 4 operieren, sind aber zu 90% gefangen in der Problemsituation der System 3 Micromanagement- und Fire-Fighting-Aufgaben. Wenn das VSM-Audit ergibt, dass System 4 vernachlässigt wird, ist absehbar, dass dein Marktprodukt in naher Zukunft veralten oder von einer disruptiven Technologie der Konkurrenz beeinträchtigt wird.

Wann diese Methode die richtige ist

Dependency Mapping und Stock and Flow schauen, ob der Code fließt. Das Viability Audit hingegen schaut weitaus höher: Besitzt dieser Code, dieser Cloud-Service und dieses Team um den Code herum überhaupt die Kybernetik eines "Gehirns", um sich selbstständig ohne Eingriffe von oben am Leben zu erhalten?

Wie du die Diagnose im Alltag einsetzt

Entferne in Management-Vorlagen das Konzept "Lean = Gut" und "Management = Overhead". Nutze das Audit, um konsequent klarzumachen: Die Autonomie deiner Amazon-Dev-Teams funktioniert nur deshalb, weil AWS Milliarden in System 2 (Perfekte APIs) und System 3 (leistungsfähige Alarmsysteme) investiert hat. Du kannst nicht einfach Hierarchien abbauen (System 3/4 entfernen), ohne System 2 deutlich mit Technologie auszustaffieren. Das Resultat ist kein "agiles Nirvana", sondern strukturelles Risiko.

Erste Analyse-Schritte

Auditiere konsequent die Kommunikationskanäle (Algedonische Kanäle). In einem Viable System muss ein gravierender Ausfall unten in System 1 direkt, roh und ungefiltert, an der mittleren Abteilungsleiter-Hierarchie vorbei, als Schmerz-Signal oben in System 5 (CIO Board) eintreffen. Existiert bei euch eine Fehler-Verwässerungs-Kultur im Mittelmanagement? Das Audit würde das Alarm schlagen.

Woran du eine brauchbare Diagnose erkennst

Wird ein einzelner, unabhängiger Bounded-Context (Microservice) nur dann als "fertig" abgenommen, wenn das betreuende Squad beweisen kann, dass der Service nicht nur logische Arbeit (System 1), sondern auch automatische Observability (System 3) und einen klaren Lifecycle-Plan (System 4) eingebaut hat?

Quellen

Stafford Beer — The Brain of the Firm (John Wiley, 1972)

Stafford Beer — Diagnosing the System for Organizations (John Wiley, 1985)

Wikipedia: Viable System Model