diagnostics

Viable System Model

Ein Meisterwerk der Organisationskybernetik. Es beschreibt die mathematisch-fraktale Struktur, die jedes Softwareunternehmen benötigt, um unter starkem Marktdruck lebendig zu bleiben.

organization·4 min Lesezeit

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

Das von Stafford Beer in den 1970ern (auf Basis des menschlichen Nervensystems) erschaffene "Viable System Model" (VSM) ist bis heute das konsequentste Denkwerkzeug, um Skalierung in der IT zu begreifen. Es besagt, dass Organigramme vereinfachen und zu Ineffizienz verdammen. Das VSM definiert, dass ein Unternehmen exakt 5 grundlegende Sub-Systeme besitzen muss. Sobald nur eines fehlt oder das Feedback zwischen ihnen abreißt, wird die Organisation unflexibel oder chaotisch. VSM ist die Blaupause, wie Teams und Softwarearchitektur fraktal skaliert werden können.

Einsatzkontext

Das VSM ist die philosophische Grundlage moderner Architektur-Dogmen wie "Conway’s Law" oder "Team Topologies". Wenn du deine Firma von einem Monolithen auf eine verteilte Service-Oriented (Microservices) Architektur zwingst, kopierst du unweigerlich das Problem der "Komplexitätsbewältigung" auf die Teams. VSM wird angewendet, um das Informations-Fehlrouting zu beheben, wenn das CTO-Board den Überblick über die Flotte an autonomen Services verliert.

Struktur des Modells (Die 5 Sub-Systeme)

Ein "Viable System" ist fraktal (Eine Entwicklerzelle hat dieselbe Struktur wie das Entwickler-Departement, was dieselbe Struktur wie das C-Level hat).

System 1 (Operation): Die tatsächlichen Muskeln. Die Ausführung. Das Delivery-Team, das Code tippt. Es muss konsequent autonom operieren.

System 2 (Koordination): Das parasympathische Nervensystem. Es verhindert, dass die Muskeln sich verkrampfen. (z.B. API-Gateway-Verträge, Scrum-of-Scrums, Shared Design-Systems). Es synchronisiert die System-1-Silos, ohne sie zu befehligen!

System 3 (Kontrolle/Delivery): Das verlängerte Mark (Base Brain). Es sorgt für die Ressourcen-Verteilung, das Budgeting und trackt das "Hier und Jetzt". Es blickt ausschließlich nach unten und innen.

System 4 (Forschung/Zukunft): Der Kortex (Denk-Gehirn). Es schaut ausschließlich nach oben, außen und ins "Morgen". Welche Tech-Trends kommen 2029? Was will der AI-Markt? System 4 erzeugt Optionen.

System 5 (Ethik/Identität): Das Über-Ich (Policy). Das Architektur-Board oder CEO. Es balanciert den ständigen, gnadenmäßigen Überlebenskampf zwischen System 3 (Wir müssen jetzt Geld verdienen!) und System 4 (Wir müssen für die Zukunft das Backend neu schreiben!).

Beispiel

Ein stark wachsendes E-Commerce System kippt um. Die Diagnose nach VSM offenbart den Grund für die IT-Störung: Es existiert ein fraktaler Bruch der Komplexitäts-Dämpfung. Die Lead-Ingenieure im Checkout-Prozess (System 1) funken jeden kleinen Deploy-Fehler direkt in das CIO-Office (System 5). Der CIO ist komplett überlastet vom "Noise" (dem Prozessen) kleinster Details. Das VSM verlangt sofortige Intervention: Es muss ein starkes System 2 (z.B. eine robuste CICD Pipeline mit Paved Roads) und System 3 (Eine dedizierte Platform-Engineering Ebene zur Ressourcenkontrolle) hochgezogen werden, die den "Noise" abdämpfen, bevor er das System 5 der Firma überlastet (Ashby's Gesetz der erforderlichen Varietät).

Diagramm

Wie aus Diagnose Handlung wird

Im VSM ist Kommunikation ("The Algedonic Signal") alles. Wenn Teams sagen, "Wir bauen autonome Microservices", meinen sie oft "Wir kappen die Kommunikationsadern". VSM warnt deutlich davor. Eine autonome Einheit MUSS zwingend Schmerzsignale sehr schnell und ungefiltert nach oben leiten können. Wenn das Mittelmanagement Incident-Reports "schönt", wird der Alarmkanal blockiert, das Gehirn (System 5) wähnt sich in Sicherheit, und der Körper der Organisation fackelt lautlos ab.

Wann diese Methode die richtige ist

Domain Driven Design (DDD) zieht fachliche Grenzen an. Das Viable System Model sagt dir, exakt wie die Kybernetik (Steuerungs-Mathematik) der Hierarchie-Ebenen zwischen diesen fachlichen Grenzen verdrahtet sein muss, um nicht am Kommunikationsüberhang zu ersticken. Es liefert das theoretische, kybernetische Fundament für das methodischere Viability Audit.

Wie du die Diagnose im Alltag einsetzt

Achte als Architekt besonders auf das Gleichgewicht zwischen System 3 und 4. Ein typisches "Legacy" IT-Silo hat ein sehr großes System 3 (Tagesgeschäft, Incident-Handling, Bugfixing), während System 4 (Architektur-Recherchen) von einem Entwickler nebenbei am Freitagabend in seiner Freizeit gemacht wird. Stärke System 4. Wenn System 3 das Unternehmen regiert, hast du Effizienz aufgebaut, um geradewegs gegen die Wand der technologischen Obsoleszenz zu steuern.

Erste Analyse-Schritte

Es nützt nichts, VSM als "Folien-Template" zu nutzen. Die Stärke von VSM entfaltet sich, wenn man begreift, dass "Ashby's Law of Requisite Variety" real ist: Die Anzahl der Steuerungszustände des Managers muss stark deutlich größer sein als die Anzahl der Zustände des komplexen Systems, das er steuern will. Da das für Microservices unmöglich ist (der Manager hat nicht genug Gehirnzellen), zwingt dich die Architektur zur "Attenuation" (Dämpfung von Variablen für den Manager durch Automatisierung) und "Amplification" (Verstärkung von Variablen für das Entwickler-Team durch Cloud-Skalierung).

Woran du eine brauchbare Diagnose erkennst

Verfügt jedes deiner einzelnen "Cross-Functional" Teams auf tiefster Ebene über eine eigene kleine Version von "System 4" (Zeit, um selbstständig über ihre Domänen-Zukunft und künftige Tech-Refactorings nachzudenken) oder diktiert das Architekten-Board dieses Wissen monolitisch hinab?