Evolving connectivity approaches in banking
Historically, banking enterprises were organized around corporate lines-of-business with each group having responsibility for executing the strategy for their specific function, such as loans and investment planning. As a result, each group also defined and managed the evolution of IT applications, such as loan and mortgage processing, credit card processing, and CASA (current account/savings account) solutions. The IT shared functions and operational management functions were deferred to the central IT function. As a result, cross-enterprise connectivity solutions evolved based on requirements for shared functions via messaging or gateway products. Often, these solutions were built as a reactive response versus a planned approach and, as a result, the solutions were often limited in flexibility and resilience. With the emergence of service-oriented design, these first generation integration solutions are being reconciled as part of enterprise SOA approaches.
During the last 3-5 years, SOA has emerged as a key architecture design approach for large banks around the world. Although SOA was initially used to support non-core banking functions, SOA is now emerging as a key strategy for transforming the enterprise transactional banking systems. Using this approach, banks are using service-based design to extend core banking with new functions, as well as integrating the back-end systems via channel-based solutions to enable a business services approach to banking IT modernization.
Connectivity approaches for core banking solutions
Banking clients design and implement SOA solutions differently depending on their core system implementation. Banks with existing mainframe implementations tend to adopt a bottom-up service implementation approach based on existing CICS® or IMS™ components. Services are exposed to provide access to the mainframe functions and are normally identified based on application analysis. This approach can be challenging as scalability issues need to be addressed due to increased potential loads from the new service consumers. Additionally, the service design needs to ensure the business applicability of the exposed services, and needs to be defined at the correct level of granularity. These two areas can be difficult to reconcile with pure bottom-up solution design. Following service exposure, ESBs (Enterprise Service Bus) or message broker technologies can provide service virtualization, mediation, routing and/or transformation between channel-based applications (such as Internet banking) and between existing enterprise applications. This subject of mediation is covered in detail in Part 1 of this article on exploring the Enterprise Service Bus.
On the other hand, banks that implement packaged core banking applications adopt a slightly different approach to SOA and connectivity. These clients normally base their service design on the inbound and outbound service/message interfaces provided with the application (such as the Finacle Integrator, Fidelity Xpress, and SAP’s Exchange Infrastructure). This approach can also be challenging as the exposed vendor services might not align with the actual solution requirements arising from business-driven design. In these cases, ESB solutions often provide transformation and mediation with the packaged applications and the banking applications (core and non-core) to resolve/mitigate the alignment issues.
With the emergence of SOA, banks often define and categorize services based on organizational domains, and this domain-based approach is also manifested in their ESB approach. As an example, it is common to see services taxonomies that align with account administration, loan origination, customer management and other key business areas. Connectivity topologies often map to lines of business as well (for example, loan management and contact center), and larger banks also tend to deploy ESB solutions based on regional proximity. As an example, we see an emerging trend with banks implementing infrastructures with centralized ESBs at bank headquarters, with regional ESBs that are collocated with the applications running in the regional data center or at the branch level (Figure 1).
Figure 1. Connectivity mapped to lines of business and regional proximity
For a longer discussion on connectivity infrastructure and federation, Greg Flurry’s article on federated connectivity in the enterprise is a great place to start.
ESB design trends
As mentioned earlier, banks with legacy SOA implementations adopt a reactive design approach, based on integrating existing ESB and messaging solutions. Banks that are just beginning to incorporate SOA into their enterprise IT strategy tend to be more proactive in their connectivity topologies incorporating ESB, service registry, and service management approaches as a foundation.
For example, one large bank is transitioning from a custom mainframe-based messaging solution that uses IBM® WebSphere® MQ as the core transport to a solution incorporating distributed commercial ESBs based on JMS. The target architecture will provide WebSphere MQ, plus offer SOAP/REST-based invocation of components exposed in the core banking solution layer. As part of their iterative deployment approach, the bank will dual-enable existing functions in the WebSphere MQ solution to the ESB instance over time.
Another common trend is the application of service gateway patterns to provide enhanced access security for service endpoints. We have seen this approach used to support mediation with mainframe functions, as shown in Figure 2.
Figure 2. Service gateway patterns for enhanced access security
This architectural approach enables on service invocation at multiple operational layers of the infrastructure; for example, providing routing and access gateway support to both distributed and mainframe services. For banks exposing services on the mainframe, the recommended target topology defines a centralized enterprise ESB instance collocated with the actual service endpoints, with an additional service gateway layer using IBM WebSphere DataPower® Appliances to offload security processing, XML validation and parsing, and service routing.
Mergers and acquisitions scenarios might result in federated connectivity implementations. One global bank is in the design phase of a solution to enable business services to be federated between two member organizations. In this example, the bank is planning to use an ESB in the distributed tier to support credit operations, and additionally will be exposing CICS-based retail bank services via an ESB instance collocated on the mainframe. The recommended design will provide interoperability between the credit and bank functions, while optimizing access to services resident on the mainframe. Figure 3 shows the benefit of this approach by providing virtualization and aggregation of services on the mainframe, versus having a single ESB instance on the distributed tier. The dual ESB approach minimizes data movement by providing service aggregation of requests close to the service endpoints, and additionally provides the ability to directly invoke mainframe-based services via the service gateway.
Figure 3. Benefits of virtualization and aggregation of services
As a general observation, we see SOA solutions in banking being coupled to the concept of service domains defined by the line of business. This approach maps to the business but requires strong design and run time governance, as mentioned earlier. As a result of the incumbent challenges, it is critical for clients to invest proactively in the planning and management of these approaches. Without a solid architecture foundation and a strong SOA governance model, these approaches can quickly turn into an unmanageable architecture, thereby defeating the benefits of implementing SOA.
This perspective has covered some of the key connectivity trends we are seeing in banks currently, and some key implementation recommendations based on engagements with financial institutions.
It should be noted that much of this work has been based on the best practices developed across IBM technical communities, with acknowledgement to Marc-Thomas Schmidt, Rachel Reinitz, Greg Flurry, Michael Ellis, and others. Additionally, the author acknowledges Greg Flurry for his critical and insightful review of this article.
- Exploring the Enterprise Service Bus, Part 1: Discover how an ESB can help you meet the requirements for your SOA solution
- Exploring the Enterprise Service Bus: Part 4: Federated connectivity in the enterprise
- Comment lines: Modernizing banking core systems
- Redpaper: Case Study: SOA Banking Business Pattern
- IBM developerWorks WebSphere
- IBM WebSphere Developer Technical Journal
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.