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
Was this article helpful?
YesNo