diagnostics

Viable System Model

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

organization·4 min Lesezeit

Was ist das?

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

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 radikalste Denkwerkzeug, um Skalierung in der IT zu begreifen. Es besagt, dass Organigramme lügen und zu Ineffizienz verdammen. Das VSM definiert, dass ein Unternehmen exakt 5 fundamentale Sub-Systeme besitzen muss. Sobald nur eines fehlt oder das Feedback zwischen ihnen abreißt, stirbt die Organisation an Inflexibilität oder explodiert im Chaos. 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 radikal 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-Katastrophe: 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" (Rauschen) 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 Gehirn (System 5) der Firma grillt (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 massiv davor. Eine autonome Einheit MUSS zwingend Schmerzsignale extrem 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 obsessiv auf das Gleichgewicht zwischen System 3 und 4. Ein typisches "Legacy" IT-Silo hat ein gigantisches System 3 (Tagesgeschäft, Incident-Handling, Bugfixing), während System 4 (Architektur-Recherchen) von einem Entwickler nebenbei am Freitagabend in seiner Freizeit gemacht wird. Rette 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 Magie von VSM entfaltet sich, wenn man begreift, dass "Ashby's Law of Requisite Variety" real ist: Die Anzahl der Steuerungszustände des Managers muss extrem massiv 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?