Intellyx BrainBlog for vFunction by Jason Bloomberg
Use AI and Cloud-Native Principles for Selective Modernization
In the late 1990s, Java quickly proved invaluable for building applications that depended on n-tier architectures to deliver web sites at scale. The web wouldn’t be what it is today if it weren’t for the power of Java Enterprise Edition (Java EE).
Today, those massive object-oriented applications of the 1990s and 2000s are themselves legacy – and all those Java EE monstrosities have become today’s monoliths.
The irony in this situation should not be lost, especially for those of us who lived through the Web 1.0 days.
Object orientation promised all the benefits of modularity at scale – but now, complex interdependencies and questionable architectural decisions counteract any advantages that modular code might have promised.
Despite Java EE’s modularity and encapsulated business logic, its package-based deployment model remained monolithic. Today, Java EE apps have become an oxymoron – the antithesis of their original vision of modularity.
Are we stuck, then, with these creaking Java monoliths, nothing more than impenetrable spaghetti?
The good news: the answer is no. It’s possible to modernize legacy Java code in such a way that preserves what value remains while moving to a new paradigm of modularity based on microservices: cloud-native computing.
If it Ain’t Broke, Don’t Fix it
The first principle of legacy modernization, Java monolith or not: if it ain’t broke, don’t fix it.
Just because some code is old, runs on older infrastructure, or was written in an out-of-date language, doesn’t automatically mean that you should replace it.
Instead, the modernization team should take a close look at legacy assets in order to sort them into four categories: reuse, refactor, rewrite, or replace.
Business priorities should drive the decisions on how to sort various software objects. What value does the code provide today? What value does the business expect from its modernization? What is the cost of the modernization, and is a particular approach cost-effective?
Sometimes it makes the most sense to leave code in place (reuse). In other cases, transitioning from legacy to modern code without changing its functionality meets the business need (refactor).
In other cases, fixing existing code simply isn’t practical, in which case rewrite or replace is the best choice.
Read the entire BrainBlog here.
