concepts

Requisite Variety

Ashby's Law of Requisite Variety besagt: Nur Vielfalt kann Vielfalt absorbieren. Um ein komplexes System zu steuern, braucht das Steuerungssystem mindestens genauso viele Handlungsmöglichkeiten wie das zu steuernde System.

organizationteams·4 min Lesezeit

Was ist das?

Warum relevant?

Nutze dieses Konzept, um beobachtbares Verhalten nicht nur zu benennen, sondern strukturell zu erklären.

Nächster Schritt

Prüfe danach, welcher Archetyp oder welche Diagnose das Muster im konkreten System sichtbar macht.

~4 Min. Lesezeit

Definition

"Requisite Variety" (Erforderliche Vielfalt) ist ein kybernetisches Gesetz, formuliert von W. Ross Ashby. Es besagt ganz simpel: Wenn das Steuerungssystem weniger Antwortmöglichkeiten (Reaktionsmuster) hat als das System, das kontrolliert werden soll, wird die Steuerung scheitern. Die Umwelt schlägt mit Problemen zu, auf die das Steuerungssystem schlicht keine Antwort hat. Um Stabilität zu wahren, muss die Varietät des Reglers (z.B. der Architektur-Abteilung) mindestens so groß sein wie die Varietät der Störungen (z.B. Projekt-Bedarfe).

Systemmechanismus

Stell dir einen Torwart vor, der nur nach links hechten kann. Wenn der Stürmer nach rechts schießt, bricht das System zusammen. Ein System in der IT (seien es Server oder Organisationseinheiten) steht unter permanentem Beschuss durch "Varietät" aus der Umwelt (Kundenwünsche, Hardwareausfälle, Legacy-Bugs). Um als System zu überleben, gibt es genau zwei mechanische Möglichkeiten: Die interne Vielfalt erhöhen (mehr Tools, mehr Autonomie, mehr Redundanz) ODER die externe Vielfalt reduzieren (Features absagen, Zugriffswege einschränken).

Architekturbeispiel

Ein zentrales Enterprise-Architektur-Board (EA) besteht aus 5 Personen und versucht, die Technologieauswahl für 100 verteilte Microservice-Teams (1.000 Entwickler) vorzuschreiben und durch Manuelle Freigaben ("Gates") zu steuern. Die EA-Abteilung erstickt sofort in Arbeit. Warum? Die Varietät (Ideen, Probleme, Edge-Cases) der 100 Teams ist um ein Vielfaches höher als die Verarbeitungskapazität (Varietät) des EA-Boards. Ashby's Law schlägt zu: Das Steuerungssystem ist massiv unterdimensioniert und wird zur Blockade (Bottleneck).

Organisationsbeispiel

Eine Bank führt einen neuen "One-Size-Fits-All" Prozess für Security-Freigaben ein. Jedes Projekt – egal ob ein kleiner CSS-Fix auf der Webseite oder ein tiefgreifendes Update des Kernbankensystems – muss denselben 12-seitigen Risiko-Fragebogen ausfüllen. Der Prozess hat nicht genug *Variety*, um die riesige *Variety* der Softwareänderungen passend zu beantworten. Die Folge: Entwickler füllen den Bogen bei CSS-Änderungen genervt mit "N/A" aus (sie dämpfen die Varietät künstlich) und der Prozess verliert jegliche Bedeutung.

Diagnosefragen

1.Haben wir komplexe Governance-Probleme einfach mit einem starren Standard-Prozess beantwortet, der der Realität nicht gerecht wird (zu wenig Variety)?

2.In welchen Teams brennt die Hütte, weil sie auf hunderte unvorhersehbare Probleme (hohe externe Variety) nur mit einem einzigen Werkzeug (niedrige interne Variety, z.B. "Arbeite härter!") antworten können?

3.Wo müssen wir radikal externe Varietät abdämpfen (z.B. "Wir bedienen diesen Edge-Case Kunden nicht mehr"), damit unsere Architekten überhaupt Land sehen?

Diagramm

Warum dieses Konzept in Architektur hilft

Das Prinzip der Autonomie in agilen Teams oder bei den DevOps-Prinzipien ist im Kern die Antwort auf Ashby's Law! Statt Varietät (Probleme) an ein zenrales Management (geringe Varietät) hochzueskalieren, gibt man dem lokalen Cross-Functional Team alle Werkzeuge, Budgets und Entscheidungsfreiheiten mit (hohe Varietät), damit sie die externen Störungen genau dort lösen können, wo sie auftreten.

Woran du das Konzept von ähnlichen Themen unterscheidest

Im Gegensatz zu *Feedback Loops*, die das zyklische Reagieren beschreiben, fokussiert sich Ashby's Law rein auf die "Bandbreite" der möglichen Reaktionen (Repertoire). Es deckt mathematisch auf, warum stark zentralisierte, bürokratische Kontrolleur-Systeme in komplexen IT-Strukturen zwangsläufig immer scheitern *müssen* (es fehlt ihnen mechanisch an Variety).

Wie du das Konzept praktisch nutzt

Wenn das Tech-Management über "Kontrollverlust" klagt, stelle Ashby's Waage auf. Entweder das Top-Management reduziert die Umweltkomplexität drastisch (es gibt strikte Vorgaben, was Teams *nicht* mehr tun dürfen: "Standardisierung"), ODER das Management akzeptiert, dass es die Kontrolle dezentral an die Teams abgeben muss ("Empowerment"). Ein Mittelweg – "Alle machen alles, aber wir kontrollieren alles zentral" – ist ein systemischer Irrglaube.

Erste Umsetzungsschritte

Verwende das Konzept, um der ständigen Rufe nach "mehr Standardisierung" zu begegnen. Zeige auf, dass Standardisierung (Reduzierung der internen Varietät) nur solange gut geht, wie die Umwelt (Markt, Technologie) ebenfalls extrem vorhersehbar ist.

Woran du Wirkung erkennst

Wurde bei der Definition des neuen Review-Prozesses einkalkuliert, dass nicht alle Projekte / Services gleich sind und der Prozess daher Ausnahmeregeln (mehr Variety) benötigt?