Application Modernization: When Rewrite is Better than Refactor

Lori MacVittie Thumbnail
Lori MacVittie
Published September 08, 2020

One of the biggest impacts of digital transformation is the disruption to application development. Historically, the introduction of new architectures into app development generally takes several years before it kicks into high gear and sees mainstream adoption. The application architectures that tend to sweep entire industries ultimately become the de facto standard. We saw that take place in the mid to late 1990s when J2EE slowly but surely became the "enterprise standard" for developing three-tier web applications.

Today, the architecture that appears destined to "stick" and become the new standard is cloud native. These container-based, microservices architectures are rapidly moving to dominate new development projects in every industry. The successful growth of Kubernetes, upon which a significant number of such applications are deployed and operated, indicates that this latest app architecture is here to stay. Our research shows that at least half of organizations are exploring "new architectures" because of digital transformation. 

impact on app dev

Now, this is often interpreted to mean that organizations are on a 'modernization' journey. And we (the industry) tend to talk about modernization in very general (and loose) terms. As if organizations will simply wave a magic wand and all their applications will be built upon this new model. 

The reality is that organizations have many ways in which to modernize applications. Only some (37%) are pursuing a refactoring approach. Refactoring methods abound, with one of the most popular approaches being Red Green Refactor. But there are others, including preparatory refactoring and a selection of abstraction-based options to choose from. Most are based on simplifying code. In other words, they rely largely on a less disruptive form of rewriting the application.

But there are times when a complete rewrite is the best strategy to modernization. Generally, the effort to completely rewrite an existing legacy application can be substantial enough to put off even the most determined digital transformation advocate. But in some cases, it can net significant savings.

Consider the approach taken by a federal agency to modernize their application portfolio. Operating under a mandate to move to an Agile methodology, the agency needed special permission to develop applications in a traditional, waterfall manner. Now, waterfall was the dominant methodology when I was coding so yes, it's old. The agency decided the best place to start was understanding its own portfolio and rationalizing the need for each application.

During that audit, they found nearly 200 applications—out of about 6000—that performed the same basic asset management task. Imagine, for a moment, that there was a change required of that basic business function that required modifying all 200 applications.

That's a lot of developer and operator time and effort to develop, test, and deploy the same business function.

The agency decided to modernize by replacing all 200 applications with a single microservice that can now be used across the agency to track assets. Developed using Agile methodologies and operated in a modern environment, it can scale to serve the needs of every function that had been relying on its own personal, private application.

Not all modernization efforts are focused on refactoring. Strategically exploring what modernization means to the entire application portfolio can yield significant business advantages. Many organizations, especially those that have been operating for decades, are likely to run afoul of the same portfolio problem: duplication. Restructuring, acquisitions, mergers, and changes in management can lead to duplication of applications quite easily.

It would be a benefit to every organization to conduct an application audit and rationalization as part of a modernization strategy. You might find you have hundreds of applications, but only need some of them. This kind of strategy enables leaders to justify a completely new application, developed in a new architecture, to eliminate app redundancy and the costs that such a situation incurs.