Comment lines by Scott Simmons: Evolving approaches for connectivity and core banking systems

We are witnessing a transition in core banking implementations as banks move from a tightly-coupled line-of-business application architecture toward adopting an SOA-based approach to solution implementation. Additionally, these changes in solution design are being reconciled with an evolution from an integration-centric approach based on traditional messaging technologies to a more open service-based architecture based on Enterprise Service Bus (ESB) patterns. This article illustrates some of the ways that banks are implementing connectivity in this evolution, and describes some of the key patterns that are emerging to support coexistence between current and next generation banking solutions. This content is part of the IBM WebSphere Developer Technical Journal.


Scott Simmons, Executive IT Architect, IBM  

Scott SimmonsScott Simmons is the Lead Banking Solutions Architect for IBM's Worldwide Banking Center of Excellence. Prior to his work with the Banking Center of Excellence, Scott was the Lead Architect for the Worldwide SOA Technical Architecture team and was the technical leader for over 50 IBM SOA Architects around the world. Scott is both an IBM Certified Senior IT Architect as well as a Master IT Architect with the Open Group. Scott specializes in design, development and implementation of SOA architectures for customers and partners and is also a Certified SOA Solution Designer. Scott has been published in numerous periodicals including WebSphere Developer Technical Journal, Web Services Journal and WebSphere Journal. Scott was formerly the Previous to working for IBM, Scott was the lead architect for the Chief Technology Office at Peregrine/Extricity as Director of Technology Solutions. Scott has extensive experience in integration and messaging architecture as well as data architecture design/deployment through employment with Vitria, Illustra/Informix, and Sybase.

developerWorks Contributing author

22 July 2009

Also available in Chinese

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
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
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
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.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Comment lines by Scott Simmons: Evolving approaches for connectivity and core banking systems