Diese Seite ist auch verfügbar in:
DevOps wird heute überall eingeführt. Neue Pipelines, neue Tools, Cloud, Kubernetes, SAFe. Die Folien sehen gut aus, die Roadmap ist grün, das Budget steht.
Und trotzdem passiert in erstaunlich vielen Organisationen dasselbe:
- Releases dauern länger statt kürzer.
- Fehler entstehen später statt früher.
- Teams blockieren sich gegenseitig, obwohl sie autonom sein sollen.
- Qualität sinkt – trotz mehr Automatisierung.
Das Problem ist selten DevOps. Das Problem ist Architektur.
Die grosse Illusion: „Wir machen jetzt DevOps“
Die Transformation beginnt meist nach demselben Muster:
- CI/CD wird eingeführt.
- Teams bekommen mehr Verantwortung („you build it, you run it“).
- Zentrale Qualitätssicherung wird aufgelöst.
- Feature Toggles ermöglichen „unabhängige“ Deployments.
- Infrastruktur wird modernisiert — Container, Kubernetes, OpenShift.
Auf dem Papier ist alles da. Nur eines fehlt:
Die Architektur wurde nicht mittransformiert.
Man hat die Auslieferungsmaschine neu gebaut – auf einem System, das nie dafür entworfen wurde, kontinuierlich ausgeliefert zu werden.
Was wirklich passiert: Kopplung explodiert sichtbar
Früher hat ein Monorelease alle zwei bis drei Monate vieles kaschiert. Synchronisierte Baselines, zentrale Tests, feste Prozesse. Wenn etwas schiefging, ging es gemeinsam schief – und wurde gemeinsam repariert.
DevOps zwingt das System, in Echtzeit zu funktionieren. Und plötzlich wird sichtbar, was vorher versteckt war:
- Services sind zyklisch voneinander abhängig.
- Fachlogik verteilt sich über mehrere Systeme.
- Datenmodelle sind global geteilt.
- Teams sind voneinander abhängig, ohne es zu wissen.
DevOps erzeugt keine Kopplung. DevOps macht Kopplung sichtbar.
Der Bruch: Warum DevOps hier nicht funktioniert
Ohne entkoppelte Architektur passiert Folgendes:
- Fehler entstehen erst in Integrationsumgebungen.
- Lokale Tests verlieren ihre Aussagekraft.
- CI/CD wird zum Blindflug.
- Feature Toggles erzeugen exponentielle Komplexität.
- Verantwortlichkeiten verschwimmen.
Und am Ende:
Niemand kann mehr mit Sicherheit deployen.
Das Gegenteil von dem, was DevOps eigentlich erreichen soll.
Die unbequeme Wahrheit: Architektur bewegt sich nicht schnell genug
Hier wird es politisch.
Architektur lässt sich nicht „mal eben“ ändern:
- Gewachsene Systeme.
- Organisatorische Grenzen.
- Historische Entscheidungen.
- Fehlende Domänentrennung.
Realistisch dauert das Jahre.
DevOps wird aber heute eingeführt.
Genau hier entsteht die Lücke. Und in dieser Lücke tun Teams das, was Teams immer tun: sie kompensieren.
Was Teams tatsächlich tun, wenn Architektur nicht liefert
Nicht sauber. Nicht ideal. Aber funktional. Vier Muster, die man heute in nahezu jeder Transformationsorganisation findet:
1. Sichtbarkeit statt Vertrauen: Quality Gates mit Ampellogik
Vor Produktion entstehen neue, oft manuelle Kontrollpunkte:
- Eigene Tests → grün.
- Fremde Abhängigkeiten → gelb.
- Kritische Fehler → rot.
Nicht elegant – aber besser als Blindflug.
2. Schnittstellen werden „simuliert“
Da echte Entkopplung fehlt, behelfen sich Teams mit:
- Aufgezeichneten Responses.
- Lokal abgespielten Mocks.
- Selbstgebauten Vergleichen gegen „letzter bekannter guter Zustand“.
Das ist kein sauberes Contract Testing. Es ist das, was übrig bleibt, wenn Architektur fehlt.
3. Zentrale QS kommt durch die Hintertür zurück
Die alte Testorganisation verschwindet offiziell – und taucht in anderer Form wieder auf:
- Als Lieferant von Smoketests.
- Als Wissensspeicher für Systemzusammenhänge.
- Als implizite Qualitätsinstanz.
Weil jemand die Systemzusammenhänge verstehen muss.
4. Integration wird nach vorne gezogen – so gut es geht
Teams versuchen, früher zu testen: lokal, mit Mocks, mit aufgezeichneten Daten.
Aber ohne saubere Architektur bleibt das immer unvollständig.
Das eigentliche Problem: Das System ist nicht deploybar gebaut
Und hier liegt der Kern.
DevOps funktioniert nur auf Systemen, die dafür gebaut sind. Dazu gehören:
- Klare Domänengrenzen.
- Minimale Kopplung.
- Unabhängige Datenmodelle.
- Testbare Schnittstellen.
- Stabile Invarianten.
Wenn diese fehlen, wird jede Pipeline zur Illusion.
Die harte Grenze: Kompensation skaliert nicht
Die beschriebenen Workarounds funktionieren – kurzfristig. Aber sie haben einen Preis:
- Hoher Wartungsaufwand.
- Steigende Komplexität.
- Versteckte Risiken.
- Langsame Feedback-Loops.
Und vor allem: sie lösen nicht das eigentliche Problem. Sie machen es nur ertragbar.
Ein Wort an die Architektur
Das ist kein Angriff. Aber eine Klarstellung.
Architektur ist nicht:
- Dokumentation.
- Tool-Auswahl.
- Zielbilder auf PowerPoint-Folien.
Architektur ist:
die Fähigkeit eines Systems, unabhängig entwickelt, getestet und betrieben werden zu können.
Wenn das nicht gegeben ist, müssen Teams kompensieren. Entstehen Workarounds. Wächst Frustration. Und am Ende verliert die Organisation genau die Geschwindigkeit, die DevOps eigentlich bringen sollte.
Fazit: Wer gewinnt – DevOps oder Architektur?
Die Antwort ist unbequem:
Wenn Architektur nicht liefert, verliert DevOps.
Und dann passiert genau das, was wir heute in vielen Organisationen sehen:
DevOps wird nicht zum Beschleuniger – sondern zur Reparaturstrategie.
Gute Architektur macht DevOps unsichtbar. Schlechte Architektur macht DevOps notwendig.
Über ONLU
Wir begleiten Banken und Versicherungen in der Schweiz bei genau dieser Frage: Wie baut man Systeme, die Transformation tragen statt sie zu behindern? Unser Fokus liegt auf BPM- und Workflow-Plattformen, Prozessautomatisierung und Cloud-nativen Architekturen auf OpenShift und Kubernetes. Wenn ihr gerade in einer DevOps-Transformation steckt und merkt, dass die Pipeline schneller ist als die Architektur: sprecht uns an.
