The Need for Application Modernization

Numerous advantages come with application modernization, including the ability to innovate quickly, more productivity, better customer service, reduced technical debt, more secure systems, etc. Of course, there is also the chance to save money!

How much modernization you do will determine how many of these advantages you receive and to what extent. Modernized or not, the state is not a binary one. The higher you go on the sliding scale, the more you receive. But the more distance you travel, the longer it will take and the more money it will cost.

Estate-Wide Modernization

It always seems like a good idea to rewrite. It gives you the ability to start over and undo all of your previous mistakes, as well as the chance to get rid of the things that gave you headaches. It's simple to overlook that a significant portion of the complexity of your current applications is a result of requirements evolving over time, but that's rarely the case. Special guidelines and circumstances were initially disregarded or nonexistent. For each application, you will need to examine all of these if you rewrite them. This is no easy chore, especially with so many programs. And chances are that the code will behave strangely without providing any explanations. You'll also make mistakes, introduce new flaws, and encounter new difficulties. The same kinds of difficulties that initially caused the pain spots.

Replatforming is very useful, but it doesn't feel as new or thrilling. Importantly, it leaves open the possibility of future rewriting. It provides you with the majority of modernization's advantages right now and gives you time to choose which applications merit a complete redesign as microservices. Additionally, while those apps that have reached their "sell-by date" are retired, you can still maintain consistent operations throughout your entire estate. The great majority of apps will, in actuality, never be upgraded past re-platforming. They will never be rewritten; instead, something else will take their place.

Precise Estimations

How did Discover arrive at an appropriate evaluation of their possibilities after establishing all of this context? Modernizing to Spring Boot was already accepted, and each application was evaluated individually. A typical application's modernization with Spring Boot took months or even years to complete. Integration issues also included links to mainframe services and other issues.

Instead of modernizing on a per-application basis, the move from WebSphere Application Server to Liberty provided an opportunity to concentrate on the estate as a whole. The estate of applications' shared code and problems are also identified, which significantly reduces the effort required for modernization. Approaching the entire estate (as opposed to each application separately) typically results in a 70% effort reduction because challenges may be solved once rather than individually for each application. Discover wants to investigate and take advantage of this particular component to speed up its modernization process significantly.

Update Applications in a Matter of Days

The results of the Transformation Advisor assessment of updating the Discover applications to Liberty were highly encouraging. Every application's average modernization effort was calculated in days, not months or years. Because Liberty had the same or similar technologies as those used by the Discover applications, complete application rewrites were unnecessary.

Compared to the current WebSphere Application Servers, re-platforming to Liberty would give a lightweight, container-optimized runtime while lowering license and footprint requirements and leaving open the possibility of additional modernization. Discover would benefit from modernization to 80% while still having the option to pursue a fully cloud-native experience down the road for those critical applications where it made sense.