
Die Abstraktionsleiter
Über Kommunikation zwischen Maschinenraum und Penthouse
Kommunikation mit nicht technischen Stakeholdern kann extrem frustrierend sein. Wir erläutern ihnen mit engelsgleicher Geduld haargenau, mit welchen Modernisierungen, Refactorings oder neuen Technologien wir unsere Software endlich bereit für die Zukunft machen können, und sie schauen uns mit leerem Blick an oder suchen bereits nach wenigen Minuten verzweifelt nach einem Fluchtweg zurück in die echte Welt. Egal wie legitim unsere dargelegten Argumente auch sind, sie alle verpuffen, wie ein Tropfen auf dem heißen Stein.
Das Problem liegt selten an der Qualität unserer Argumente. Es liegt daran, dass wir sie auf der falschen Flughöhe vortragen. Nicht jede Zielgruppe stellt uns dieselbe Frage.
Zwei Blickwinkel
Entwickler, Betriebler oder allgemein Praktiker im Maschinenraum des Projekts stellen sich vor allem Fragen, die mit einem “Wie?” beginnen. Wie schneiden wir die Module sauber? Wie machen wir die Kommunikation zwischen den Diensten ausfallsicher? Wie migrieren wir die Datenbank, ohne die Nacht im Rechenzentrum zu verbringen?
Stakeholder im Penthouse, bspw. Manager oder allgemein Entscheidungsträger hingegen stellen sich vor allem Fragen, die mit einem “Warum?” beginnen. Warum müssen wir den Modulschnitt überhaupt jetzt anfassen? Warum braucht ihr zusätzliches Budget, um die Ausfallsicherheit zwischen den Diensten zu verbessern? Oder allgemein: Was bringt uns das, außer zusätzlichem Aufwand, den wir doch viel besser in Features investieren sollten?
Beide Blickwinkel sind legitim. Beide müssen beantwortet werden, um erfolgreich zu sein. Allerdings benötigen sie Antworten auf unterschiedlichen Abstraktionsebenen.
Die Abstraktionsleiter
Diese Unterscheidung zwischen konkreter und abstrakter Kommunikation ist kein reines IT-Phänomen. Der Linguist S. I. Hayakawa beschrieb sie 1939 als “Ladder of Abstraction”1: Ganz unten steht “Bessie”, eine ganz bestimmte Kuh. Eine Stufe höher wird daraus “Kuh”, dann “Vieh”, dann “Vermögenswert”, bis am oberen Ende nur noch “Wohlstand” übrig bleibt. Jede Stufe lässt Details fallen, die auf der vorherigen noch da waren.
Übertragen auf unsere Arbeit heißt das: Im Maschinenraum reden wir über das Refactoring einer konkreten Klasse, den Wechsel eines Protokolls oder die Ablösung einer Datenbanktechnologie. Steigen wir die Leiter hoch, wird daraus die fachliche Begründung einer Änderung, die erwartete Kostenersparnis, der Effekt auf die Zufriedenheit der Nutzer. Die Fakten bleiben dieselben, aber wir müssen unsere Sprache anpassen.
Der Fahrstuhl
Für die organisatorische Version dieser Bewegung liefert Gregor Hohpe ein Bild, das sich unter Architekten durchgesetzt hat: der Architect Elevator. Er beschreibt einen Fahrstuhl, der von der Vorstandsetage eines Unternehmens bis in den Maschinenraum reicht, in dem die Software tatsächlich gebaut wird2. Architekten sind für ihn diejenigen, die in diesem Aufzug fahren, statt nur auf einer Etage zu verweilen. Sein Bild für die Konsequenz, wenn diese Verbindung fehlt, stammt aus der Seefahrt: Sichtet die Brücke ein Hindernis und funkt “volle Kraft zurück”, der Maschinenraum aber bekommt das Kommando nicht mit und fährt unbeirrt weiter, ist die Havarie programmiert3. Genau dafür gab es auf alten Dampfschiffen ein Rohr, durch das der Kapitän direkt mit dem Heizer sprechen konnte.
Wichtig ist mir hier die Abgrenzung: Hayakawas Leiter beschreibt, wie sich Sprache zwischen konkret und abstrakt bewegt. Hohpes Aufzug beschreibt, wie sich eine Organisation in Etagen gliedert und wessen Aufgabe es ist zwischen den Ebenen zu vermitteln. Beide Bilder ergänzen sich gut, sie sind aber nicht dasselbe - die Abstraktionsleiter ist das sprachliche Werkzeug, mit dem wir uns im Architect Elevator bewegen.
flowchart TD
A["Penthouse<br/>Management, Strategie"] -->|"Warum?"| B["Mittleres Management<br/>Produktverantwortliche, Teamleitung"]
B -->|"Wie? / Warum?"| C["Maschinenraum<br/>Entwicklung, Betrieb"]
C -->|"Wie?"| B
B -->|"Zusammenfassung, Wirkung"| A
Technik allein überzeugt nicht
Wir könnten dem Management natürlich trotzdem das Klein-Klein erklären. Machbar ist das fast immer. Nur holt es die Zuhörenden nicht dort ab, wo sie stehen, und produziert nicht selten das Gegenteil von Überzeugung.
Die Sozialpsychologie hat dafür einen Begriff: Reaktanz. Nach Brehm entsteht Widerstand immer dann, wenn Menschen den Eindruck gewinnen, ihre Entscheidungsfreiheit werde eingeschränkt4. Wer einem CFO zwanzig Minuten lang Kafka-Partitionierung erklärt, obwohl der eigentlich nur wissen wollte, ob das Budget hält, engt genau diese Freiheit ein: die Freiheit, selbst zu entscheiden, wie tief er einsteigen möchte. Das Ergebnis ist selten Zustimmung. Es ist Widerstand gegen etwas, das inhaltlich vielleicht völlig richtig, aber fehl am Platz war.
Aufklärung ist keine Holschuld
Damit bin ich bei einer Position, die ich bewusst vertrete und die nicht jeder Architekt teilt: Nicht-technische Stakeholder technisch “aufzuschlauen”, damit sie unsere Sprache verstehen, ist für mich kein Ziel an sich. Technische Expertise angemessen zu kommunizieren ist unsere Aufgabe. Technik zu verstehen ist keine Bringschuld des Managements.
Stellt jemand aus dem Penthouse eine konkrete Nachfrage zum Wie, dann steigen wir gemeinsam mit ihnen die Leiter für diese eine Frage herab. Aber der Normalfall bleibt: Wir begegnen Stakeholdern auf ihrer Flughöhe und zwingen diese nicht auf unsere zu steigen.
Die Flughöhe ist eine Entscheidung
Die Wahl der Abstraktionsebene sollte in unserer Kommunikation kein Zufall sein. Sie sollte immer eine Entscheidung sein, die wir für ein Gespräch bewusst treffen. Will mein Gegenüber gerade wissen, wie etwas funktioniert, oder warum es passieren muss? Die Antwort darauf entscheidet, ob wir effektiv kommunizieren oder nicht.
Footnotes
-
S. I. Hayakawa: Language in Thought and Action, 1939/1949. Zusammenfassung des Konzepts u. a. bei Big Think: Boost your communication skills with the “ladder of abstraction”. ↩
-
Gregor Hohpe: The Software Architect Elevator – Redefining the Architect’s Role in the Digital Enterprise, O’Reilly Media, 2020. ↩
-
Gregor Hohpe: The Architect Elevator – Visiting the upper floors, martinfowler.com. ↩
-
J. W. Brehm: A Theory of Psychological Reactance, 1966. Deutschsprachige Einordnung u. a. bei Springer Professional: Die Theorie psychologischer Reaktanz. ↩
