diagnostics

CATWOE Analysis

Ein Checklisten-Werkzeug aus der Soft Systems Methodology, um die unterschiedlichen Weltbilder und Interessen hinter einer Konfliktsituation zu entschlüsseln.

teamsorganization·3 min Lesezeit

Was ist das?

Ein Checklisten-Werkzeug aus der Soft Systems Methodology, um die unterschiedlichen Weltbilder und Interessen hinter einer Konfliktsituation zu entschlüsseln.

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

CATWOE (ein Akronym für Customers, Actors, Transformation, Weltanschauung, Owner, Environmental constraints) ist eine hochstrukturierte Diagnose-Schablone, die aus der *Soft Systems Methodology* (SSM) von Peter Checkland stammt. In der IT prallen oft Abteilungen aufeinander, weil sie dasselbe technische System fundamental unterschiedlich wahrnehmen. Die Finance-Unit sieht AWS als Kosten-Katastrophe, die Dev-Unit sieht AWS als heiligen Gral der Geschwindigkeit. CATWOE bricht diese toxischen Konflikte auf, indem es das System in 6 hart umgrenzte soziotechnische Perspektiven seziert.

Einsatzkontext

Die Methode glänzt in den frühen Phasen des "Requirements Engineering" oder bei total verfahrenen Migrationsprojekten. Wenn Stakeholder in Endless-Meetings festhängen und über "die Architektur" streiten, ohne dass jemand definiert hat, *welche* der 50 konkurrierenden Wahrheiten des Systems gerade analysiert wird, kommt CATWOE zum Einsatz. Es zwingt alle, ihr mentales Modell explizit auf den Tisch zu legen.

Schritt für Schritt

Das System wird zwingend entlang der 6 Elemente der Wurzeldefinition durchdeklamiert:

1.C (Customers): Wer sind die Nutznießer oder Opfer des Systems? (z.B. "Die Endnutzer der App", oder "Der CEO").

2.A (Actors): Wer führt das System operativ aus? (Die Feature-Entwickler, die DevOps-Agenten).

3.T (Transformation): Welcher Kernprozess verwandelt den Input in Output? (Roh-Code wird zu Live-Software).

4.W (Weltanschauung): *Der wichtigste Punkt.* Welche Philosophie macht diese Transformation sinnvoll? (z.B. "Agilität ist wichtiger als Sicherheit").

5.O (Owner): Wer hat die ultimative Macht, das System morgen per Knopfdruck abzuschalten? (Sponsor, Board of Directors).

6.E (Environmental Constraints): Welche starren externen Regeln erzwingen Limits? (DSGVO, Legacy-Cobol-Mainframes, Budget).

Beispiel

Ein Team soll ein neues "Customer Data Platform" (CDP) System aufbauen. Es knallt ständig. Eine CATWOE-Diagnose deckt auf:

Das Architekten-Team (A) hat als (W) Weltanschauung: "Das CDP muss ein technisch pures Meisterwerk aus Entkopplung und Kafka-Topics sein."

Das Marketing-Team (C) hat als (W) Weltanschauung: "Ich brauche übermorgen meine Werbekampagnen-IDs in Excel, der Rest ist mir egal."

Die Diagnose zeigt, dass der Konflikt nicht an "schlechter Technologie" liegt, sondern dass die (W) Weltanschauungen nicht in ein gemeinsames (T) Transformations-Ziel überführt wurden. Die Architekten bauten das falsche System für die richtige Frage.

Diagramm

Wie aus Diagnose Handlung wird

CATWOE ist enorm mächtig gegen das "Ingenieurs-Krankheit-Syndrom". Software-Architekten neigen dazu, direkt an der (T) Transformation zu schrauben (Microservices, Docker, Kubernetes), vergessen dabei aber völlig den (O) Owner einzubinden oder die (E) Environmental Constraints (z.B. ISO27001 Zertifizierungen) der Operations-Teams zu berücksichtigen. Ein System, das im Labor perfekt funktioniert, wird in der Praxis sterben, wenn es die Weltanschauung der (A) Actors (Wer soll es mitten in der Nacht bei PagerDuty reparieren?) verletzt.

Wann diese Methode die richtige ist

Während das *Iceberg Model* eher die Tiefe der System-Events untersucht (Was löst das Ereignis strukturell aus?), schneidet CATWOE horizontal wie ein MRT-Scanner quer durch das Operations-Feld und zwingt die soziologischen Rollen ins Scheinwerferlicht.

Wie du die Diagnose im Alltag einsetzt

Bevor der erste Code-Block eines Multi-Millionen-Projekts geschrieben wird, muss das Architektur-Komitee das CATWOE-Matrix-Dokument von jedem Head-of der Schlüsselabteilungen unterschreiben lassen. Wenn Marketing und Security sich auf das Feld (W - Weltanschauung) für das System nicht einigen können, verbiete den Entwicklern, mit der Arbeit anzufangen. Sie würden am Ende zwischen den Fronten zerquetscht werden.

Erste Analyse-Schritte

Verwende CATWOE im Event Storming! Wenn Domain-Experten an der Wand die Events kleben, nutze CATWOE-Fragen wie ein Scharfschütze, um die blinden Flecken anzugehen: "Moment, (E) Environmental constraints: Lässt der Gesetzgeber es hier auf dem Server überhaupt zu, dass wir dieses Event einfach asynchron abfeuern?"

Woran du eine brauchbare Diagnose erkennst

Haben wir bei der Planung unserer neuen internen Developer-Plattform (IDP) präzise geklärt, wer eigentlich der harte (O) Owner mit dem Veto-Recht ist, wenn die (A) Actors (Plattform-Devs) und die (C) Customers (Feature-Devs) in Streiks verfallen?