In the previous articles, I explored different aspects of modern IT modernization. The starting point was the observation that many systems do not fail because of technology, but because of a lack of clarity about their underlying domain structure. Domain-Driven Design provides the foundation to understand systems and to define meaningful boundaries.
Building on this, I showed how this understanding leads to concrete decisions—from prioritizing domains to defining migration strategies and creating a realistic roadmap. Approaches such as Golden Master Testing and the Strangler Fig Pattern play a key role in implementing these changes in a controlled way while managing risk.
This perspective is intentionally holistic. IT modernization is not a single architectural concern, but a combination of structure, decision-making, implementation, and quality assurance.
What is often overlooked is that this combination does not stop at the system level. It directly affects the organization that builds and operates these systems.
This is where it becomes clear that IT modernization is more than a technical initiative.
Systems and organizations are tightly coupled
A central aspect that is often underestimated in modernization efforts is the close relationship between system structure and organizational structure.
Systems do not emerge in isolation. They reflect how teams collaborate, how decisions are made, and how responsibilities are distributed.
This observation is commonly described as Conway’s Law: systems tend to mirror the communication structures of the organizations that build them.
In practice, this means:
Fragmented organizations produce fragmented systems.
Unclear responsibilities lead to unclear system boundaries.
Local optimization results in global complexity.
If these underlying structures remain unchanged, they will reappear in any new system that is built.
Why technical modernization alone is not enough
Many modernization initiatives focus heavily on architecture and technology. New platforms are introduced, services are restructured, and target architectures are defined.
At the same time, the underlying ways of working often remain unchanged. Teams continue to operate along historical boundaries, responsibilities remain unclear, and decisions are still made in a fragmented way.
The result is predictable.
The new architecture is shaped by the existing organization. Boundaries blur, dependencies re-emerge, and complexity returns.
Modernization becomes a technical project with organizational side effects, rather than a true transformation.
Domain-Driven Design as an organizational structure
In this context, Domain-Driven Design is more than an approach to system modeling. It provides a structure that can be directly reflected in the organization.
Domains are not just technical units. They represent areas of business responsibility. They define where decisions are made, where knowledge resides, and where change happens.
When a system is structured around domains, the organizational implications become unavoidable.
Who owns a domain?
How are decisions made within it?
How are dependencies between domains managed?
DDD makes these questions explicit—and requires them to be answered.
Agile transformation beyond processes
A similar dynamic can be observed with agility. In many organizations, agile transformation is primarily understood as the introduction of processes, roles, and ceremonies. Scrum events are established, boards are created, and terminology is adopted.
However, the essence of agility lies elsewhere.
Agility is about making decisions where the relevant knowledge exists. It is about incorporating feedback quickly, taking responsibility, and working effectively under uncertainty.
In this sense, agility is not a process.
It is an organizational principle.
Connecting structure and ways of working
The connection between Domain-Driven Design and agility becomes particularly clear when both are considered together.
DDD defines meaningful boundaries and areas of responsibility.
Agility describes how work and decision-making happen within those boundaries.
Only this combination creates a consistent system:
Teams are aligned with business domains.
Responsibility is clearly assigned.
Decisions are made where the relevant knowledge exists.
Dependencies are managed deliberately rather than emerging by accident.
Modernization thus becomes not only technically feasible, but also organizationally coherent.
Common anti-patterns in practice
In many organizations, recurring patterns can be observed that work against this logic.
Feature teams operate across multiple domains without developing deep understanding. Architectural decisions are made centrally, while implementation is distributed. Teams optimize locally without considering the impact on the overall system.
These structures inevitably lead to systems that are difficult to understand, hard to change, and tightly coupled.
Implications for IT modernization
If systems and organizations are so closely connected, a clear conclusion follows:
IT modernization cannot be treated as an isolated technical effort.
Every change in system structure has implications for the organization—and vice versa.
This does not mean that organizations need to be rebuilt from scratch. However, it does mean that structural questions must be addressed deliberately:
- How are teams organized?
- Where does responsibility lie?
- How are decisions made?
Without answering these questions, modernization remains incomplete.
Conclusion
IT modernization is more than an architectural challenge. It is always, to some extent, a process of organizational change.
Domain-Driven Design and agile principles together provide a way to connect these two dimensions.
DDD establishes the structural foundation.
Agility defines how work is carried out within that structure.
Only when both aspects are considered together does an environment emerge in which sustainable change becomes possible.
Modernization then is not only about changing systems.
It is about changing how decisions are made and how responsibility is taken.
