Die drei Übergänge: Architektur, Delivery, Adoption

Wenn ein Vorhaben scheitert, wird meistens eine Phase beschuldigt: die Architektur war zu abgehoben, das Team zu langsam, die Fachabteilung zu unwillig. In der Rückschau liegt der Bruch fast nie mitten in einer Phase. Er liegt an den Übergängen.

Übergang 1: Architektur → Delivery

Ein Architekturbild wird übergeben und das Team beginnt zu bauen. Was dabei verloren geht, sind die Begründungen. Das Team sieht das Ergebnis der Entscheidungen, nicht die Abwägungen dahinter. Beim ersten Widerstand in der Realität wird die Entscheidung dann still korrigiert — ohne dass jemand prüft, ob die ursprüngliche Randbedingung noch gilt.

Was hilft:

• Entscheidungen als kurze ADRs festhalten: Kontext, Optionen, Wahl, Konsequenz. Zwei Absätze reichen.
• Die Person, die geschnitten hat, bleibt in der Umsetzung erreichbar — nicht als Aufsicht, sondern als Gegenüber.
• Ein Event Model statt eines Kastendiagramms: Es beschreibt Abläufe, nicht nur Komponenten, und ist für Fachbereich und Team gleichermaßen lesbar.

Übergang 2: Delivery → Betrieb

Das Feature ist fertig, die Pipeline grün, das Ticket geschlossen. Dass niemand weiß, wie man den Zustand im Fehlerfall rekonstruiert, fällt erst im ersten Incident auf.

Production-Readiness ist keine Abnahmestufe am Ende, sondern eine Eigenschaft, die pro Scheibe mitwächst: Logging mit Korrelation, Metriken mit Schwellwerten, ein Alarm, der jemanden erreicht, ein Runbook für die zwei wahrscheinlichsten Fehler. Wer das ans Ende schiebt, baut technische Schulden mit Zinseszins.

Übergang 3: Betrieb → Adoption

Der teuerste Übergang. Das System läuft stabil, und die Fachabteilung arbeitet weiter in ihrer Tabelle.

Adoption scheitert selten an Funktionen. Sie scheitert daran, dass der neue Ablauf mehr Aufwand macht als der alte, dass niemand erklärt hat, warum sich etwas ändert, oder dass die Person, die es erklären könnte, nach dem Go-live nicht mehr da ist.

Was hilft:

• Adoption ab dem ersten Tag mitplanen, nicht nach dem Go-live. Wer die Fachabteilung im Event Modeling dabei hat, muss später weniger überzeugen.
• Eine benannte Person im Fachbereich, die das System vertritt — nicht eine Rolle, sondern ein Name.
• Messen, ob der Ablauf tatsächlich genutzt wird. Nutzungszahlen sind ehrlicher als Feedback-Runden.

Ownership ist die Klammer

Alle drei Bruchstellen haben dieselbe Ursache: Verantwortung wechselt den Besitzer, ohne dass es jemand ausspricht. Deshalb steht bei uns am Anfang eines Vorhabens eine Ownership-Karte: Wer entscheidet, wer baut, wer betreibt, wer erklärt — namentlich, nicht per Rolle. Diese Karte kostet eine Stunde und beantwortet später die Fragen, die sonst wochenlang im Kreis laufen.

Gute Software entsteht nicht dort, wo eine Phase besonders gut gemacht wird. Sie entsteht dort, wo die Übergänge niemandem überlassen werden.