Critical Systems Heuristics

Zweck

In einer Ära, in der Algorithmen (GenAI, Scoring-Systeme) Karrieren und Lebenschancen entscheiden, versagt das rein technische Systemdiagramm. "Critical Systems Heuristics" (CSH), nach Werner Ulrich, ist keine Checkliste für APIs, sondern eine Checkliste für strukturelle Gewalt- und Machtverteilung. CSH hinterfragt die "Wahrheit" einer Architektur. Es legt die tiefe, unangenehme Annahme offen, dass Architektur niemals neutral ist. Jedes Tool, das du einführst (selbst ein einfaches Jira), begünstigt systematisch eine Kontrollschicht und entmachtet eine ausführende Schicht.

Einsatzkontext

Wende CSH an, bevor große "Enterprise Governance" Tools (z.B. Firmenweite Überwachungstools, KI-Code-Assistenz mit Metrik-Tracking, strikte Architektur-Board-Strukturen) eingeführt werden. Immer dann, wenn hochbezahlte Architekten im 5. Stock Regelwerke aufstellen, die 500 Code-Mokey im Keller ausführen sollen, schreit die Situation nach einer CSH-Diagnose.

Schritt für Schritt

CSH arbeitet mit 12 extrem aggressiven Heuristiken (Leitfragen), aufgeteilt in vier Domänen. Jeder Block muss einmal in einer "Ist"-Sicht und einer zwingenden "Sollte-Sein"-Sicht beantwortet werden:

1.Quellen der Motivation: Wessen Zwecke werden eigentlich durch dieses System bedient?

2.Quellen der Kontrolle (Macht): Wer hat die physische Macht, in dieser Architektur die Infrastruktur-Ressourcen zu ändern?

3.Quellen des Wissens: Wessen Expertise zählt? (Warum zählen wir die Zertifikate der Cloud-Architekten, aber ignorieren die operative Tages-Erfahrung des Kundensupports?)

4.Quellen der Legitimität: Wer darf das Projekt stoppen, wenn es toxisch wird? Welche Weltanschauungen werden unterdrückt?

Beispiel

Ein "Platform Enablement Team" baut DORA-Metrics-Tracking in alle Repositories der Entwickler ein. Das Ziel: "Velocity erhöhen". CSH-Diagnose:

Ist (Macht): Das Management (Owner) sieht die Metriken und bestraft langsame Teams. Die Devs (Actors) haben keine Kontrolle über die Anzeige.

Ist (Wissen): Das Tool misst "Lines of Code", ignoriert aber das "Refactoring"-Wissen der Senior Devs, weil das nicht maschinenlesbar ist.

Die Diagnose zeigt, dass das Architektur-Tool in Wahrheit keine "Befähigung", sondern ein reines "Top-Down Kontrollinstrument" ist. Ohne die CSH-Übersetzung wundert sich das Management, wieso die Devs das Tool durch das Schreiben sinnloser Code-Zeilen gnadenlos "gamen" (sabotieren).

Diagramm

Wie aus Diagnose Handlung wird

Softwarearchitektur wird meist dogmatisch betrachtet ("Ist Event-Sourcing die beste Lösung?"). CSH ändert die Frage in: "Für wen ist es die beste Lösung?" Oftmals sind architektonische Rahmenwerke ("Konzern-Standards") nur dünn verschleierte Manifestationen von Machtstrukturen. Wenn ein zentrales Architektur-Board den Feature-Teams die Tech-Stack-Auswahl komplett entzieht, ist das keine "Effizienzsteigerung", sondern primär ein Instrument der Machterhaltung und Herrschaft.

Wann diese Methode die richtige ist

CSH ist der intellektuelle Hammer hinter *Boundary Critique*. Während sich *Stakeholder Mapping* oft auf das reine "Management" der Emotionen fokussiert ("Wie verkaufen wir denen das Update am besten?"), fokussiert sich CSH kompromisslos auf Emanzipation: "Wie geben wir diesen extrem benachteiligten Nodes im System eine echte operative Vetomacht in unserer Software?"

Wie du die Diagnose im Alltag einsetzt

Trau dich als Architekt, die CSH Fragen am Bord-Tisch zu stellen. Wenn ein C-Level Manager ein riesiges Re-Org und eine neue Software fordert, frage ihn hart: "Wer sind die Leidtragenden dieser Software (Legitimität)? Wie verankern wir im Code das Veto-Recht der Ausführenden, falls wir uns geirrt haben?" Architektur-Designs, die keine Feedback-Loops "von unten nach oben" zulassen, sind keine reifen Systeme, sondern technische Feudalsysteme, die auf Widerstand und Katastrophen zusteuern.

Erste Analyse-Schritte

Bringe externe Skeptiker ins Review: Die beste CSH-Analyse einer internen Developer-Plattform wird nicht vom Chef-Architekten geschrieben, sondern vom genervtesten Junior-Frontend-Entwickler, der jeden Tag mit dem verpfuschten System kämpfen muss.

Woran du eine brauchbare Diagnose erkennst

Haben IT-Security Systeme (wie Device-Management Algorithmen) in unserem Unternehmen transparente Opt-Out Klauseln, oder erzwingen wir Sicherheit durch totale Entmündigung der Mitarbeiter?

Quellen

Werner Ulrich — Critical Heuristics of Social Planning (Haupt, 1983)

Werner Ulrich — A Brief Introduction to Critical Systems Heuristics (CSH)

Wikipedia: Critical Systems Heuristics