IT modernization is currently one of the dominant topics across many organizations. New market demands, increasing cost pressure, and technological developments such as AI are pushing companies to rethink their existing systems. At the same time, experience shows that these initiatives are often more complex than anticipated and frequently fail to deliver the expected results.
A recent project illustrates this situation clearly. Over many years, a system had evolved into a monolith built on more than 25 different technologies and programming languages. It was deployed in over 200 installations, many of them tailored to specific customer requirements. At the same time, knowledge about the system had become fragmented: individual parts were understood, but a shared understanding of the system as a whole no longer existed.
This situation is not an exception. It is typical for many long-lived IT landscapes.
When systems are no longer evolvable
The real challenges are not primarily visible in architecture diagrams, but in day-to-day operations. Changes become increasingly risky because their impact on other parts of the system can no longer be reliably assessed. Customer-specific adaptations regularly introduce unintended side effects, as implicit dependencies remain hidden. At the same time, quality assurance turns into a bottleneck, since the system’s behavior can no longer be consistently reproduced or verified.
In this particular case, a single installation took more than a year to complete and had to be carried out on-site at the customer. At the same time, new business requirements—such as data visualization—could not be implemented. Not because of a lack of technical expertise, but because the existing system structure made such changes practically impossible.
The system continued to function.
But it was no longer capable of evolving.
Common assumptions – and why they fail
In situations like this, two assumptions frequently emerge. The first is the belief that the existing system is generally understood. The second is the expectation that new technologies—particularly AI—will take over much of the modernization effort.
Both assumptions tend to break down in practice.
In the project described, it quickly became clear that there was no shared understanding of the system. Knowledge existed, but it was distributed across individuals and teams. Decisions were made locally, without fully understanding their impact on the overall system.
The expectation that technology alone can solve these problems is equally misleading. Tools such as LLMs can leverage and accelerate existing structures, but they cannot replace a missing understanding of the domain. Without clearly defined relationships and boundaries, there is no solid foundation for meaningful automation or generation.
Why traditional modernization approaches fall short
Against this backdrop, it becomes clear why many modernization efforts do not achieve their intended outcomes. A common reaction is to design a new architecture or even attempt a complete rebuild. While these approaches may be technically sound, they fall short if the underlying domain structure is not properly understood.
In practice, this often leads to a situation where existing complexity is not reduced, but simply transferred into a new technological environment. Dependencies remain, business ambiguities persist, and the fundamental problems are carried forward rather than resolved.
The technology changes.
The complexity stays.
Domain-Driven Design as a structuring approach
The turning point in the project did not come from a technical decision, but from a shift in perspective. Instead of focusing immediately on target architectures, the team started by analyzing the system from a business domain perspective.
Key questions included: What domains actually exist? How are they connected? And which of them are truly critical to the business?
A crucial difference was that this analysis was not performed by IT alone. Only through the involvement of business stakeholders did a shared understanding of the domains and their relationships emerge. This shared model became the foundation for all subsequent decisions.
The role of an external perspective
An often underestimated factor in this context is the value of an external perspective. In long-established organizations, many structures become implicit and are no longer questioned. Historical decisions are continued, even when their original rationale no longer applies.
An external perspective does not necessarily introduce better ideas, but it helps to make existing assumptions visible and subject them to systematic scrutiny. This is what enables real prioritization.
What changes as a result
With a clear understanding of domains, the perspective on modernization shifts fundamentally. The central question is no longer how to replace the system as a whole, but which parts are actually relevant, where investment creates value, and which areas can intentionally remain unchanged.
Modernization becomes less of a large-scale technical initiative and more of a sequence of informed decisions grounded in business context.
Conclusion
The main challenge in IT modernization is rarely the technology itself. It is the lack of clarity about the underlying domain structure. Domain-Driven Design provides a way to make this structure visible and to use it as a basis for decision-making.
Not as a methodological end in itself, but as a practical means to reduce complexity in existing systems and make modernization manageable.
Outlook
Once a clear domain understanding is established, it becomes possible to derive concrete next steps—from prioritizing specific areas to defining migration strategies and building a realistic roadmap.
This is what the next article will focus on.
