Middleware in Banks

This article looks at the manner in which use of middleware in banks has evolved over the last few years. It also examines the critical role played by middleware in enabling a bank to remain competitive and provide personalised and user friendly services to their customers.

Definition of Middleware

So what is middleware? A simple answer is “The software which resides in the middle!”

Thus Middleware in a 3-tier implementation is the 2nd or middle tier – sitting between the client tier and database tier. Popular software products in this category include J2EE application servers like BEA WebLogic Server, IBM Websphere Application Server, Oracle Application Server etc.

In the case of integration, Middleware sits between multiple applications, providing the platform for these applications to communicate with each other. Microsoft Biztalk, Oracle Business Process Manager and TIBCO Rendezvous are some of the common middleware products used for this purpose.

Evolution Stage 1 – No Middleware in Banks

Fifteen years back very few banks in India had heard of Middleware, leave alone thought of implementing it. Most of the applications were standalone applications, typically client server and had a single interface for access. Adoption of Windows on the desktop changed the interface from character mode to graphical, but the siloed nature of the applications did not change. Any integration between the applications was batch mode and involved writing of batch jobs, scripts, file transfers using File Transfer Protocol (FTP) or floppies! 

This setup severely limited the bank’s ability to offer sophisticated services to their customers. Some examples of these limitations were:

·         Delay in propagation of Customer data to multiple applications: A name and address change in an application would normally take a day to be propagated to the other applications as most batch jobs were run at night, after office hours.

·         No single Window clearance: If the customer wanted to transfer money from his savings account to pay off his loan, it would typically take a day as the savings application and loan application could not talk to each other in real time.

·         Limited Channels of Access: The Branch was the only channel of access and the customer had to physically come to the branch to conduct any transaction – account balance inquiry or cash withdrawal.

Evolution Stage 2 – Use of Middleware starts for Point to Point Integration

In the mid to late nineties, banks starting implementing point-to-point integration using queuing technologies like MQ Series, Oracle Advanced Queues (AQ) etc. While this did bring down the delay in data propagation to multiple applications, Middleware was still regarded as a back office technology with no direct impact on the customer.

Also, IT administrators quickly realised that managing and maintaining the Point-to-Point integrations was very difficult. Reconciling data in the event of a break down of one of these point-to-point integrations was a nightmare.

Evolution Stage 3 – Use of Middleware becomes pervasive

Today most IT organisations in banks make extensive use of Middleware. Two factors made this happen:

1.      Adoption of Centralised or Core Banking: For Core Banking to be effective, it requires data to be consolidated and stored in a centralised manner. This resulted in fundamental changes in the banks operations:

Single Application for all Branches: All the branch users, which used to earlier access their branch specific applications now log on to a centralised core banking application.

Offering of New Customer friendly Services: Banks could now offer a vast array of customer friendly services including single window clearance, any branch banking, phone banking etc.

Need for Highly Scalable application: It increased the load on the IT infrastructure as all the branches and access channels are accessing the same application. Thus the number of users accessing a Savings Account application increases from <100 in a Total Branch Automation setup to >10,000 in a Core Banking scenario. As 2-tier client server architectures cannot support this large number of applications, most Core Banking applications are 3-tier with Middleware providing the Scalability and High Availability required to service this large number of users. The business logic resides on the middle tier and gives the bank flexibility to scale vertically (adding more processors on the same machines) and horizontally (add additional machines).

2.      Advent of ATM/IVR/Internet:  With liberalisation of the economy, the banks were under stress to increase productivity of their workforce. Common transactions like account balance inquiry, cash withdrawal, chequebook request etc. could be serviced more cost effectively through ATM or Interactive Voice Response (IVR), Call Centre instead of branches. As the number of access channels increased to browser, mobile devices, it became clear that point-to-point integration technologies would not suffice. This required adoption of Middleware to implement an Information Bus architecture to integrate these access channels with the back office applications. Middleware is increasingly being used in banks to provide a platform for integrating these multiple channels of access (ATM/IVR/Browser/Branch/Mobile Device) with the back office applications like core banking, loan management, cash management etc.

Future – Use of Middleware to implement Service Oriented Architecture

So what does Middleware have to do with Service Oriented Architecture (SOA)? In one word – everything!

Middleware provides the technology and building blocks needed to implement SOA. One of the key tenets of SOA is a closer alignment between business and IT. For this to happen, IT has to provide tools to business where in they can model, define and modify business processes.

Most Middleware vendors like IBM, Oracle and Microsoft offer process modeling tools, which can be used by business users to define these processes. In addition to the process modeling tools, Middleware provides the run time environment for these processes. For these processes to be functional, they need to interact in an agile and loosely coupled fashion with the back end applications.

Middleware provides the Enterprise Service Bus and standards based Adaptors for these processes to integrate with the back end applications like core banking, loan management, cash management etc. Middleware is also used to control access to who has access to which application – key requirements to enable a bank to meet its regulatory requirements as well as ensure data privacy for their customers to minimise the risk of fraud.

Conclusion

Banks will make increasing use of Middleware as they strive to become more competitive and offer sophisticated services to their customers.

———————————–

Dhruv Singhal

Director, Middleware Sales Consulting

Oracle India