Application Modernization is like Going to Therapy

Many of us have experienced going to therapy to examine our mental health, to improve our ability to handle life's complexities, and to communicate better with our friends and family and colleagues.

The problem is a lot of people will avoid therapy like the plague. The idea of examining our problems and making changes in our daily life to address them is daunting. We're comfortable. Why bother?

Application modernization in this day and age suffers from the same problem. We have legacy applications that were built over the last 25 years that have become too complex and costly to maintain. When development teams look at improving or modernizing these systems, the original missteps, often considered legitimate at the time, are now viewed as glaring mistakes.

For instance, using a single relational database for many applications is now considered poor architecture design. We've learned that separating data stores using bounded contexts or just modularizing functionality, provides a less complex set of applications, improves maintainability, and lowers maintenance costs.

In the 2000's, it was common to urge development teams to construct an enterprise domain model using object-oriented design practices. We'd start with base classes, implement shared functionality in abstract classes, override and inherit that functionality and so on. Eventually we had a pyramid of objects that represented the company and all of its functionality. All of our company applications then shared these structures either directly or through web services.

This was considered legitimate software architecture, and in many cases, it still is. The defining characteristic is level of complexity. If a system is simple, our past architectural decisions worked and still work.

But in middle to large enterprises with many interconnected legacy applications, this style of architecture has proven to be a barrier to change. The root object model is tightly coupled to itself and every application, rendering change nearly impossible. Any attempt to pull these types of architectures apart requires a level of introspection and investment that most companies aren't willing or capable of addressing.

To complete the analogy, Domain-Driven Design and Event Storming are the therapeutic processes to examine our legacy software, map its complexities, and improve our software architectures. Many companies have on the path of modernization for many years now, especially with cloud platforms providing technologies and services that could allow for better application architectures.

I've been working with companies using DDD and Event Storming for about nine years now and across the board they all accept the concepts. But the challenge is that like therapy, DDD and application modernization are long-term processes. Long-term change usually runs into short-term realities. Managers and staff have jobs and careers. They love the idea of modernization, but when deadlines approach, they will fall back on past successes. Modernization efforts will often slowly metastasize or simply die. Stakeholders will be forced to do triage. Accountability becomes just as complex as the applications themselves.

However, I don't think this is about the managers and the staff or the stakeholders. Modernizing complex legacy applications is one of the hardest, if not the hardest thing to accomplish. Just like therapy, it requires real work. It requires you to dig deep, to look closely at misconceptions and misunderstandings. To rebuild an understanding of what is true, what is needed, and how to build a roadmap to enable these changes.

Now ask me how it can be made easier, and I will go back to the analogy. You have to keep going back to therapy over and over until you have a breakthrough, which can sometimes take years. With Domain-Driven Design, you have to keep running Event Storming workshops and you have to keep going back to the white board and model your systems, define scenarios to test your models, build samples, execute your tests, identify gaps, and repeat continuously. There is no easy way out of the challenges of modernizing complex legacy applications.

You just have to keep doing the work.