Aplication focus : Banks Cashing in on

As financial organizations become more global, SOA offers a feasible way to make that happen. However, a change of mindset is required

Financial application software suppliers are exploiting new capabilities made available with Service-Oriented Architecture (SOA), aimed at lowering total cost of ownership, simplifying integration and customization, and enhancing performance. Financial institutions, steeped in legacy systems, are increasingly embracing SOA as a means to access and distribute information locked in those systems—and do it in real time, helping them become truly global organizations. SOA offers a way to organize the services they want and to build connections to the systems they already have. It used to be that financial institutions—namely banks—only had to worry about internal customers and how to keep them happy. They were able to do that reasonably well with their white rooms of computers. They knew where all their computers were. They had a limited set of applications, a limited set of users, and very limited and strictly monitored interfaces on the outside, if any. But the onset of Internet banking has broadened banks’ customer reach significantly. Today, banks have to be online 24x7 on a global basis or they lose customers. This creates myriad challenges as banks face regulatory and compliance requirements, the necessity for near-real-time, uninterrupted processing support with guaranteed response times, the problems of application overlap caused by mergers and acquisitions, and the need to maintain a complete, 360-degree view of each customer. At the same time, banks are experiencing increasing market competition and thus the need to reduce the cost of operations and IT. So, in an effort to retain customers, increase time to market, and better manage a multi-channel environment, financial institutions are viewing services as an approach to agility. Weighing the Benefits “Adopting SOA can provide definite benefits by allowing companies to rapidly build and deploy reusable business applications, release ’trapped ROI’ from legacy applications and mainframe resources, better integrate applications through BPEL (Business Process Execution Language) and workflows, and effectively allow financial services companies to offer new and innovative service models to clients,” explains Sharad Vajpayee, vice president of India-based 3i Infotech, a global information technology company with customers in the banking, insurance, manufacturing, contracting, retail and distribution, and government industries. Percy Barraclough, CTO of SunTec, a global technology company also based in India, concurs. SOA, he says, is a principle of good management, good design, maximum duplication, and maximum reutilization. “The basis,” he explains, “is an extension of object-oriented design within applications, bringing forward the concept of open integration across applications. This has significant relevance for financial institutions because of the diverse source of information and its relevance to charging and billing.” Financial institutions, in particular, need systems that are much more agile than the systems they’ve used in the past. “It’s much easier to use SOA to cope with the stream of continuing changing business needs,” notes Germany-based Jost Hopperman, research analyst and vice president of Forrester Research, Inc., with headquarters in Cambridge, Mass. Financial institutions rely heavily on legacy systems and cannot afford to discard them, nor do they want to. At the same time, however, they need to share the critical information and functionality embedded in those systems with other applications, including those of customers and partners, often in real time or near-real time and, increasingly, over the Internet. “SOA can be a great way to encapsulate legacy applications and distribute their functionality across the enterprise and beyond in a standard way,” says Michael Guttman, vice president and CTO of The Voyant Group, LLC, a Westchester, Pa.-based consulting company dealing with transitions to SOA, Business Process Management (BPM), and related technologies. “The trick is to do it in a way that meets all the necessary quality-of-service and security requirements, and without disrupting or overloading the legacy systems.” And, SunTec’s Barraclough adds, SOA is essential if financial firms are to address new challenges such as new services, new initiatives, innovative models for servicing the market, and increasing competition. There are many ways to service-enable legacy financial applications. An IMS-based application, for example, can be service-enabled through the use of a transaction integration tool. (See Fig. 1.) A CICS application can be service-enabled using an on-mainframe or off-mainframe approach. (See Fig. 2.) Another option is service-enablement through the terminal screen. (See. Fig. 3.) Embracing SOA Wells Fargo is one organization that is embracing SOA to address new challenges. In fact, the bank led the shift to SOA for financial institutions through its successful launch of Internet banking back in 1995. Today Wells Fargo is in its second generation of SOA technology. “It’s our primary way of doing distributed computing,” notes Eric Castain, chief architect for Internet services, based in San Francisco, Calif. “It’s our way of integrating the various accounting systems to give a customer-centric view of the relationship to Wells Fargo.” The goal of obtaining an integrated view of its relationships with customers is what drove Wells Fargo to SOA in the early 1990s when a customer service agent needed to interact with multiple computer systems to get an overall view of a customer’s relationship with Wells Fargo. “That integrated view in the 1990s became SOA of now,” Castain adds. The organization can now provide “anytime, anywhere information for the customer,” he continues. “It’s a consistent experience that offers the agility to react to business requirements.” (See Fig. 4.) “The key to successful SOA is understanding services,” says Mark Tiggas, chief architect for enterprise payment strategies in Wells Fargo’s technology information group in Minneapolis. “We believe very strongly in the number of tools that are emerging to help us integrate and leverage the power of services,” he adds. Some of those tools include Sun Microsystems’ JAX-B (Java Architecture for XML Binding) and JAX-WS (Web Services toolkit), open-source tools such as Apache SOAP, Microsoft Visual Studio for .NET development, and a number of tools to assist in managing and performance monitoring, such as those offered by AmberPoint. In addition, the major Web application and communication servers have introduced some level of Web services integration into their product lines as well. SOA is a standards approach, providing a business-centric view of development and business. Because Wells Fargo has multiple channels and multiple interactions, a business-centric view is vital. Before this, a customer would receive a different answer from a teller than from an ATM about his or her checking account balance, for example. “Because of what we’ve done [with SOA], the information is fresh everywhere,” Tiggas says. “You get the same answer.” SOA makes the information more real-time and more consistent. Cole Taylor Bank is another example of a financial institution embracing SOA. After more than 75 years of service to small and mid-sized businesses in the Chicago area, Cole Taylor Bank realized it had an inflexible data environment with un-optimized customer services. This resulted in management issues as well. Needing a distributed infrastructure to standardize, connect, and scale IT systems, Cole Taylor Bank turned to Sonic ESB. Using that product, the bank was able to simplify data management, automate account visibility, and expedite customer services. Sonic ESB helps Cole Taylor Bank deploy new applications and business processes faster, as well as to make portfolio changes directly via a website. In addition, the bank was able to cut time spent on exporting information from a data system into a spreadsheet from eight to 10 hours a month down to 45 minutes, according to a case study entitled “Cole Taylor Bank Deposits the Benefits of Service-Oriented Architecture.” As a result, the bank’s call center can answer customer inquiries quicker through a centralized view of customer accounts across service applications and servers. New Mindset Required While some banks are realizing the benefits of SOA, arriving at actual results is not a quick or easy process, and there are still many challenges to overcome. “In order to realize the full benefit and value of SOA, companies often need a systemic change in architecture and process, which is easy to underestimate,” notes 3i Infotech’s Vajpayee. Jerry Silva, research director for the Tower Group, agrees. “The biggest challenge most banks face in deploying SOA comes from the architecture’s inherent advantage of breaking down the walls between businesses in the organization, which, therefore, requires a new organizational model and governance policy,” Silva wrote in a September 2006 report entitled “The SOA Challenge: New People, New Models, New Ways of Thinking.” That is exactly the challenge most banks are facing. Wells Fargo had to overcome that problem as well. Successful use of SOA “takes a shift in the way you think about how to design systems focusing on business processes,” Castain explains. It’s an approach more focused on business functionality than technology, he adds. Wells Fargo has succeeded in changing its thought processes as an organization. “It’s so ingrained here now that we don’t think of it as anything other than what you normally do,” Castain says. He encourages other organizations to view it that way as well. His colleague Tiggas agrees: “It really is about defining the right services and moving forward with services as the center of your thought process.” Castain adds, “If you approach it from the business service point of view, then I think you’re much more likely to succeed and have an easier time of SOA. Partnering with business is the key step in that process.” The transition process to SOA involves four key maturity levels, according to The Voyant Group’s Guttman. Reaching the first level involves acquiring, installing, and becoming proficient in the infrastructure and tools necessary to design, develop, and deploy services. Reaching the second level is more challenging. It involves making SOA the predominant paradigm for all inter-application communication and distributed computing across the enterprise. “Unfortunately, without proper planning, pushing an organization too rapidly into level two can lead to a glut of one-off services,” Guttman notes. To avoid that, organizations should move quickly to level three, where the organization begins the shift from simply building new services on an ad hoc, as-needed basis to reusing and improving existing ones instead. “To get to that third level, you have to have an overall model and roadmap for your entire enterprise portfolio of services,” he explains. “This is the area that even most advanced SOA organizations are struggling with now,” he adds. A level-three roadmap is also essential for organizations that expect to eventually expose their services to outside parties. Those organizations will become increasingly interested in the fourth level of SOA maturity: industry standardization. Most organizations starting into level three, Guttman says, will probably prefer to follow international standards for modeling sets of services aimed at their particular industry—financial, telecom, etc. According to Guttman, few such standards exist for SOA yet, and this, he says, is a good indication of SOA’s current overall maturity level: “Most organizations are still at level one or two, while even the most mature organizations are struggling to get from level two to three.” Future Looking Bright Guttman notes: “It will be another few years at least before enough organizations are far enough into level three that they create a demand for level-four SOA standards.” At that point, he adds, SOA will really take off, as businesses rush to integrate their SOA services with those of their customers and partners. As SOA evolves, so will the way we view and pay for the services it provides. Forrester’s Hopperman believes that over time there will be a very strong change in planning approaches in application landscapes in general. “If you have to buy applications, hopefully you will only have to pay for the services you need,” he notes. “It will be about planning functionality at the services level instead of the application level.” Don Free, research director in banking for Gartner, headquartered in Stamford, Conn., agrees. Real service-oriented businesses are going to have to do some understanding of whom they’re serving, he says, adding, “As organizations become more service-oriented, we’re going to see this turn into more of a utility so they pay for levels of volume of usage versus the number of services they have.” Free anticipates that scenario is still five to 10 years in the future. But it is definitely coming. As he explains, “the rip-and-replace option is not a very feasible one in the banking environment.”