Incumbent banks that have made long-term commitments to legacy infrastructure are now deciding to build digital customer experiences or omnichannel support applications with the cloud. In addition to this, these financial institutions are also adding an
abstraction layer that can interact with applications through an API interface.
Why is this occurring? Given the complexity of some financial products that banks offer and the contractual obligations that are in place with core vendors, it often makes sense to bring modern functionality to existing core systems before modernising the
entire core itself.
Banks are utilising cloud so that their core systems can be opened up for modern application development. This technology is also ensuring that the data - that is typically stuck in the core system – is available for analytics.
Further to this, transaction data that exists in the core system can be streamed into the cloud for real-time analytics, artificial intelligence, and machine learning applications, helping tailor the customer experience or improve customer targeting. What
is derived from the analysis can then be communicated to customers in a targeted fashion and utilised for product engagement.
Finextra spoke to Akhilesh Tiwary, chief architect and data scientist at Tata Consultancy Services and Pranava Balakrishnan, head of software engineering - lending services at Credit Suisse about why legacy application modernisation is imperative to digital
transformation, the challenges traditional banks come across when operating with outdated systems and how the cloud can provide availability, scalability, agility, and resilience.
Why is legacy application modernisation imperative to the digital transformation of the financial services industry?
Decades old core applications have become ‘legacy’ due to their inability to run on modern IT infrastructure. Operating with outdated systems has resulted in numerous obstacles namely a lack of skills to maintain applications, high maintenance costs, inability
to adapt to changing customer needs, and error-prone business operations.
Further to this, legacy applications are unable to provide the required availability, scalability, agility, and resilience required by increased digital transformation. A product upgrade can also lead to an extended release cycle, increased costs and longer
time-to-market. This, in turn, results in poor customer experience and banks losing their competitive edge. This is why legacy application modernisation is imperative for success in the industry, but also essential for a quick transition to a cloud-ready application
landscape.
In Balakrishnan’s view, legacy application modernisation is imperative because “we want to start integrating systems across the ecosystem. Different capabilities that are being built with a modern tech stack [are associated with] modern business models that
we want to bring across from legacy application enablement. But trying to get the products to the market takes quite a bit of time, particularly around integration of other products, with other fintechs or creating ecosystems.”
Balakrishnan summarised that the digital transformation must occur from a customer centric and a business centric perspective. Alongside this, “in terms of the skill set and technology awareness that’s available in the market is mostly for traditional system
implementation. It’s very difficult to find the skills in the market as it becomes more and more niche, and we must continuously adapt in terms of transforming the overall platform.”
In answer to the question, Tiwary highlighted that there are several reasons. “One of these is that any changes you make to any application, the time it takes to market that application or product is very important. With legacy applications and being monolithic
in nature, release takes longer.
“When there is any change made to the legacy application, it goes through a series of tests and it should be quite easy but because the whole component is integrated, it takes a lot of time to deploy and ensure this feature reaches the end user. By the time
it reaches them, they are losing interest,” Tiwary added. This, in turn, leads to banks losing their competitive edge.
Tiwary continued to say that legacy application modernisation can provide scalability and can be cost effective. “Modern applications can meet the surging demand by spinning up the servers and can reduce the cost by spinning down the server when there is
no demand.”
How are delays in legacy application migration to the cloud or cloud-ready platforms preventing traditional banks from having a competitive advantage?
Migrating legacy applications to the cloud is not easy and is costly. Public cloud adoption, with its added security and compliance, can delay a quick move to cloud infrastructure for financial institutions. While some banks will wait and see what their
peers in the sector will do and then follow a similar path for their transition, further delays could compromise their early-mover advantage.
According to TCS, banks can choose from three approaches to migrate legacy applications to the container-as-a-service (CaaS) platform:
- Lift and shift: This approach is relatively fast and inexpensive and helps banks to rapidly containerise legacy applications without major code changes. It requires minimal configuration changes during migration. Additionally, the approach expedites the
decommission of old components and frameworks, infuses agility, and allows banks to auto-scale the application, using minimal resources to meet sudden spurts in demand. However, the application will still be monolithic in nature with a longer development lifecycle
and time-to-market.
- Improve and move: This approach helps banks revamp applications to make them cloud-compatible, integrate seamlessly with the target infrastructure environment, improve performance and customer experience, add more features, and reduce costs. Migrations
using this approach take longer than the lift and shift method as applications need to be refactored to enable integration with the infrastructure and consequently result in high costs as well.
- Rip and replace: This approach helps financial institutions completely redesign and rewrite applications to make them cloud-compatible and unlock all the benefits of a modern platform. Legacy applications are moved to a cloud native, CaaS platform using
a microservices framework. However, this approach is expensive in terms of both time and money compared with the lift and shift method.
Balakrishnan advised taking a step back before transforming legacy platforms and “slowly changing around it so that it can start interacting or integrating with other systems that have been built, which could be an exposure of an API, which works as a wrapper
around the traditional core system. Tackle it from the outside where you can start building those interfaces or interactions and then slowly come towards the core of the traditional implement, where you then change the heart of the system.”
Tiwary also offered his view and said that when migrating to cloud ready or container platforms, the first step is to “split legacy, monolithic applications into small, manageable microservices.” He continued to say that what will happen is the “testing
cycle will be reduced, the release lifecycle will be reduced, and changes can be made much earlier than with legacy applications and faster than competitors.
How can the CaaS approach underpinned with a microservices architecture help banks modernise legacy platforms?
Adopting a CaaS approach underpinned by a microservices architecture can help banks modernise legacy platforms and renew older applications to become cloud ready. Microservice architecture separates large, monolithic applications into smaller microservices,
which can lead to reduced release cycles.
CaaS platforms can be hosted on-premises and create a bridge between cloud and on-premises applications. Coupled with the DevOps approach to software development, this is a cost-effective way to help banks become agile and expedite their software delivery
cycle. Tiwary said that when ripping and replacing, large legacy applications, which consist of front, middle and end layers that are tightly coupled, are split into multiple components, multiple microservices.
“I can control the lifecycle of individual bots due to the container platform. After deployment, each pod can run when needed and can be scaled up or scaled down. If changes need to be made to microservices, I will only have to focus on that isolated component,”
Tiwary said.
Balakrishnan added: “This is the new tech stack that we should adopt with the microservices we are already enabling, which have the capability of having mutually exclusive services which can have a collective working on a particular business area or a business
function and with containers, also then approach to implement these microservices on the stack.
“It's easier to scale based on the service load or the capacity that they want in terms of servicing the customers and keeping them quite independent and fault tolerant across different geographies or even within the same demography as well. These capabilities
provide the business function almost 24/7 and also scale services and put in new functionalities to these services without disrupting or having any downtime for their channels to the customer,” Balakrishnan said.
What is the key consideration for the success of modernisation journey?
As a concluding point, Balakrishnan surmised that “from day one, we need to start analysing the platforms to see how we break them down into different microservices. It's very easy to break it down too granular and make them into thousands of microservices,
which then become difficult to manage.
“The key thing is to understand is the business process and the context, and then break them down into a manageable set of microservices to start with before even implementing or going ahead with making any code or infrastructure changes. That would be a
joint effort from the business and the technology team to go through the entire process.
“The second point would be to start scaling the team, because traditionally most of them come from a different approach of implementation. It would require rescaling and training of the team to understand how and why we are implementing certain changes into
the infrastructure or the way it has been approached. And then as a next step, you start building it around step by step.”