diagnostics

Assumption Mapping

Ein Diagnosewerkzeug, um unausgesprochene Annahmen im Architektur-Design schonungslos aufzudecken, zu kategorisieren und gezielt zu testen.

teamsorganization·3 min Lesezeit

Was ist das?

Ein Diagnosewerkzeug, um unausgesprochene Annahmen im Architektur-Design schonungslos aufzudecken, zu kategorisieren und gezielt zu testen.

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

"Assumption Mapping" (Annahmen-Kartierung) ist eine fundamentale Diagnose-Methode der Systemtheorie und der agilen Produktentwicklung. Sie dient dazu, die oftmals gewaltige Lücke zwischen "Fakten" und "Wunschdenken" in der Softwarearchitektur sichtbar zu machen. Anstatt blind große System-Interventionen (wie einen Cloud-Wechsel) basierend auf Bauchgefühl zu starten, zwingt diese Methode das Team dazu, jeden Schritt des Plans in falsifizierbare Hypothesen zu zerlegen. Sie macht das Eis messbar, auf dem die Architektur gebaut ist.

Einsatzkontext

Diese Methode ist das absolute Mittel der Wahl, bevor große architektonische oder organisatorische Wetten eingegangen werden. Wenn ein Team beschließt: "Wir zerschlagen den Monolithen und gehen auf 200 Microservices, dann werden wir doppelt so schnell entwickeln", ist das keine Tatsache, sondern ein massives Bündel an toxischen Annahmen.

Schritt für Schritt

Das Mapping wird typischerweise auf einem 2x2 Quadranten-Whiteboard durchgeführt:

X-Achse (Beweise): Von "Wir haben absolut keine Daten dafür" bis "Wir haben stichhaltige Metriken".

Y-Achse (Risiko/Einfluss): Von "Unwichtig, wenn wir uns irren" bis "Die Firma brennt nieder, wenn diese Annahme falsch ist".

1.Sammeln: Jeder im Team schreibt seine Annahmen über das neue System auf Post-Its. (z.B. "Kafka wird unsere Latenzen nicht verschlechtern", "Die Devs wollen überhaupt 24/7 Rufbereitschaft machen").

2.Mappen: Die Post-Its werden hart im Quadranten verortet.

3.Fokus: Der oben-links Quadrant ("Hohes Risiko" + "Keine Beweise") wird zur Todeszone (Leap of Faith Assumptions) erklärt.

4.Testen: Es wird *nichts* programmiert, bis exakt diese extrem riskanten Annahmen durch billige Prototypen (Spikes) getestet wurden.

Beispiel

Ein Platform-Team baut ein teures internes Entwickler-Portal ("Backstage"). Ihre Annahme: "Wenn wir es bauen, werden die Feature-Teams es sofort nutzen". Die Diagnose-Session bringt dieses Post-It in den Hochrisiko-Bereich ohne Beweise. Bevor sie 6 Monate Engineering-Zeit investieren, machen sie einen Test: Sie bauen ein simples CLI-Mockup an einem Nachmittag und schicken es per Mail an 3 Feature-Teams. Niemand antwortet. Die Annahme ist geplatzt (falsifiziert), bevor 1 Million Euro an Gehältern verbrannt wurden.

Diagramm

Wie aus Diagnose Handlung wird

Die größte kognitive Verzerrung (Bias) in der IT ist der "Confirmation Bias". Entwickler und Architekten verlieben sich in ein Muster und suchen nur noch nach Beweisen, die belegen, dass es funktionieren wird. Assumption Mapping erfordert radikale intellektuelle Ehrlichkeit. Der Senior Architect muss offen vor seinem Team zugeben können: "Die These, dass Event-Sourcing unser Consistency-Problem löst, ist physikalisch völlig unbewiesen und reines Glücksspiel."

Wann diese Methode die richtige ist

Im Gegensatz zum *System Dynamics Modeling* (welches das gesamte technische Verhalten über Zeit simuliert), ist *Assumption Mapping* extrem ressourcenschonend, stark psychologisch getrieben und fokussiert sich explizit darauf, an welchen Sollbruchstellen das mentale Modell der Entwickler von der Wahrheit abweicht.

Wie du die Diagnose im Alltag einsetzt

Lehne als Principal Architect jegliche "Big Bang" Pitch-Dokumente ab, in denen die Sektion "Unsere kritischsten Annahmen" fehlt. Ein Architektur-Dokument ohne explizit ausgeflaggte Unsicherheiten ist ein Märchenbuch. Verhindere, dass in Meetings Sätze fallen wie "Unsere User wollen das". Frage sofort zurück: "Wo auf unserem Assumption-Board klebt das, und welche Metrik beweist, dass es stimmt?"

Erste Analyse-Schritte

Trenne beim Mappen strikt in drei Überkategorien von Annahmen: Desirability (Will der Developer das Tool überhaupt?), Viability (Können wir uns die AWS-Kosten dafür leisten?), Feasibility (Haben wir technisch überhaupt die Kompetenz, das zu bauen?).

Woran du eine brauchbare Diagnose erkennst

Wurde für das aktuell größte Architektur-Projekt (z.B. die Service Mesh Einführung) ein dedizierter "Spike" (technischer Proof of Concept) im Sprint eingeplant, der exakt *nur* die hochriskanteste Netzwerklatenz-Annahme validieren soll, bevor der Feature-Code geschrieben wird?