Share this post:
An increasing number of financial services customers with mainframe applications want and need to modernize. They face many issues related to the management, maintenance and deployment of mainframe applications.
Real-world modernization barriers
Most financial services customers are reluctant to modernize mission-critical applications because, well, they are mission critical. They run the business on them. These customers are concerned that if they open up the applications, they risk breaking them and causing a business outage.
One insurance company had patched its application for more than a decade to avoid the inevitable modernization. The programmers that originally built and now maintained it were the only ones in the company who understood it.
The managing director told me that the thought of one or more of these programmers leaving the company, or getting hit by a bus, kept her awake at night. She had no real option to address the issue.
If she does a rewrite, it will take too long and cost too much. Besides, the entire application doesn’t need to be rewritten. She can’t take the application out of production because it runs a significant part of the business. She can’t risk a “big bang” deployment of an updated monolith because it may have unintended consequences such as outages or jeopardizing her employment.
Many enterprises struggle with the question of whether to modernize established applications. So what can be done?
Three proven steps to successful cloud modernization
For many financial services clients and many like them in other industries, the following approach to incrementally and iteratively modernize heritage applications has led to success.
- Analyze the code. Identify the user interface components and understand how they interact with the rest of the application. You should understand how the business logic works in the application and how the application persists and accesses data and other applications. That means understanding interfaces, interactions and data needs in motion and at rest, cached or retrieved from a store.
- Map the components to the business goals and prioritize the modernization of each component to meet those objectives.
- Tackle the user interface (UI), separating it from the monolithic application and rewriting it in React or Angular.js and Node. Deploy the new UI components and the now-headless monolith to their own, separate containers.
This process enables new functionality right away. You can write a new UI component and the associated new, back-end function using a microservices architecture. Deploy the new microservice in its own container parallel to the monolith. Finally, you can incrementally and iteratively rewrite as much of the rest of the application as you choose. You can deploy components typically to containers that will run on the mainframe, on- or off-premises and to multiple cloud providers.
Automation dramatically accelerates the modernization process
Using automation tools to analyze the application, break down and categorize components, rank components by complexity, and prioritize and stage the component code modernization using the customer/IBM-developed criteria to meet business objectives reduces the initial delivery time from many months to weeks.
You can achieve a good deal of flexibility and modernization without ever freezing code or taking the application out of operations. Since you rewrite with microservices, you can deploy individually as often as you choose. You achieve flexibility in deployment targets by using containers. There’s no “big bang” and no bundles of changes to make in one large, risky deployment.
And the customer finally gets a good night’s sleep.
Source link https://www.ibm.com/blogs/cloud-computing/2018/09/19/microservices-apis-mainframe-applications/