Rich Picture Mapping

Zweck

"Rich Picture Mapping" entspringt der *Soft Systems Methodology* von Peter Checkland. Es ist keine UML-Zeichnung und kein C4-Diagramm. Es ist ein absichtlich informelles, handgezeichnetes "Wimmelbild" einer Organisations-Krise. In hochkomplexen System-Transformationen (wie der Wechsel auf Cloud-Native) sind die größten Blockaden keine fehlenden Kubernetes-Cluster, sondern Ängste vor Jobverlust, Machtkämpfe zwischen Abteilungen und schlechte Kommunikation. Rich Pictures holen diese emotionalen, kulturellen und politischen Faktoren physisch auf das Architektur-Whiteboard.

Einsatzkontext

Wenn du als Architekt oder Berater in ein völlig zerrüttetes Projektteam kommst ("Die Anforderungen ändern sich täglich", "Das Business redet nicht mit der IT", "Operations weigert sich zu deployen"), greift man zum Rich Picture. Es wird ganz am Anfang (Phase 1) genutzt, bevor man überhaupt versucht, das Problem technisch zu lösen. Es fängt den "Mess" (den wirren Sumpf) der Situation ein.

Schritt für Schritt

1.Der große Bogen (Whiteboard): Es gibt keine Syntax, keine formellen Notationselemente. Nur Stifte.

2.Die Akteure zeichnen: Zeichne die Stakeholder (CEO, Devs, Ops, User) als Strichmännchen auf das Board.

3.Strukturen & Prozesse: Verbinde sie mit dicken Pfeilen für offizielle Datenflüsse und zackigen Blitz-Pfeilen für ständige Konflikte.

4.Denkblasen hinzufügen: Zeichne Sprechblasen oder Gewitterwolken über die Köpfe. (Was denkt das Ops Team gerade wirklich über das "Agile-Manifest" des Managements?)

5.Gekreuzte Schwerter: Markiere die harten politischen Blockaden und Silo-Grenzen aktiv mit Warnschildern oder Mauern.

Beispiel

Eine traditionelle Bank baut eine "Neo-Banking App". Das Projekt steht kurz vor dem Scheitern, weil nichts live geht. Ein Rich Picture wird mit dem Team gezeichnet: Oben thront der "Innovation-Hub" in einer rosa Wolke und träumt von "Krypto" (Denkblase). Unten im Keller schwitzen die "Core-Banking" Mainframe-Operatoren unter einem Berg (Sinnbild für "Regularien und Audit"), aus denen Blitze schießen, immer wenn das Neo-Team ein API-Update fordert. Die Landkarte zeigt: Es gibt keinen technischen Layer, der das Problem löst. Das Problem ist ein radikaler Kultur-Clash (Zwei Welten, die sich aktiv bekämpfen). Das Bild legitimiert es, dieses Tabu-Thema im Management Review anzusprechen.

Diagramm

Wie aus Diagnose Handlung wird

Software-Entwickler hassen Rich Pictures anfänglich, weil es "Kindergarten-Zeichnen" ist. Doch genau darin liegt die Magie: Ein C4-Architektur-Diagramm ist einschüchternd, elitär und steril. Es verbannt Emotionen. Ein Rich Picture ist chaotisch und demokratisch. Plötzlich traut sich der Junior-Tester vorzuspringen und ein fettes rotes "Angst"-Schild neben den CI/CD-Pipeline-Knoten zu malen. Die Informellität der Zeichnung bricht den elitären Schutzschild auf, hinter dem sich toxische Management-Strukturen oft verstecken.

Wann diese Methode die richtige ist

Im Gegensatz zu *Dependency Mapping*, das sehr hart und logisch die API-Abhängigkeiten zählt, ist das Rich Picture weich, soziologisch und unstrukturiert. Es ist der absolute Gegenentwurf zur *Root Definition Analysis*, welche den chaotischen Sumpf der Realität in extrem strikte logische Sätze pressen will.

Wie du die Diagnose im Alltag einsetzt

Wenn in deinem Requirement-Engineering Kickoff alle nur müde auf Exceltabellen starren, brich das Meeting ab. Teile den 10 Leuten Eddings aus und vergleiche am Ende die 10 individuellen "Rich Pictures" der Teams. Du wirst geschockt sein, wie komplett unterschiedlich Frontend, Backend, und Product-Owner die existierende Architektur und ihre "Feinde" in der Firma wahrnehmen. Einigt euch auf ein gemeinsames "Feindbild", bevor Code geschrieben wird.

Erste Analyse-Schritte

Zeichne keine Lösungen in ein Rich Picture! Es ist eine reine Bestandsaufnahme der "Problem-Situation" (Problem Situation Unstructured). Erlaube und erzwinge Humor: Karikaturen des zornigen CTOs oder der einschlafenden Datenbank-Admins helfen, den Elefanten im Raum ohne Vorwürfe besprechbar zu machen.

Woran du eine brauchbare Diagnose erkennst

Wurde vor dem milliardenschweren Rollout unserer neuen "Microservice-Strategie" jemals ein Rich Picture gemalt, das die tatsächliche Frustration, die Überlastung und die Tool-Müdigkeit der Entwickler-Teams dokumentiert?

Quellen

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

Open University — Rich Pictures

Wikipedia: Rich Picture