This site is also available in:
DevOps is being introduced everywhere today. New pipelines, new tools, cloud, Kubernetes, SAFe. The slides look good, the roadmap is green, the budget is in place.
And yet the same thing happens in an astonishing number of organizations:
- Releases take longer instead of shorter.
- Errors occur later instead of earlier.
- Teams block each other, even though they are supposed to be autonomous.
- Quality is falling – despite more automation.
The problem is rarely DevOps. The problem is architecture.
The great illusion: “We’re doing DevOps now”
The transformation usually begins according to the same pattern:
- CI/CD is introduced.
- Teams are given more responsibility (“you build it, you run it”).
- Central quality assurance is dissolved.
- Feature toggles enable “independent” deployments.
- Infrastructure is being modernized – containers, Kubernetes, OpenShift.
Everything is there on paper. Only one thing is missing:
The architecture was not transformed.
The delivery machine has been rebuilt – on a system that was never designed for continuous delivery.
What really happens: Coupling explodes visibly
In the past, a monorelease every two to three months concealed many things. Synchronized baselines, central tests, fixed processes. If something went wrong, it went wrong together – and was fixed together.
DevOps forces the system to function in real time. And suddenly what was previously hidden becomes visible:
- Services are cyclically interdependent.
- Specialist logic is distributed across several systems.
- Data models are shared globally.
- Teams are dependent on each other without realizing it.
DevOps does not create coupling. DevOps makes coupling visible.
The break: Why DevOps doesn’t work here
Without decoupled architecture, the following happens:
- Errors only occur in integration environments.
- Local tests lose their significance.
- CI/CD becomes a blind flight.
- Feature toggles create exponential complexity.
- Responsibilities become blurred.
And at the end:
Nobody can deploy with certainty anymore.
The opposite of what DevOps is supposed to achieve.
The inconvenient truth: architecture is not moving fast enough
This is where things get political.
Architecture cannot be changed “just like that”:
- Established systems.
- Organizational boundaries.
- Historic decisions.
- Lack of domain separation.
Realistically, this takes years.
But DevOps is being introduced today.
This is exactly where the gap arises. And in this gap, teams do what teams always do: they compensate.
What teams actually do when architecture fails to deliver
Not clean. Not ideal. But functional. Four patterns that can be found in almost every transformation organization today:
1. visibility instead of trust: Quality gates with traffic light logic
New, often manual control points are created before production:
- Own tests → green.
- External dependencies → yellow.
- Critical errors → red.
Not elegant – but better than flying blind.
2. interfaces are “simulated”
Since there is no real decoupling, teams make do with:
- Recorded Responses.
- Mocks played locally.
- Self-built comparisons against “last known good condition”.
This is not clean contract testing. It is what remains when architecture is missing.
3. central QS comes back through the back door
The old test organization officially disappears – and reappears in a different form:
- As a supplier of smoketests.
- As a knowledge store for system interrelationships.
- As an implicit quality authority.
Because someone has to understand the system context.
4. integration is pulled forward – as best as possible
Teams try to test earlier: locally, with mocks, with recorded data.
But without a clean architecture, it always remains incomplete.
The real problem: The system is not built to be deployable
And this is the core.
DevOps only works on systems that are built for it. These include
- Clear domain boundaries.
- Minimal coupling.
- Independent data models.
- Testable interfaces.
- Stable invariants.
If these are missing, every pipeline becomes an illusion.
The hard limit: compensation does not scale
The workarounds described work – in the short term. But they come at a price:
- High maintenance effort.
- Increasing complexity.
- Hidden risks.
- Slow feedback loops.
And above all: they do not solve the actual problem. They just make it bearable.
A word to the architecture
This is not an attack. But a clarification.
Architecture is not:
- Documentation.
- Tool selection.
- Target images on PowerPoint slides.
Architecture is:
the ability of a system to be developed, tested and operated independently.
If this is not the case, teams have to compensate. Workarounds arise. Frustration grows. And in the end, the organization loses the very speed that DevOps was supposed to bring.
Conclusion: Who wins – DevOps or architecture?
The answer is uncomfortable:
If architecture doesn’t deliver, DevOps loses.
And then exactly what we see in many organizations today happens:
DevOps is not becoming an accelerator – but a repair strategy.
Good architecture makes DevOps invisible. Bad architecture makes DevOps necessary.
About ONLU
We support banks and insurance companies in Switzerland with precisely this question: How do you build systems that support transformation instead of hindering it? Our focus is on BPM and workflow platforms, process automation and cloud-native architectures on OpenShift and Kubernetes. If you are in the middle of a DevOps transformation and realize that the pipeline is faster than the architecture: talk to us.
