Flexible architecture is considered one of the most important goals in modern software development. In practice, however, it often fails due to tight coupling, unclear responsibilities, and premature technology decisions. In this interview, Eberhard Wolff and Falk Sippach explain how flexibility can actually be achieved through clear domain boundaries, suitable architectural models, and continuous architecture work.
Many people talk about “flexible architecture.” What does flexibility mean for you in practice, and how can you tell whether a system is truly flexible?
Flexibility primarily means that a system can respond to change without every adjustment becoming expensive, risky, or slowing down development. It is not about keeping as many options open as possible, but about implementing changes in a targeted and manageable way.
You can recognize true flexibility in everyday work: Do changes remain local? Are dependencies manageable? Can new requirements be implemented without major side effects and independently of other teams?
In your experience, what are the biggest obstacles preventing teams from implementing flexible architectures? How can these challenges be overcome?
The biggest obstacle is often short term delivery pressure. Clean boundaries, well designed modules, and continuous architecture work require additional effort at first, but they pay off in the long run. In many cases, the pressure is so high that teams never get the chance to think about a sustainable architecture.
Other challenges include unclear responsibilities, historically grown structures, and the temptation to adopt technical trends without fully understanding the underlying problem. These issues can only be overcome step by step through greater transparency regarding dependencies, clearer domain boundaries, and architecture work as a continuous team responsibility.
In your session, you talk about both Domain-driven Design and Microservices and Self-contained Systems. How do these approaches work together when it comes to flexibility?
Domain-driven Design helps identify meaningful domain boundaries. This is exactly where flexibility begins: with understanding the domain and defining clear responsibilities.
Microservices and Self-contained Systems can build upon this foundation and provide technical flexibility, but they are not an end in themselves. Without well-defined domain boundaries, there is no real business flexibility, and that is often what matters most. DDD therefore provides the foundation for making informed decisions between a modulith, microservices, or self-contained systems and their respective trade-offs.
Many organizations adopt microservices without actually becoming more flexible. What is commonly done wrong, and what should teams focus on instead?
Microservices are often introduced as a modern architectural style without fully understanding both their benefits and their challenges. Teams distribute a system before clarifying domain boundaries, dependencies, and team responsibilities.
The result is often a landscape of many small services with strong coupling and significant coordination overhead. In many situations, a well structured modulith can be the better starting point. If scalability or independence requirements increase later on, parts of the system can still be extracted into microservices.
If a team wants to make an existing system more flexible today, what concrete first steps should it take?
The first step should be identifying the biggest pain points regarding change. Where do changes take too long? Where do unintended side effects repeatedly occur? Which dependencies are slowing the team down the most?
After that, teams should sharpen domain responsibilities, improve module boundaries, and reduce dependencies. It is important not to start with a huge target architecture, but with small and concrete improvements in the areas that are already being changed anyway.
How is the topic of flexible architecture evolving today, for example through new requirements such as AI or the need to deliver features faster?
Flexible architecture is becoming even more important because requirements, technologies, and markets are changing faster than ever. Teams need to deliver more quickly while simultaneously dealing with greater uncertainty.
This becomes especially visible in the area of AI. At the beginning, it is often unclear which models, providers, or integration approaches will prevail in the long term. That is exactly why architectures are needed that allow experimentation, limit coupling, and enable change without destabilizing the overall system.
More on this topic at the Software Architecture Forum 2026. In their session, Eberhard Wolff and Falk Sippach will demonstrate how flexible architectures can be designed using Domain-driven Design, moduliths, microservices, and self contained systems, and what really matters in practice.
