Advanced User

Case Studies

Azure Implementation of Legacy systems in Finance Industry

Problem Statement

Changes made to legacy systems could undermine what the legacy system was always good at. On the other hand, simply adding objects that express a distinct model without
changing the ones already there will lead to conflicting rules and concepts.
Cloud implementation types
1. Rehost “lift and shift”
2. Refactor
3. Rearchitect
4. Rebuild

Problem Solution

1.  Lift and shift
2. Migrate existing applications to Azure App Service or Azure Kubernetes Service (AKS). Refactored relational and nonrelational databases as Azure SQL Managed Instance, Azure Database for MySQL, Azure Database for PostgreSQL, and Azure Cosmos DB.
3. Rearchitected to implement multi-tier architecture for a monolithic app in claims domain
4. Rebuilt Channel Cost Analytics (Contact Center) using cloud-native technologies Azure Functions, AI, SQL Managed Instance, and Azure Cosmos DB.

First Step

Assessment Factor Index
1. Complexity and Risk
2. Architecture
3. Business Drivers
4. Technology
5. Deployment
6. Operations
7. Security


Multi -Tier Architecture


This ACL activity is asynchronous with any activity in either context, with a service level agreement (SLA) regarding the freshness of the translated data. Translation of data occurs here and


SQL queries to select the data they needed, and a post-query filter to get rid of some non-Credit/Debit EFT records the queries still pulled in on the complexity of the query . \ Data from these disparate query results and were formed together into JSON records using the uniform representation.
A claims record that originated elsewhere. Such a service would be attached to an anticorruption layer that would figure out how to insert it into the legacy database correctly.

FIX Protocol was implemented to reduce processing speed.

Banking Industry

CCA Channel Cost Analytics
o OFSAA Oracle Financial Services Analytical Application
o DQ Data Quality and lineage implementation
o M&P Maintenance and Production support
o FTP Fund Transfer Pricing


1. No. of Maintenance and Production tickets brought down to 100/month from an average of 200/month (50%) reduction in < 6 months.

2. Implementing Reg W compliance and BCC work to eliminate UDAs, MII and manual processing.

3. Implemented amortization models and mortgage officer selection criteria through SQL tuning.

• Implemented critical IT Work to support business (PnC, Life, FPNA, Bank) which in turn saved the COSAs over $100M in budget.

• Worked with business and Enterprise stakeholders to understand, validate, and help shape business strategy and vision, and customer needs.

• Worked with the Enterprise platform and/or multiple systems integrations for major elements of technical infrastructure.

• Worked EPIC/Feature-level efforts that coordinate distribution to, and release across multiple scrum teams, within SAFe scaled Agile organizations, as necessary.

Advanced user

Azure Cloud Technology

Banking client wanted to use Azure cloud implementation for claims processing in parallel to the legacy environment.

• Determine the impact of infrastructure scalability.

• Determine the reaction to failures in the existing architectural design of specific mainframe software.

The proposed solution would use a virtual application to process claims. Its purpose would be to monitor the performance and scalability of the infrastructure. The aim was to determine the impact of failures in the mainframe Electronic Funds Transfer (EFT) system workloads through this set of implementations. The proposed method was a smooth DevOps transition from on-premises to the cloud. The transition had to include the bank’s process and methodology, and it had to use existing tools. Using existing technologies would reduce the up-skill impact for the developers.

Tools used:

1. Azure Pipelines
2. Azure Kubernetes Services (AKS)
3. Azure Red Hat OpenShift
4. Azure SQL Database
5. Azure Event Hubs – (Kafka)
6. Azure Monitor
7. Azure Container Registry
8. Azure Container Instances (ACI)
9. Azure Cache for Redis
10. Third-party
11. Bank proprietary software and backend services
12. Docker

Technical Solution

Important feature of Azure Red Hat OpenShift 3.11, implemented the use of Azure Kubernetes Service for testing node autoscaling scenarios.

There were several design constraints that the Dev team had to consider:

  • Because of internal requirements, bank requested the use of the following technologies:
  • OpenShift 3.11 as the container orchestration platform.
  • Java and Spring Boot for microservice development.
  • Kafka as the event streaming platform with Confluent Schema Registry feature.
  • The solution had to be cloud agnostic.
  • DevOps and monitoring tools had to be the same ones that the bank already used in their on-premises development environment.
  • The solution could not share the source code that the bank put in the on-premises environment to external environments bank policy only allows moving container images from on-premises to Azure.
  • Bank policy restricts the ability for a constant integration (CI) pipeline to work between both on-premises environments and any cloud.
  • Dev team manually deployed all source code hosted in the on-premises environment, as container images, to Azure Container Registry.
  • The claims processing scenarios for tests had to use a subset of mainframe EFT workloads as a flow reference.