Customer Case Study: Synovus Financial Services

Service-oriented architecture delivers “big bank” solutions with community banking intimacy

Overview

Synovus Financial Systems has been developing and evolving their Service Oriented Architecture for over three years, competing in an industry that demands business agility. Like many financial services companies, Synovus has core business systems that include vendor packages, home-grown applications and service bureau-hosted solutions. Together, these systems are vital to the delivery of Synovus’ many financial products, but the architecture and platform of each are highly diverse. Compounding this complicated environment, the business mandate is to provide big-bank services while maintaining a community bank “touch and feel”. This demands a multitude of delivery channels to customers, including branch, ATM, call center, internet, and mobile banking.

Over the years, Synovus has been forced to write code to stitch together many lower level services. The effect is a tight coupling of services to the data sources, leading to a brittle architecture that forces multiple code changes when the inevitable data changes occur. What Synovus has concluded is that they were missing a critical component in their SOA architecture – a data services layer which compartmentalizes the data in all its complexities. Often called “data abstraction”, such a layer provides processes and applications a logical view of the data in a well-defined vocabulary, without the need to deal with complexities of distributed and diverse data sources and types. Synovus concluded they would formalize the data services layer to provide services to their process orchestration level. The data services layer would be required to provide a common customer view, data abstraction to contain and manage the complexity of the back end systems, and modern tooling to maximize productivity of the small development staff.

Solution

The solution was to provide common services that could be used by many Synovus groups to help build value in the company. A focus on loose coupling of components held the promise of reusability and interchangeability of their core information assets. Synovus set out to create a “Shared Application Services” layer, which is now becoming the backbone of new application functionality throughout the enterprise.

Best of Breed SOA Tools

Within the Shared Application Services layer, two complimentary components were used – an orchestration layer to handle process logic, and a data abstraction layer to manage the complexity of data sources within the company. For orchestration, Synovus selected a Business Process Execution Language environment by ActiveEndpoints. For a data abstraction layer, Synovus selected XAware.

Process Orchestration Using BPEL

In the new SOA environment, BPEL provides the capability to stitch together activities required to implement an application service. This includes calling data services implemented in the XAware engine, and web services provided by external core system providers.

Data Services Using XAware

XAware provides the data services layer for the application services orchestrated by BPEL. XAware creates a data abstraction layer based on an XML-based data model, which Synovus created based on the needs of the application services. XAware lets data service designers import the XML Schema and quickly translate between the physical data model represented in multiple back end systems, and the logical model defined by the XML Schema. In the process, XAware maps, transforms, and mediates multiple data sources into the single XML model. By implementing this data abstraction layer, Synovus shields processes and the application services layer from the complexity of the back end systems, while “future proofing” the enterprise as those sources evolve over time.

It is worthwhile repeating that Synovus initially approached the data services layer as a coding requirements. This is a natural approach, as an abstraction layer is not a necessity when an architecture is not “service oriented”. Many applications are written without a data abstraction layer. Indeed, modern development environments for Java and .Net make it very easy to bind an application directly to a physical data source. While functionality can often be quickly developed and delivered in this manner, the resulting application will be brittle, as any data layer change may break the application, and application changes may force data changes, potentially having a chain reaction effect to other systems. ROI studies have convincingly shown that using a data abstraction layer provides far less expensive systems in the long run.

Customer Profile Application Service

In early 2007, Synovus embarked on an aggressive project to provide a central application service for a new loan origination application. This service, called “Customer Profile”, needed to deliver a common view of the customer as seen from a number of systems within the Synovus IT environment, and would be invoked from virtually all new applications across the enterprise. The first new application to use the Customer Profile service is one of the company’s most important: Loan Origination. For the project, BPEL was used to orchestrate multiple services residing in the data layer and outside the enterprise, such as core system provider web services.

Project Execution

After attending a standard training course, the small Synovus development team went to work on the data services layer. The Customer Profile application service would need three data services for its operation: Get Customer Information, Get Customer Directory Information, and Get Application Key. The team created an XML Schema to represent the request and response message for each of those messages. The XML Schema represents the logical schema to be used by the application service. Then, XAware Designer was used to map the physical schema from internal data sources into the logical XML Schema. The result is web services that consume the request, read and/or update the internal data sources, and return the result, which conforms to the XML Schema. The services involve accessing multiple data sources within the enterprise, including SQL Server and the central LDAP protocol.

Production-Ready Implementation

As with any enterprise, Synovus has implemented strategies to assure near-100% uptime for their applicaitons. Error handling, recovery, fault tolerance, and load balancing were mandates for the data services layer. These requirements add a new dimension to what the data services layer must achieve in terms of shielding complexity from the process layer. XAware’s engine provided the needed features to load balance data source requests across multiple data centers, detect and recover from those errors that are recoverable, and report on errors that are not recoverable.

Enterprise-Quality Operational Support

While rapid development is important to Synovus, operational supportability is critical to the smooth operation of the enterprise. To that end, Synovus drew on the support features built into the XAware engine. SNMP lets Synovus monitor performance, set alerts and notifications, and in some cases, predict failures based on degrading system response times. Facilities are provided to remotely access diagnostic logs, and view information at the right level of detail for each task. Multiple views are provided: high level service execution view, component data set view, and detailed diagnostic view, letting an operations person gradually narrow down a problem to diagnose and correct the problem. The SNMP alerts feed the enterprise wide system management consoles, so that alerts are integrated into the standard operational support environment.

Summary

Synovus’s evolving SOA demanded a better way to handle the complex data that is the core of their information technology processing. Previous efforts required coding to combine low level services into higher level services consumable by the process orchestration level (BPEL). Synovus turned to XAware as a best-of-breed solution to provide data services and a data abstraction layer, hiding the complexity of the diverse data sources from the process layer, and eliminating the costly coding that accompanied previous efforts.

Contact details:

XAware Europe AG

T: +41416662914

F: +41416662771

info@xaware-europe.com

www.xaware-europe.com