July 18, 2022 By Paul Barry
Elena Nanos
4 min read

Maximize your return on investment (ROI) by adopting an estate-wide application modernization strategy.

This is Part 1 in a series of blog posts on application modernization at Discover. Make sure you check out Part 2 and Part 3.

Application modernization comes with a host of benefits — the agility to drive innovation, increased productivity, improved customer experience, less technical debt, more secure applications, etc. And, of course, the opportunity to save money!

How many of these benefits you reap and to what degree depends on how much modernization you do. It’s not a binary state — modernized or not. It’s a sliding scale where the further you go, the more you get. However, the further you go, the more time it will take and the more it will cost. So there is a sweet spot — the classic 80:20 rule.

The 80:20 rule

What set of choices will give you 80% of the benefit for 20% of the cost? And, most importantly, how can you figure this out before you start modernizing?

Broadly speaking, you will be modernizing in three areas:

  • Operations: Moving from on-premises hardware and virtual machines (VMs) to containers running in cloud. 
  • Runtimes: Moving from general-purpose, heavyweight application servers hosting many applications, to lightweight, optimized application servers hosting a single application.
  • Architecture: Rewriting your applications to be cloud-native microservices.

Discover’s modernization journey

At Discover, the decision for operations modernization had already happened. Containers offered clear benefits and OpenShift had already been selected as the container orchestration platform.

The next decision point was which runtime to use. The options were to stay with the existing WebSphere Application Server (but running in containers) or move to a more lightweight runtime. Staying with WebSphere Application Server appeared attractive because no code changes would need to be made to the applications, but it was also not going to deliver as much benefit. There would be no opportunity to scale the licensing and hardware requirements to only what was needed, no rapid start-up offered by lightweight runtimes, no access to rapid inner-loop development techniques and no real chance to make it to 80% of the benefits. 

Lightweight runtimes

The preliminary decision was to adopt a lightweight runtime; preliminary because Discover needed to know how much this decision would cost and how much it would save them in the future. One obvious choice was the Liberty Runtime — the cloud-ready successor to WebSphere Application Server. The applications would need to be updated for this new runtime, impacting their configuration and (potentially) their code. This approach would provide most (but not all) of the benefits of modernization.

The other option was to completely rearchitect and go after as much of the benefit of modernization as possible. Discover selected Java SpringBoot for this approach.

So how is it possible to compare these two options? Selecting Liberty would replatform the existing applications, and selecting Spring Boot would mean rewriting them. In all, Discover had hundreds of applications to modernize, so selecting the right option for the whole estate was critical. Discover needed to assess the true effort involved for both options — replatform the whole estate or rewrite application by application.

Estate-wide modernization

Rewriting always feels like a great option. It offers the chance to wipe the slate clean of all the mistakes made the first time around and the opportunity get rid of those things that gave you a headache. But, that’s rarely the reality — it’s easy to forget that much of the complexity of your existing applications is a result of requirements changing over time. Special rules and special cases that were overlooked initially or didn’t exist. If you rewrite all of these, then you will need to review all of these, for each application. That’s no small task, especially for hundreds of applications. And odds are the code will do strange things and there will be no comments to tell you why. You will also miss things, introduce new defects and face new challenges. The same kind of challenges that introduced the pain points in the first place.  

Replatforming does not feel as shiny or exciting, but it’s extremely practical. Crucially, it does not close the door on rewriting in the future. It gets you most of the benefits of modernization right now and gives you time to decide which applications deserve the full microservice rewrite treatment. It also lets you keep consistent operations across your whole estate while those applications already past their “sell-by date” are retired. The reality is that the vast majority of applications will never be modernized past replatforming. They won’t ever be rewritten; instead, they will be replaced by something else. 

Accurate estimates

Having established all of this context, how did Discover get an accurate assessment of their options? Modernizing to Spring Boot was already approved, with the assessment for each application done on a case-by-case basis. The effort to modernize a typical application with Spring Boot was measured in months and years. Additionally, challenges existed with integrations, including connections to mainframe services.

The modernization from WebSphere Application Server to Liberty offered an opportunity to focus on the estate as a whole, rather than modernizing on a per-application basis. A tool called IBM Transformation Advisor provides an automated means of assessing the modernization development effort and challenges for each application. It further identifies common code and common issues across the estate of applications, allowing for significant effort reduction when modernizing. The typical effort reduction when tackling the whole estate (rather than each application in isolation) is around 70% — you can resolve each challenge once, as opposed to once per application. It was this aspect, in particular, that Discover wanted to explore and leverage to really accelerate their modernization effort.

Modernize applications in just days

The assessment of modernizing the Discover applications to Liberty IBM Transformation Advisor showed very promising results. The average modernization effort for each application was measured in days, not months and years. All of the technologies utilized by the Discover applications had the same or equivalent technologies on Liberty, which meant that full application rewrites were not required. Replatforming to Liberty would deliver a lightweight, container-optimized runtime while reducing licensing and footprint requirements, when compared to the existing WebSphere Application Servers, and did not close the door on further modernization. Discover would get 80% of the value of modernizing, while still allowing them to go after the full cloud-native experience in the future for those key applications where it made sense.

In Part 2 of this blog series, we look at the proof of technology Discover undertook to validate the assessment of Liberty as a modernization target: “Application Modernization at Discover with Transformation Advisor: The Proof of Concept

Learn more

More from Cloud

Data center consolidation: Strategy and best practices

7 min read - The modern pace of data creation is staggering. The average organization produces data constantly—perhaps even continuously—and soon it’s investing in servers to provide ample storage for that information. In time, and probably sooner than expected, the organization accrues more data and outgrows that server, so it invests in multiple servers. Or that company could tie into a data center, which is built to accommodate even larger warehouses of information. But the creation of new data never slows for long. And…

Hybrid cloud examples, applications and use cases

7 min read - To keep pace with the dynamic environment of digitally-driven business, organizations continue to embrace hybrid cloud, which combines and unifies public cloud, private cloud and on-premises infrastructure, while providing orchestration, management and application portability across all three. According to the IBM Transformation Index: State of Cloud, a 2022 survey commissioned by IBM and conducted by an independent research firm, more than 77% of business and IT professionals say they have adopted a hybrid cloud approach. By creating an agile, flexible and…

Tokens and login sessions in IBM Cloud

9 min read - IBM Cloud authentication and authorization relies on the industry-standard protocol OAuth 2.0. You can read more about OAuth 2.0 in RFC 6749—The OAuth 2.0 Authorization Framework. Like most adopters of OAuth 2.0, IBM has also extended some of OAuth 2.0 functionality to meet the requirements of IBM Cloud and its customers. Access and refresh tokens As specified in RFC 6749, applications are getting an access token to represent the identity that has been authenticated and its permissions. Additionally, in IBM…

How to move from IBM Cloud Functions to IBM Code Engine

5 min read - When migrating off IBM Cloud Functions, IBM Cloud Code Engine is one of the possible deployment targets. Code Engine offers apps, jobs and (recently function) that you can (or need) to pick from. In this post, we provide some discussion points and share tips and tricks on how to work with Code Engine functions. IBM Cloud Code Engine is a fully managed, serverless platform to (not only) run your containerized workloads. It has evolved a lot since March 2021, when…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters