Root Definition Analysis

Zweck

In der IT starten hunderte Projekte mit desaströsen, unklaren Missionen wie: "Wir wollen ein agileres Backend bauen." Was genau bedeutet "agiler"? Was ist der Zweck dieses Systems? "Root Definition Analysis" (Wurzeldefinition) ist der Kern der *Soft Systems Methodology*. Sie zwingt Analysten und Architekten, den wabernden Problem-Sumpf aus dem *Rich Picture* in einen einzigen, radikal präzisen, logischen Satz zu schmieden, der genau deklariert, WIE das System WAS tut, und WARUM.

Einsatzkontext

Wenn ein Team sich streitet, was eigentlich im aktiven Sprint gebaut werden soll, oder wenn die Architektur so "verwässert" ist, dass sie versucht, 15 verschiedene Stakeholder gleichzeitig glücklich zu machen (Big Ball of Mud). Die Root Definition schneidet den Speck weg und zementiert die fundamentale Daseinsberechtigung eines Teilsystems.

Schritt für Schritt

Eine saubere "Root Definition" hat immer die Struktur: "Ein System, das X tut, durch die Anwendung von Y, um das Ziel Z zu erreichen."

1.Das "WAS" (X): Was ist die physische oder logische Eingabe, und was ist die exakte Ausgabe? (Transformation).

2.Das "WIE" (Y): Mit welcher technologischen oder prozessualen Methode tun wir es?

3.Das "WARUM" (Z): Dem höheren Sinnengehalt zuliebe (Die Weltanschauung aus dem CATWOE).

Diese Sätze werden in Schleifen getestet, indem man sie hart gegen die 6 Dimensionen der *CATWOE-Analyse* (Customers, Actors, Transformation, Weltanschauung, Owner, Environment) spiegelt.

Beispiel

Ein Team soll ein "User Analytics Portal" bauen.

*Schlechte Definition:* "Wir bauen ein System für Produktmetriken, um datengetriebener zu sein." (Niemand weiß, was das architektonisch bedeutet).

*Erste Iteration:* "Ein System, um Klicks in Graphen zu verwandeln (X), durch eine Kafka-Daten-Pipeline (Y), um den Product-Ownern schnelle Entscheidungen zu ermöglichen (Z)."

Wir prüfen dies gegen CATWOE: Moment, die "Owner" (O) sind aber die Audit-Beauftragten der Bank, und die Erlaubnis der DSGVO (E) fehlt.

*Root Definition Finale:* "Ein DSGVO-konformes System (E), das anonymisierte Roh-Traffic-Daten von Endnutzern (C) durch das Data-Engineering-Team (A) mittels aggregierter Redshift-Views (Y) in Compliance-sichere Reports (X) transformiert, um im Auftrag der Rechtsabteilung (O) die gesetzlich vorgeschriebene Auditierbarkeit unseres Traffics (Z) sicherzustellen (W)."

Das Architektur-Design dreht sich plötzlich komplett: Es geht nicht mehr um "Echtzeit-Graphen für den PO", sondern um "kalte Batch-Sicherung für Auditoren". Riesige Fehlinvestitionen wurden verhindert.

Diagramm

Wie aus Diagnose Handlung wird

Architektur ist die Kunst des "Nein" Sagens. Eine schlagkräftige Root Definition ist das Schwert, mit dem Feature-Creep auf Systemebene bekämpft wird. Wenn ein Stakeholder an die neue Reporting-Applikation plötzlich eine "Kreditkarten-Abrechnungs-Funktion" anbauen will, holt der Domain-Architect die Root-Definition heraus: "Das fällt nicht unter unsere Wurzel-Transformation X zu Y, wir sind nicht der Payment-Context."

Wann diese Methode die richtige ist

*Rich Pictures* feiern das Chaos. *Root Definitions* hassen das Chaos. Sie sind der harte grammatikalische Übergang vom Sumpf (Problem-Situation) hin zum formalen Systemdiagramm. Während *Domain Driven Design (DDD) Bounded Contexts* den Code-Raum abteilen, fungiert die Root Definition als der semantische Grenzpfahl dieses Raumes.

Wie du die Diagnose im Alltag einsetzt

Akzeptiere keine Jira-Epics, keinen System-Context-Entwurf und kein neues Cloud-Repository, das keine präzise Root-Definition im Readme stehen hat. Halte Architekten dazu an, Buzzwords wie "Synergien", "Plattform" und "Agilität" aus diesen Sätzen gnadenlos zu streichen. Zwinge sie zu Verben: Was wird in was transformiert?

Erste Analyse-Schritte

Für komplexe Systeme existiert niemals nur *eine* Root Definition. Das Marketing hat eine Root Definition eurer App (Ad-Revenue-Generator), das Ops-Team eine zweite (Ausfallsicheres Service-Mesh), und der Kunde eine dritte (Shop-System). Der beste Weg zur Klarheit ist, 3 verschiedene Root-Definitions-Sätze für dieselbe Software auszuarbeiten und in der Architektur-Runde zu diskutieren, wie sich diese widersprechen und wer am Ende Vorfahrt hat.

Woran du eine brauchbare Diagnose erkennst

Können 5 Entwickler aus deinem Backend-Team unvorbereitet und exakt den gleichen "System X tut Y um Z zu erreichen" Satz über die Architektur aufsagen, an der sie gerade 40 Stunden die Woche arbeiten?

Quellen

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

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

Wikipedia: Soft Systems Methodology