Soft Systems Methodology

Zweck

In der Softwareentwicklung wird oft das reine "Hard Systems Thinking" gelehrt: Da ist ein kaputter Server (Input), wir debuggen ihn, er läuft wieder (Output). "Soft Systems Methodology" (SSM), entwickelt von Peter Checkland, greift genau dort, wo dieses harte Denken völlig versagt. SSM ist für "Wicked Problems" (Vertrackte Probleme) zuständig, bei denen der Satz "Wir müssen das System reparieren" unmöglich ist, weil 15 hochrangige Manager im Raum 15 komplett unterschiedliche Definitionen darüber haben, was "Das System" überhaupt sein soll.

Einsatzkontext

SSM wird verwendet in der Phase 0 großer digitaler Transformationen. Wenn das Business schreit: "Die IT ist zu langsam!" und die IT schreit: "Das Business weiß nicht, was es will!". Wenn du in dieser Situation versuchst, das Problem mit neuen Microservices zu lösen, wirst du scheitern. Du musst als Architekt moderieren und den schwammigen Problempool (den "Mess") in formelle, für alle akzeptable Aussagen gießen, bevor auch nur ein Ticket geschrieben wird.

Schritt für Schritt

Der 7-Stufen-Prozess der SSM schwankt zwischen der echten, wirren Welt und dem sauberen System-Denken hin und her:

1.Den Sumpf betreten (Real World): Die unstrukturierte Problem-Situation anerkennen. Niemand weiß, was los ist.

2.Das Rich Picture (Real World): Das Problem subjektiv malen. (Siehe *Rich Picture Mapping*). Gefühle und politische Feinde ausdrücken.

3.Root Definitions (Systems Thinking World): Für jede entdeckte Partei im Rich Picture formal einen Sinn-Satz bilden. (Siehe *Root Definition Analysis* + *CATWOE*).

4.Konzeptionelle Modelle bauen (Systems Thinking World): Zeichne logische Pfeil-Diagramme: Welche Verben muss das System zwingend ausführen, damit die Root-Definition wahr wird?

5.Vergleich ziehen: Leg das saubere Konzeptmodell aus Schritt 4 über die dreckige Realität aus Schritt 2. Wo knallt es?

6.Entscheiden: Finde *Kulturell machbare und erstrebenswerte* Änderungen. (Achtung: nicht die "perfekte technische Lösung", sondern den besten Kompromiss).

7.Action: Das System umbauen (Implementierung).

Beispiel

"Die Frontend-Performance ist zu schlecht", klagt das C-Level. SSM beginnt: Das *Rich Picture* zeigt, dass die Performance gar nicht das Problem ist, sondern der CEO glaubt, die Konkurrenz sei schneller. *Root Definition A (Dev Team)*: "Wir müssen die Bundle-Size reduzieren". *Root Definition B (Sales Team)*: "Wir müssen mehr glitzernde Features bauen, Performance egal". Der Vergleich (Schritt 5) zeigt, dass eine reine Code-Optimierung (Vite statt Webpack) das tiefere Konflikt-Problem (Sales vs. Devs) nicht löst. Die kulturell akzeptable Änderung (Schritt 6) lautet also nicht "Framework Wechsel", sondern "Einführung eines wöchentlichen Performance-Budgets, das Sales und Devs gemeinsam verhandeln müssen".

Diagramm

Wie aus Diagnose Handlung wird

Der Geniestreich der SSM ist die Trennung der Sphären (Stufe 2 vs Stufe 4). Architekten flüchten sich bei Konflikten gerne sofort ins "Systems Thinking" (Stufe 4: Architektur zeichnen). Wenn sie das tun, ohne vorher den kulturellen Dreck (Stufe 2) zu verstehen, bauen sie das perfekte Container-Cluster für die absolut falsche Fragestellung einer Firma, die in Wahrheit ein Produktfindungs-Problem und kein Hosting-Problem hat.

Wann diese Methode die richtige ist

SSM ist der Schirm (Die Meta-Methode), unter dem *Rich Picture*, *Root Definition* und *CATWOE* als Sub-Tools zusammengefasst werden. Es ist das philosophische Gegenstück zum "Systems Engineering" (wie z.B. System Dynamics), welches davon ausgeht, dass die Ziele der Firma messbar und mathematisch klar sind.

Wie du die Diagnose im Alltag einsetzt

Zwinge dich als Senior Architekt zur brutalen Disziplin: Unterschreibe keine Lösungs-Architektur, wenn nicht vorher glasklar auf 2 Seiten dokumentiert wurde, aus welchen *konkurrierenden Weltbildern* das eigentliche Problem entstanden ist. Das stärkste Instrument eines Tech-Leads ist es, den Stakeholdern zu sagen: "Gute Nachrichten, unser Architektur-Problem ist gar keines. Wir haben ein Business-Strategie-Problem. Löst diesen Streit erst untereinander, bevor ich ein neues Backend-Repo anlege."

Erste Analyse-Schritte

Achte in Stufe 6 zwingend auf die Wörter "Systemically Desirable AND Culturally Feasible". Etwas mag systemisch das Genormteste, Sauberste und Beste der Welt sein (Desirable), wenn die Kultur der Entwickler es aber komplett ablehnt (Not culturally feasible), ist es eine gescheiterte Diagnose. Architektur muss von den Menschen akzeptiert werden, die sie atmen.

Woran du eine brauchbare Diagnose erkennst

Wurde bei der Einführung des neuen "Firmen-weiten Architektur-Standards" die Methode nachweislich erst gegen die gelebte Kultur des unordentlichsten Entwickler-Tribes geprüft (Stufe 5), anstatt es einfach Top-Down zu verordnen?

Quellen

Peter Checkland — Systems Thinking, Systems Practice (Wiley, 1981)

Peter Checkland & John Poulter — Learning for Action (Wiley, 2006)

Wikipedia: Soft Systems Methodology