Business Impact: Before and After Microservice-Based APIs

DZone 's Guide to

Business Impact: Before and After Microservice-Based APIs

See the difference.

· Microservices Zone ·
Free Resource

Image title

IBM, UNISYS, HP, Digital, Siemens, Honeywell — Big global brands still depend on their legacy systems.
You may also like: The Role of APIs in a Microservices Architecture

Using data storage and access methods — like VSAM, IDMS, IMS, DB2, Oracle, and ADABAS — to store and rapidly access data through mission and business-critical applications are written in COBOL, Assembler, Fortran, ADS, RPG, and Natural, these business giants now find themselves unable to stay on the cutting edge in terms of speeding delivery of innovative digital channels and applications.

When you have legacy systems and must cater to customers and prospects that are heavily reliant on digital services delivered via mobile or Web, you need to find a way to close that gap between old technology and modern demands. The answer is microservices.

While the IT side of the organization cares about reducing the complexity of accessing and leveraging their systems, the business side may not care about how the technology works - they just want to be competitive, nimble, and build new or enhance revenue channels.

Modern microservices answers the needs of both sides – managing the abundance of legacy technology and digital-demanding consumers. Insurance and banking are significantly benefitting from this approach. Here’s the big “before and after” microservice-based APIs picture:

1 — Optimizing Agent Portal Efficiency


A major publicly-traded insurance company developed an “agent portal” that exposed business processes for its workers. The organization wanted to add more services to the portal, which was based on an IBM I application — meaning that adding more services took months at a time. In the meantime, the company’s competitors were gaining.


The company started using an API connector that automatically scans and parses green screens to take the output from their IBM i application and place it into the context of their portal. No COBOL modification or re-write was required, and the first new service was in place within hours. Their agents were able to rapidly understand the new interface and perform job responsibilities more productively.

2  — Enhancing Online Insurance Quote Comparison Services


Insurance aggregators have become critical for companies to get their price quotes in front of consumers. According to Price Waterhouse Cooper (PWC), 71% of insurance customers use digital research before buying a policy, and 68% of them were willing to download and use an application from their insurance provider. Unfortunately, one company found that its AS/400-powered application was unable to serve quotes to aggregation services. Even after six months of development, it still took up to three seconds to deliver quotes - long enough that most aggregator services still refused to accept their input.


This insurance company was able to use an API that defined web services on top of AS/400 transactions. This lets them extend the reach of their legacy systems into the cloud. They were rapidly able to serve quotes to browser-based applications in just 300 milliseconds and are now included in all major insurance aggregators.

3 — Improving Internal Staff Efficiencies


Although an insurance company was able to modernize most of its offerings, its auto insurance offering was left as a legacy application. Agents were forced to switch between a web browser and an antiquated “green screen,” which impacted productivity and responsiveness.


This insurance company was able to expose a service from its AS/400 claim management system, which presented all the reports related to a specific claim within the main auto insurance web applications. The initial proof-of-concept was completed in just five days. In production mode, insurance agents were able to realize time savings of up to 30%.

4 — Accelerating Bank Innovation By 50%


Despite wanting to be an innovative, “fintech-ready” bank, a major bank in Latin America was stifled by post-merger legacy systems spread across two countries and some of the highest operating costs of any bank in the region. Mainframe programming using COBOL was done in Colombia, Java programming in Panama and the infrastructure was maintained by a third-party global systems integrator. Excessive complexity delayed time-to-market (as long as six months or more) for new mainframe-based products and services, including a payment processing service for commercial clients.


The bank embarked on a “digital journey.” The first project included training, creation, and deployment of 12 new APIs in just 8-9 weeks by only four Java developers. The total time for deployment of the new payment processing service was 90 days, 50% faster than typical mainframe projects — an exceptional timeframe considering they bank also switched from IBM BlueMix to Amazon Lambda mid-way through the project. The service now runs 20-30% faster than those previously built without microservices, and a DevOps stress-test concluded that the bank far exceeded its goals by handling 60,000 concurrent requests.

5 — Creating Six Global APIs in Two Weeks


A top 10 global bank’s demand for digital, global services led to a backlog of 100+ foundational APIs necessary to build new applications and customer experiences. Nearly 200 developers have been working on the project for over a year. They used a popular product for API gateway and orchestration that did not specialize in legacy (core) applications running on AS/400 and mainframe platforms and could not generate APIs exposing RPG programs.

It could only manage and expose existing APIs. Hence, the bank’s developers had to write an additional AS/400 code in RPG to expose functionality, change existing code, invest in testing and regional certification and customization, which slowed things down even further. The bank also had to create a Global API: a unified API with the same end-user experience no matter the country, region, or underlying technical environment. This required the extraction of common logic and functionality that served as a single launch point for new products and services that can be built and consistently rolled out in a unified, global manner.


The bank partnered with API integration consultants who worked out an alternative architecture, making it possible to eliminate all the intermediate layers and the AS/400 channel logic. Now, the bank can directly expose the AS/400 transactions and move them to a Java application where the bank develops new applications and new logic. It can also run and orchestrate transactions outside its legacy environment, thanks to a new simplified product architecture with a minimal number of layers, and direct (straight-line) connectivity to the CBS transaction.


Ultimately, six key global APIs were created in just two weeks, and the new approach enabled the bank to accelerate “omnichannel” innovations for mobile, web, or cloud to serve customers wherever, and whenever they choose. Furthermore, simplicity and automation enabled APIs to achieve impressive 7X performance improvements.

Besides insurance and banking, many more industries are positively impacted by microservices. As established organizations all over the world face the growing digital economy and the growing influence of the millennials and their digital impatience, there has never been a better time to consider microservices and APIs.

Make sure the vendor and approach you use to lead you to IT efficiency, faster cycles, greater scalability, and competitive differentiation.

Further Reading

Microservices Architectures: Introduction to API Gateways

Rule Your Microservices With an API Gateway: Part I

API First — Microservices

apis, apis in enterprises, application migration, development platforms, legacy and modern, legacy application migration, microservice best practices, microservices, microservices development, modernization

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}