Es ist Donnerstagmorgen, 9:40, und Sandra, Lead Architect bei einem großen deutschen Industriekonzern, steht vor einem Whiteboard und zeichnet eine Architektur. Lose gekoppelt, klare Domänengrenzen, durchdachte Schnittstellenverträge. Es ist die richtige Architektur. Sie weiß es. Ihr Team weiß es.
Um 10:15 geht Sandra ins Steering Committee. Vierzehn Personen, drei Beamer. Der Bereichsleiter unterbricht nach Slide zwei. Er war letzte Woche auf einer Konferenz. Er hat einen Vortrag über "Headless API-First" gehört. Er hat nicht alles verstanden, aber genug, um es in einem Steering Committee zu sagen. Er fragt, warum die Plattform nicht Headless API-First gebaut wird. Was Sandra vorschlägt, klingt kompliziert. Headless klingt modern.
Um 11:00 ist die Architektur Headless API-First. Nicht weil es richtig ist. Nicht weil jemand die Implikationen durchdacht hat. Sondern weil die Institution es so will. Niemand in diesem Raum ist inkompetent. Die Leute sind nicht das Problem. Das System ist das Problem.
Drei Wochen später sitzt ein externer Berater am selben Tisch. Er ist gut. Er hat zwanzig Jahre Erfahrung. Nach zwei Tagen Workshop kommt er zu exakt dem Schluss, den Sandra von Anfang an hatte. Lose Kopplung. Klare Domänengrenzen. Die richtige Architektur.
Der Bereichsleiter hört zu, nickt, und sagt: "Aber wir haben uns doch auf Headless API-First geeinigt." Der Berater zögert. Dann greifen seine eigenen Strukturen: der Kunde ist König. Der Kunde will nicht hören, dass er falsch liegt. Der Kunde will hören, dass seine Intuition richtig war. Also passt der Berater seine Empfehlung an. Er nennt es "pragmatische Anpassung an die bestehende Entscheidungslandschaft". Sandra nennt es anders.
Die Rolle des Beraters wäre, zu beraten. Zu sagen, was richtig ist, auch wenn es unbequem ist. Aber die Anreizstruktur der Beratung zeigt in die andere Richtung: Folgeaufträge, Kundenzufriedenheit, Referenzen. Wer dem Kunden widerspricht, riskiert den Vertrag. Also bestätigt der Berater, was der Kunde bereits beschlossen hat, und nennt es Strategie.
Es sind nicht die Menschen. Es ist die Maschine.
In fast jedem Konzern existiert eine unsichtbare Kraft, die technische Entscheidungen formt, ohne je eine Zeile Code geschrieben zu haben. Es ist keine Person. Es ist die Institution selbst — ihre Bewertungszyklen, ihre Anreizsysteme, ihre Governance-Rituale. Zusammen erzeugen sie ein Gravitationsfeld, das jede Architekturentscheidung in seine Richtung biegt.
Nicht weil jemand Böses will. Sondern weil das System so gebaut ist, dass rationale Akteure irrational handeln. Wenn Anreize und Ingenieurskunst kollidieren, gewinnen die Anreize. Immer.
Der jährliche Bewertungszyklus als stiller Saboteur
Jedes Jahr, zwischen Oktober und Dezember, passiert in deutschen Unternehmen etwas, das offiziell "Zielvereinbarungsgespräch" heißt und inoffiziell "die zwei Wochen, in denen nichts anderes zählt". Führungskräfte bewerten ihre direkten Mitarbeiter. Das klingt vernünftig. Das Problem ist die Mechanik.
Ab September beginnt ein unsichtbarer Wettlauf. Jeder braucht etwas Vorzeigbares. Etwas, das "Impact" hat. Refactoring hat keinen Impact. Technische Schulden abbauen hat keinen Impact. "Was haben Sie dieses Jahr erreicht?" — "Ich habe die Codebasis aufgeräumt." Das ist kein Satz, der Beförderungen auslöst.
Nur 14 Prozent der Mitarbeiter geben an, dass jährliche Bewertungsgespräche sie zu besserer Arbeit inspirieren. Schlimmer: 66 Prozent berichten, dass jährliche Leistungsbeurteilungen ihre Produktivität senken. Das System, das Leistung messen soll, zerstört Leistung.
Also baut Sandra nicht das, was technisch sinnvoll wäre. Sandra baut ein neues Microservice-Gateway, weil das auf einer Bewertungsfolie besser klingt als "bestehende Codebasis stabilisiert". Sie ist nicht opportunistisch. Sie ist rational. Das System sagt: Bau Neues. Sichtbares. Vorzeigbares.
Die Roadmap gehört dem Business. Engineering trinkt aus dem Feuerwehrschlauch.
In den meisten Organisationen wird die Roadmap vom Business geschrieben. Engineering bestimmt, wie es gebaut wird. Theoretisch. Praktisch ist es Drinking from the Firehose: zu viele konkurrierende Prioritäten, kein Raum für Fundamente, und das "Wie" wird durch das "Was" und das "Wann" so eingeschränkt, dass keine echten Entscheidungen bleiben. Jedes Feature wird auf die bestehende Headless-Architektur geschraubt, weil ein Umbau drei Monate kosten würde, die niemand budgetiert hat.
Engineering wird zur Erfüllungsstation. Die Architektur ist kein Entwurf mehr, sie ist ein Nebenprodukt — Schicht für Schicht, Feature für Feature, jedes unter Zeitdruck, keines mit Blick aufs Ganze.
Die Institution trennt die Leute, die wissen, was möglich ist, von den Leuten, die entscheiden, was gemacht wird. Und dann wundert sie sich, dass die Ergebnisse weder möglich noch gemacht sind.
Goodharts Gesetz und die Metrik-Falle
"Jede beobachtete statistische Regelmäßigkeit tendiert dazu zu kollabieren, sobald Druck auf sie ausgeübt wird, um sie zu Kontrollzwecken zu nutzen."
Sobald eine Metrik zum Ziel wird, hört sie auf, eine gute Metrik zu sein. Velocity wird gemessen — also werden Story Points inflationiert. Test Coverage wird gemessen — also werden Tests geschrieben, die nichts testen. Deployment Frequency wird gemessen — also wird häufiger deployed, ob die Änderungen sinnvoll sind oder nicht.
Die Institution misst, was messbar ist. Nicht was wichtig ist. Die Architektur wird gebaut, um Metriken zu erfüllen. Feature-Velocity statt Systemstabilität. Coverage-Prozentsätze statt Fehlerfreiheit. Goodhart hat das 1975 formuliert. Wir haben es immer noch nicht verstanden.
Die politische Ökonomie technischer Entscheidungen
TOGAF, das meistverbreitete Enterprise-Architecture-Framework der Welt, enthält einen Satz, der ehrlicher ist als alles andere in der Enterprise-IT: "Corporate politics is critical to enterprise architecture."
In der Praxis: Der Bereich mit dem größten Umsatz bekommt die meisten Entwickler. Der VP, der am lautesten spricht, bekommt sein Feature. Die Plattform, die der CTO vor drei Jahren ausgewählt hat, wird nicht in Frage gestellt — weil sie in Frage zu stellen hieße, den CTO in Frage zu stellen.
Conway's Law ist kein Witz. Organisationen entwerfen Systeme, die ihr Organigramm abbilden. Drei Teams, drei Budgets, drei Definitionen von Erfolg — also ein System mit drei Teilen. Sandra hat die richtige Architektur gezeichnet. Aber sie passt nicht zum Organigramm. Also zeichnet Sandra eine andere.
Slow Is Smooth, Smooth Is Fast
Slow is smooth, smooth is fast. Navy SEALs lernen das am ersten Tag. Institutionen verstehen es nicht. "Wann ist es fertig?" ist die häufigste Frage in jedem Steering Committee. Nicht "Ist es richtig?". Nicht "Wird es halten?".
Also wird schnell gebaut. Und weil schnell gebaut wird, wird schlampig gebaut. Und weil schlampig gebaut wird, dauert es länger, als wenn man es von Anfang an sauber gemacht hätte. Eine Woche investieren, um die Domäne zu verstehen, sieht aus wie Stillstand. Es ist die Investition, die drei Monate Umbau verhindert. Aber die Institution sieht den Umbau nicht, weil er in der Zukunft liegt.
Institutionen belohnen Helden, die Nächte durcharbeiten, um Releases zu retten. Sie sollten Systeme belohnen, die keine Helden brauchen.
Der Mut zur Neubewertung
Nein ist das unpopulärste Wort in einem Konzern. Nein heißt: Wir haben uns geirrt. Also sagt niemand nein. Stattdessen wird "re-scoped", "pivotiert" oder "in Phase 2 verschoben" — wobei Phase 2 ein Euphemismus für "nie" ist.
Sandra weiß, dass das dritte Microservice-Projekt keinen Sinn ergibt. Niemand sagt es. Weil Nein sagen heißt, den Stakeholder zu verärgern, im Bewertungszyklus schlecht dazustehen, kein Budget zu bekommen. Also baut Sandra es. Pünktlich. Im Budget. Korrekt implementiert. Niemand benutzt es.
Institutionen bauen, die ihre eigene Architektur nicht auffressen
Was wäre, wenn Bewertungszyklen kontinuierlich wären statt jährlich? Wenn Refactoring genauso belohnt würde wie ein neues Feature? Wenn die Roadmap gemeinsam mit Engineering entworfen würde statt vom Business diktiert?
Es gibt Organisationen, die das tun. Sie messen Lead Time statt Velocity. Incidents statt Coverage-Prozentsätze. Outcome statt Feature-Output. Sie geben Engineering eine Stimme als Designpartner, nicht als Erfüllungsgehilfe.
Sandra steht wieder vor ihrem Whiteboard. Die Headless-API steht auf der Roadmap. Sie ist eine gute Architektin. Sie weiß, welches System das richtige wäre. Aber sie baut das System, das die Institution belohnt.
Die Institution ist die Architektur. Solange wir nur die Software umbauen, aber nicht die Organisation, die sie produziert, bekommen wir immer wieder dasselbe: gute Menschen in schlechten Systemen. Das Whiteboard hat die richtige Architektur. Das Organigramm hat eine andere. Und das Organigramm gewinnt. Immer.