In Diskussionen über IT-Zielarchitekturen geht es erstaunlich oft um Technologien, Patterns und Plattformen. Selten um eine Frage, die für den Geschäftserfolg eigentlich auch zählt: Wie lange dauert es, eine neue Funktion produktiv zu bringen. Und wer entscheidet darüber.
Ein einfacher Test, den ich in Assessments regelmäßig einsetze. Nimm eine konkrete, kleine Funktion. Eine neue Metadatenregel im ECM, eine zusätzliche Guardrail für einen KI-Agenten, ein zusätzliches Sortierkriterium oder Maskenfeld. Und frage drei Dinge:
- Wie viele Abstimmungsrunden braucht es, bevor diese Funktion live geht?
- Wer darf heute Nein sagen, und wer darf Ja sagen?
- Wie lange dauert es, bis diese Funktion dann wirklich beim Benutzer landet?
Die Antworten sind aufschlussreicher als jedes Architekturdiagramm.
Geht die Funktion in Tagen live, ist die Architektur weitgehend gesund. Braucht sie Wochen, gibt es meist ein Strukturproblem. Modulgrenzen, Testabdeckung, Release-Prozess. Braucht sie Monate, ist die Architektur nur das Symptom. Das eigentliche Problem sitzt in der Governance.
Der DORA State of DevOps Report, seit über zehn Jahren die Referenz für Software-Delivery-Performance, hat 2025 bewusst aufgehört, Teams in „Elite" und „Low" einzuteilen. Stattdessen rücken Friktion, Entscheidungswege und wahrgenommener Wert in den Vordergrund. Das ist kein methodischer Zufall. Es ist die Einsicht, dass Durchlaufzeit keine rein technische Kennzahl ist.
In vielen Häusern, die ich begleite, ist genau das der wunde Punkt. Niemand darf wirklich entscheiden. Oder will es nicht.
Das ist selten ein Personen-Problem. Es ist ein Rollenlogiken-Problem: Architekt, Release Manager, Entwickler, Projektleiter, Stakeholder, Sponsor und Benutzer haben berechtigte, aber divergierende Erwartungen an dieselbe Entscheidung. Jeder tut das Richtige aus seiner Perspektive. Alles wird in zu vielen Meetings eskaliert, diskutiert, abgestimmt, dokumentiert. Und nach vier Wochen weiß keiner mehr, warum ein Komma in einer Konfigurationsdatei einen Lenkungsausschuss brauchte.
Das lässt sich nicht mit Cloud-Migration, Microservices oder einer neuen Integrationsplattform lösen. Diese Maßnahmen machen das Problem sogar sichtbarer, nicht kleiner. Eine moderne Architektur zeigt gnadenlos, wo Entscheidungswege zu lang und Verantwortlichkeiten zu diffus sind.
Das eigentliche Ziel einer Architektur-Modernisierung ist nicht nur technisch. Sie ist das Werkzeug, um Entscheidungskompetenz wieder an den richtigen Stellen zu platzieren. Möglichst nah am Problem, möglichst weit weg von der Eskalation.
Wer über Architektur spricht, ohne über Governance und Verantwortung zu sprechen, löst nicht das Problem, das weh tut. Er verschiebt es nur in ein moderneres Diagramm.