Service-Oriented Architecture Pays Off for Synovus Financial

What does it take to achieve a successful, award-winning SOA implementation? Try asking Synovus Financial Corp., a provider of investment services, commercial and retail banking to 35 banks in the southeastern U.S. In late September, Synovus won a service-oriented architecture (SOA) case study competition sponsored by the SOA Consortium and CIO magazine. The competition highlighted business success stories and lessons learned for organizations pursuing SOA adoption.

Synovus’ Emerging Business Opportunities partnered with NACHA, the Electronic Payments Association, and eWise, a financial software provider, to create a consumer secure vault payment (SVP) platform for a new Automated Clearing House payment program. The project reduces consumer identity fraud risks; it also gives merchants guaranteed payment from a consumer’s financial institution at lower cost than credit card processing fees. By May 2008, Synovus had rolled out the SVP to 37 financial institutions. The project will continue until 2012.

A key technology challenge was to pass information securely between the various partners using only Internet technologies. Synovus had to avoid complexity and keep the solution affordable, since merchants and financial institutions had to adopt it quickly and integrate it with their own IT systems. Furthermore, Synovus could leverage the company’s existing SOA infrastructure.

The company credits its success to SOA’s reliance on industry standards, which enables adoption across disparate languages, operating systems and vendors. “This was critical to our approach because any proprietary implementation would fail,” wrote David Mize, Synovus director of architecture and development, in the winning project submission.

The SVP project impacts a very large domain. To be successful, it requires fast and committed adoption from merchants, billers, consumers and other supporting businesses, such as financial information processors and merchant hosting companies. Its payback is based on transaction revenue from sponsoring merchants and billers, as well as transaction fees from consumer payments and purchases, wrote Mize.

Synovus began with a high-level vision and plan. The participants identified the enterprise systems of record and critical business applications within each delivery channel.

The SVP application uses 19 Web services. Ten were reused from previous SOA implementations, one was acquired from Metavante for processing payments and three came from eWise for switch operations. That left only five Web services for the Synovus development team to build and test. Project organizers judged that the cost and effort, from a Synovus IT Web service standpoint, was 65 percent cheaper than a project from scratch. Each company involved has or is adopting a SOA infrastructure.

Each project participant agreed to build all integration interfaces (WSDL/XSD) using the interface-first approach to Web service development. Synovus could build the SVP website and Web services, integrate with vendor interfaces and perform much of the website unit testing before the vendors actually deliver their Web services. “This approach saved about two months off a five month project timeline,” said Mize.

The technical design phase began January 9, 2008. It completed its implementation phase and transacted its first production purchase from iGourmet on March 31, 2008. By May, Synovus had rolled out to all its 37 financial institutions. Due to configuration flexibility, said Mize, Synovus will sponsor seven new merchants to the SVP program.

Commonly, consulting firms encourage buying a vendor’s SOA solution as an implementation strategy. This approach creates a few timeline short cuts and reduces risks of the early projects, admitted Mize. “However, we decided to go in a different direction. Past experience shows that although the early projects are successful, the long term effect is reduced internal knowledge of development and architecture freedom of the system,” he explained. Plus, changes to early implementations are difficult when they are not developed internally.

Synovus has had plenty of technical and business wins. Prior to the SOA implementation, Mize explained, customer and account information, funds transfer, credit card balances and intraday bank balances and transactions were not possible outside the branch channel. “Now this data has been integrated into call center, Internet and mobile banking channels using services from the banking and credit card legacy systems,” he wrote.

The result is that the IT department could increase the business’ ability to bring new products to market. For instance, Internet banking was the first company-level SOA project. As a follow-on, Mize explained, the business deployed mobile banking with less than 500 hours of IT involvement because the Internet banking Web services were reused in the mobile channel. “IT was able to bring great project ROI and business agility to deploy new products like SVP to the end customer,” wrote Mize.

The company had plenty of “lessons learned,” which may help your company in its own SOA adoption. For example, to make a success of the business IT architecture, Mize recommends, it’s important to educate the business on design decisions that may compromise architectural principles. Leverage your business objectives to fund your SOA on a pay-as-you-go basis, he recommends; don’t overbuild or over-promise.

The education role doesn’t stop once the project is underway. “Continue to educate the business over and over again to ensure they fully understand the potential and the benefit,” writes Mize. Talk to the business in terms of ROI, cost reduction, product enhancements, and speed to market. Set up an SOA configuration control board that is made of up subject matter experts and can guide your other governance structures.

Do not underestimate the complexity of a distributed system, suggested Mize. “Start your SOA with a security standard for run-time security; do not let it evolve,” he wrote. “Your SOA environment is only as good as your most poorly performing service.” As a result, Mize recommends that companies adopting SOA put monitors in place to debug connection and data issues, such as real-time service statistics, network sniffers, and warehouse capabilities for service level agreement (SLA) management.

This was a huge project. In the process of creating its winning solution, the company learned—sometimes the hard way—how important governance is for reaching SOA project goals. They treated SOA as an architecture and philosophy, not a technology.

“You don’t have to get all of the things right on the first implementation,” wrote Mize. “But you do have to get your architecture correct.”