Source: cio.economictimes.indiatimes.com
I have often observed that a journey to cloud discussion for banks begin and end with Application modernization. Without a doubt, this is an important element of the journey. However, the IT landscape in a typical banking environment presents a unique setup that compels us to think about this pursuit differently.
There are two important considerations: one, the landscape is filled with Commercial-off-the-shelf (COTS) applications, which means banks are heavily dependent on System Integrators to modernize their applications to a cloud-native architecture. And number two, the lack of understanding and therefore the ensuing implementation of data privacy/security/regulatory and governance framework as the bank migrates to a cloud environment.
In a bank environment, the approach to modernization of application may vary based on the COTS attributes and the digital and business drivers for the organization. Many of the legacy applications may continue to have key technical limitations and therefore limit the migration process. Besides,
For some of the applications, the source code may be available and therefore changes required as part of cloud-native architecture are easier to carry out.
Some of the application vendors are already on the modernization pursuit and therefore the container images are available and have exposed APIs and Microservices.
There may be some home-grown applications: cloud migration is easier. However, more often than not, they are non-critical applications and therefore the benefits of running them natively on a cloud (on-prem or public) are somewhat muted.
So, how does one go about approaching application modernization? Keeping the central idea of decoupling identified functions from legacy, we will need to address the challenges of hardwired dependencies on data and application code. Here the proven patterns for incremental modernization can come in handy. The patterns are:
Decoupling Consumer Services from complex Systems of Record. Here the idea is to separate systems of engagement from the core and deploy them in the form of Microservices. This is a clean end-state one can aim for.
Staggered decoupling and modernization using Command Query Responsibility Segregation. Separating the UI layer from the back end data store and handling all the record translations and associated logic enables building services or adaptors for microservices.
In a Microservice mediated pattern, the underlying services are offered and accessed through APIs that are built on top of the core systems.
One can also do away with Microservice and access all services directly via APIs (such as Payment APIs).
Accessing data related functions – Data services, Cognitive Services, and Insights services – through a dedicated enterprise-wide data platform.
All these patterns mentioned above are important while defining the technical architecture of the journey. More often than not, the journey of modernization is a combination of these patterns, the suitability of which will emerge after the initial assessment of the application landscape.
A typical journey will comprise developing clarity around business, technology and infrastructure architectures quickly. To start with, it is important to have clarity on the business architecture: this will help define business services needed, along with the associated capability and process models. The definition of technology architecture can follow this exercise leveraging the patterns outlined earlier.
This is the step where we can define the needed microservices, APIs, automation, and integration needed to decouple the legacy into core and those integration functions that are needed to fulfil the business services.
Let us not forget the choice of Infrastructure platform: irrespective of whether the landscape is completely on-prem or cloud or combinations of multiple clouds, the necessary modernization will need to be carried out to convert the infrastructure into programmable entities. The target state may very well contain several existing components that are modernized and many commercially acquired components (or developed) as composable extensions to be integrated into servicing the business function.
DevOps and Security are two important functions that form part and parcel, not only during the ‘build’ part of this journey but also during the ‘run’ state. Interestingly, as far as processes are concerned, these are strong forte for banks. Because of the sensitivity to customer services and criticality of data, through years they have evolved the process of collaborative testing, automation, integration, and implementation of security processes. But with the advent of new tooling available for DevOps, automation, agile infrastructure, and integrated security management, it becomes important to leverage these new technologies in the context of their existing mature process framework.
A siloed and piecemeal approach to modernization will, at best, tackle the peripheral applications and therefore tend to have a sub-optimal impact. As part of scaling the adoption of cloud or modernizing legacy, banks will benefit from creating a blueprint and methodically get to the end state, realizing incremental business benefits along the way.
