Panacea

When greenfield teams start a software project, it's all fun and easy. The developers respond to new requirements at lightning speed, and the users are thrilled. Development proceeds in leaps and bounds. However, this picture changes over the lifetime of the system as the complexity of the software inevitably increases, making the system more prone to error, slowing progress and affecting maintainability.

When worst comes to worst, even the smallest change can take months to reach production. What was initially a flourishing green meadow has turned into a brownfield. "Legacy system," "old software," "big ball of mud," and "monolith" are the unflattering names teams use for these kinds of systems, but don't give up hope: You can bring flexibility, error resilience, and development speed back to aging systems. The core task is to control and break up the complexity.

Software systems suffer from different "diseases," and you need a variety of medicines to cure them. Four malaises in various permutations are observed in organizations and their legacy systems, whether monoliths or microservices.

Over time, a legacy system grows into a "big ball of mud," wherein unmanaged dependencies lead to everything being interrelated with everything else. Additionally, business cases become entangled in a large domain model whose parts don't genuinely fit together – or that even get in each other's way. In the third disease, the domain and technical source code intermingle. In such cases, replacing obsolete technology or expanding the business case have mutated into Herculean tasks. To make things worse, the stakeholders are bogged down in a team structure that does not lend itself to, or in fact prevents, fast progress.

Within the last 20 years, work with Domain-Driven Design (DDD) and legacy software has identified some cures for these diseases: refactoring, domain storytelling, event storming, team topologies, and the modularity maturity index (MMI). These cures can be combined in a kind of therapeutic plan referred to as Domain-Driven Transformation.

When addressing the treatment of a project, you should ensure that the development team has a positive outlook that in turn boosts motivation. The further the healing process progresses, the more satisfied the users, project leads, and managers, as the clumsy and expensive legacy software becomes more stable, adapts more quickly, and ultimately even opens up to innovative, forward-looking extensions.

The Choices

The first question is whether to replace the legacy system completely or keep it as a foundation and transform or refactor it. The replacement solution has two variants: a big bang or a step-by-step replacement. Big bang means building a completely new system on a greenfield site while the legacy system remains in use. At a certain point, you flip the switch from the legacy to the new system.

The gradual replacement of a legacy system allows you to develop a new system one slice at a time and use each slice in production at the earliest possible stage. At the same time, you disable the corresponding functionality in the legacy system. If you decide to walk down the reshaping road, you need to refactor the big ball of mud because it remains operational all the time.

To begin, you should look at the advantages and disadvantages of the different types of transformation so you can make the decisions that are right for you. Figure 1 visualizes the first replacement variant, the big bang.

Figure 1: The old system remains in service (arrows 1 and 2), but only until the new system is complete. At this point, you switch over in one fell swoop (arrow 3).

This strategy is known as the "big bang" because in the end you are in a whole new world. Unfortunately, the name also hits the mark because, inevitably, something is going to blow up in your face. What sounds good in theory (i.e., establishing the new system next to the old one) does not work in practice for various reasons. For example, a lot of unknown knowledge is hidden in the legacy system that often falls by the wayside during reconstruction. The legacy system often turns out to be so large that it cannot be rebuilt in a short period of time. Therefore, the legacy system cannot be "frozen," so it becomes a moving target during refactoring.

You can probably tell from these comments that we are not fans of a big bang rollout, and we are not the only ones who see the difficulties of replacing legacy systems in this way. The collective experience of the IT industry shows that the second approach – replacing the legacy system step-by-step with a new system that grows by increments (Figure 2) – works better than the big bang.

Figure 2: In a step-by-step replacement, you slowly replace individual components until the legacy system has completely disappeared.

In the process, you gradually cut out parts of the legacy system, revamp the design, and set the new parts up alongside the legacy software. After a short time, users are directly confronted with the new system and can work with it in production. As soon as the desired functionality is available in the new system, you can switch off the old one (arrow 4). Nearly two decades ago, Martin Fowler gave this approach the name "strangler fig application" [1]. He chose this name because the old system is entangled and eventually overcome by the new system, like a host tree is by a strangler fig.

This kind of modernization lends itself to the agile approach favored in IT, wherein you learn from iteration to iteration. You can continually evaluate and adjust the path forward according to the latest findings.

Organizations assume a great deal of intelligence resides in their legacy systems; understandably, they want to keep this know-how for the future. In this case, it's not a good idea to replace the legacy system. Instead, just continue to operate it, rebuilding it in increments through refactoring.

Strategic Transformation

To disassemble legacy software technically, you need to capture and think through the current work processes with all their workarounds. In other words, the key to success lies in (re)understanding the domain. It is not enough to look at the solution (i.e., the existing source code) alone. Instead, you have to start with the problem – the domain – to unravel and simplify a software system that has become entangled over the years through additions and changes. When doing so, you need to consider two things.

To begin, you mentally have to put aside the monolith and the structure that it contains and look at the basics of the business case or, more specifically, break down the domain into subdomains. Interestingly, at least from an analytics point of view, you start from scratch, even though you already have a system. From this fresh understanding of the domain, you can identify the redundant or misunderstood parts in the software solution and remove and rebuild them.

Therefore, for both the development of the new software system and the decomposition of the monolith, the critical activities do not simply consist of writing code but, first and foremost, include stakeholders learning from and understanding each other. Developers need to learn what exactly the business experts do in their daily work. On the other hand, the business experts need to understand the technical reasons for the constraints and prioritization in the solutions.

Strategic transformation can be described by four substeps that include rediscovering the domain, modeling the domain-oriented target architecture, comparing the architecture with the target architecture, and prioritizing and implementing the restructuring measures.

Sociotechnical Transformation

To transform a legacy system into something better, you need to consider more than just the technical and business dimensions of domain-driven transformation. It often makes sense to rethink team structures and procedures at the same time.

Fortunately, the agile approach is well established in many organizations. If this is not yet the case in your organization, you need to consider taking the plunge because agile transition and domain-driven transformation often go hand in hand. Moreover, organizational domain-driven transformation often means evolving horizontally organized teams (Figure 3) into vertically organized workgroups (Figure 4).

Figure 3: The way to dependencies: layers with horizontal teams.

Figure 4: The possibility of independence: layers with cross-functional teams.

In the following discussion, the term "refactoring" is used in a very broad sense. Alternative terms would be "reorganization" or "sociotechnical transformation." To give teams some idea of how the planned changes should proceed, you need to look at some types of sociotechnical refactoring that include the cross-layer refactoring [2] method, wherein an interdisciplinary team is establish from the members of the various specialist groups (user interface, business logic, database, etc.).

In partly layered refactoring [3], you establish a second interdisciplinary team from members of additional functional groups and the first cross-functional team. During second-team refactoring [4], you take a similar approach, the difference being that the existing interdisciplinary teams continue to work without interruption because none of their members need to join the new working group. At the same time, you can create several new interdisciplinary teams.