Minimize risk (and maximize happiness) by choosing the right application for your Proof of Concept.
This is Part 2 in a series of blog posts on application modernization at Discover. Make sure you check out Part 1 and Part 3.
It’s very tempting to start your application modernization journey with your most important application, but the one that everyone cares about is not the right option. You need to use your estate-wide modernization assessment (see Part 1) to drive the choice of application for your Proof of Concept (PoC).
You want to start with an application that represents your whole estate, both in terms of code changes and in terms of configuration (connecting to common backend systems and databases). Configuration is typically as simple as counting the type and number external systems and interfaces that it connects to (these will be found during your initial assessment). It’s unlikely a single application will have every possible modernization issue and configuration, but the odds are there is one that will be pretty close, so that application will be the core of your PoC. Then, look at the remaining issues and configurations and add further applications if necessary.
The right applications for Discover
The Discover infrastructure included multiple different flavors of databases, gateways, messaging systems, distributed and mainframe platforms and applications — a typical enterprise infrastructure. The applications for the Proof of Concept (PoC) would need to connect to most of these.
Discover performed two Liberty PoCs and one related Messaging PoT, testing running IBM Messaging platform in the Cloud, co-located with Liberty on OCP, using Native HA Queue Manager (details here). They relied on IBM Transformation Advisor (TA) data to pick the right candidates for the PoCs.
Discover Enterprise Architecture (EA) chose two applications to migrate to Liberty. The first was a straightforward web application with no backend connectivity, and the second connected only to the Messaging platform. Transformation Advisor categorizes both of these applications as having moderate complexity.
In the second Liberty PoC, EA choose a single moderate application with 35 interfaces that connected to the most common interfaces and systems Discover currently uses with WebSphere applications.
By doing these PoCs, Discover tested every pattern in use, identifying all common issues and all common modules. The effort to perform ‘lift and remediate took only 3-10 days per application plus testing time.
The results of the Messaging PoT were very interesting. They not only proved that connection from the existing applications was achievable, but they also showed a 5x improvement in throughput for their messaging system co-located with their applications on OpenShift by using the auto-scaling capability.
Transparent Calculations with IBM Transformation Advisor
Discover needed to be sure that the applications selected for the PoCs were good candidates. Did they have sufficient issues that were present in other applications? To discover this (yes, pun intended!) they needed to see a breakdown of issues across all applications in the estate. That came courtesy of the Transparent Calculation feature of IBM Transformation Advisor.
Transformation Advisor provides a detailed UI that gives you a single-pane-of-glass view into all of your applications. However, modernization is one-size-fits-none, so all the data in Transformation Advisor can be exported (in CSV or PDF reports) so that you can review, search, analyze and manipulate the data any way you want.
Using these reports, Discover was able to see what modernization issues the PoC application had and which other applications had the same issues. The PoC application had enough issues to be a good candidate, and it included an ‘Unavailable API’ issue that appeared in over 90% of their applications. A scalable resolution for this issue was essential as part of the PoC.
Below is the output from Transformation Advisor showing potential issues migrating to Open Liberty for the second PoC EAR file and describing integration patterns in use:
Subplot: Managing risk
The Proof of Concept (PoC) is all about de-risking the modernization effort. IBM Transformation Advisor uses a simple system to help you manage this risk. Applications fall into one of three categories: simple, moderate or complex.
- Simple: These applications can be deployed to your modernized runtime without the need to get access to their source code. They may still require some configuration changes, such as setting passwords and other authorizations. These applications are very low risk.
- Moderate: These applications are expected to need code changes prior to deployment to your modernized runtime, but these code changes are well known. Transformation Advisor provides detailed guidance on how to resolve issues for these applications. They are low risk — the more bodies you throw at this work, the faster it gets done. Most applications will fall into this category.
- Complex: These applications use a type of technology that does not have a direct equivalent in your modernized runtime. These applications have a degree of risk until an alternative technology is selected and proven. This usually means your solution architects and technical leads are working together. To date, less than 1% of applications encountered by Transformation Advisor have been complex.
None of the Discover applications were complex, 95% of applications were moderate and 5% were simple. The PoCs Discover undertook gave them a clear picture on the suitability of Open Liberty, their chosen modernized runtime.
Estimated effort, actual effort and common resolutions
The IBM Transformation Advisor assessment of the second Proof of Concept application identified six modernization issues that potentially required code changes, and it estimated the effort for these changes at 16 days (see chart above). Part of this estimate included the effort to scale out one of these issues across many instances within the application.
Note: The Transformation Advisor estimation model assumes that the first time you fix an issue it will take the longest, and if TA detect thousands of instances of an issue, that you will develop a scalable solution. In short, TA assumes you are smart enough not to try to manually fix the same problem 10,000 times.
The actual implementation at Discover took 10 days. The difference was due to the fact that a scalable solution was quickly found for the ‘Unavailable API’ issue. This significantly reduced the overall effort for the PoC application. Better yet, this solution was not just scalable across the PoC application, it was scalable across all of the Discover applications.
The only efficient way to achieve mass modernization is via these common resolutions, otherwise you end up reinventing the wheel time and again. Discover created shared libraries where all common code and configuration files were placed to be reused with other Applications (there will be a lot more about this in the next blog).
Did it work?
So, did it work? Yes, it did! The Proof of Concept was a success.
The PoC applications were modernized from running on WebSphere Application Server on-premises to running on Open Liberty on the Discover OpenShift Cloud. TLS was used to secure connections from the PoC applications on cloud back to the original on-premises endpoints.
The PoCs proved that minimal code changes were necessary. Benefits of the modernization were immediately evident. The build/deployment cycle for applications they did ‘lift and remediate to OpenShift Container Platform were reduced to less than 10 minutes, and a fully integrated continuous delivery pipeline was created to support Day 2 operations.
In the next blog post in this series, we will look at how to take what was learned from the PoCs and use it to understand the potential Return on Investment for modernizing the entire application estate at Discover.
Learn more
Was this article helpful?
YesNo