Wall Street & Technology is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Trading Technology

05:15 PM
Nancy Feig
Nancy Feig
News
Connect Directly
RSS
E-Mail
50%
50%

A New Foundation: SOA Implementation for Business Transformation

Implementing a successful service-oriented architecture starts with making the right decisions early in the process.

It wasn't just small changes that Wachovia's Corporate and Investment Banking (CIB) division was eyeing when it first looked to deploy a service-oriented architecture (SOA). Rather, it was a total transformation resulting from a mandate from the division's head to create a business-aligned IT group, according to Tony Bishop, SVP and director of product management for the CIB technology group.

Charged with differentiating the bank and growing its business in the face of larger-scale competitors, Wachovia's CIB division had to map out where its technology needed to be to match where it wanted the business to go, relates Bishop. Under the leadership of Susan Certoma, who stepped into the role of CIO for the CIB division in 2004 after a tenure at Goldman Sachs, Bishop was about to embark on a three-year transformation of the business enabled by SOA.

Like Wachovia, with similar goals of improving operational efficiency and growing the business, financial services providers worldwide are turning to SOA. According to recent research from TowerGroup, half of the top 20 banks in the United States already are implementing SOA strategies.

As Wachovia and other banks are discovering, leveraging SOA's loosely coupled services to overcome siloed technology has the potential to completely change a financial institution. Yet the road to a full SOA implementation is marred with potholes and roadblocks, and according to experts, it's important for financial institutions to be aware of the key decisions they face about services, technology and governance.

Approaching SOA with clear business goals and realistic expectations may be the most important step a bank can take, Wachovia's Bishop says. Although Certoma set the ultimate goal for the bank's SOA transformation as business differentiation, she also outlined more-specific subsets of the project, including decreased time to market and cost of delivery for new products, Bishop points out.

"When you think of the CIB business focusing on institutional clients, you are focused on either creating liquidity, transferring risk or providing advice," Bishop relates. He says Wachovia was looking for "the technology that allows you to build and make the right decisions, and do it in the most automated and cost-efficient way possible."

Though the plan was to transform the entire CIB organization using SOA, the project was divided into easy-to-swallow pieces. "Funding and support was built on trust and incremental deliverables," Bishop recalls. "It was, 'Here is the plan -- each year we are going to deliver increments. If we do, then you will fund the next piece.'"

Selecting Services

Once a bank defines its business drivers for SOA, the next step is to determine which services to integrate in the new architecture. Prior to an SOA implementation, services held within each process need to be rebuilt to get the same services in another channel. SOA, however, allows banks to decouple services so they can be reused across applications and channels.

Banks should look for the low-hanging fruit first, says Greg Haslip, managing director for banking in the U.S. for Microsoft. Start with the systems that will enable the SOA strategy and the most process reuse, he suggests, noting that services such as money transfer, account opening and account history are commonly utilized in SOA projects at banks.

Wachovia's CIB unit first integrated its front-end services to create a common interface for sales, trading and banking, according to Bishop. Then project leaders examined the services the bank needed for trade execution, positions, offerings and connectivity to markets, he adds. "Traditionally, everything was built in silos," Bishop says. "Instead of silos, I'm creating horizontal functions and horizontal services."

According to U.K. IT research provider The Butler Group (East Yorkshire), services should be described in a standardized manner across the organization. This will ensure that when services are reused they will achieve their expected purposes.

The Technology Component

Of course, no SOA project would be successful without the right technology. According to Microsoft's Haslip, the technology a bank chooses -- including Web services, middleware, frameworks and platforms -- has to meet a few basic requirements of all SOA-enabling technology. It has to have open standards, enable rapid deployment, be agile, be easy to use for developers and end users, and be capable of being deployed in an end-to-end manner with an integrated suite of capabilities, he says. Some mistakes that banks make, Haslip adds, include choosing technology without a business need, setting the wrong expectations for technology, focusing too much on the reuse and build capabilities of the SOA software and not enough on the user experience, and focusing too much on Web services.

And what about the ever-present question: To build or to buy? "You build it if you have to, not because it's fun," says Bill Conroy, enterprise architecture senior business executive for Bank of America. According to Conroy, Bank of America has a well-defined set of rules for its SOA-enabling technology. "Partnership, purchase, then build if you have to," he says. As a rule of thumb, anything that's commoditized, the bank will buy; but if the technology is differentiating, intellectual property or of strategic value, then the bank is more prone to build, Conroy notes.

For its SOA project, Wachovia required that all its technology be componentized and capable of being extracted, the bank's Bishop says. Wachovia didn't want any technology built to a specific language or a specific format. "This is where a lot of SOA strategies fall short," Bishop asserts. "A lot of people in the past would build business logic and need to inherit that it was running on a Java container. We didn't want that. We wanted to reuse so that it could be moved about in different ways."

According to Bishop, he bought a lot of best-of-breed technologies that are open standards-based and pluggable. "On the client side, we just leveraged the .NET framework from Microsoft, so that was really more of a leverage of the development tools," he says. On the server side, Wachovia's CIB division leveraged open source from JBoss (Raleigh, N.C.) and grid server and fabric server from DataSynapse. It also used Tibco messaging, IBM data power and data caching technologies from Tangosol (Somerville, Mass.) on the data side. "We married those into hardened versions -- almost like solutions stacks -- so that the application developers don't have to think about how they combine them all," Bishop says.

Previous
1 of 2
Next
Register for Wall Street & Technology Newsletters
Video
Exclusive: Inside the GETCO Execution Services Trading Floor
Exclusive: Inside the GETCO Execution Services Trading Floor
Advanced Trading takes you on an exclusive tour of the New York trading floor of GETCO Execution Services, the solutions arm of GETCO.