Once a bank defines its business drivers for SOA, the next step is to determine which services to integrate in the new architecture, according to a TowerGroup report.
Prior to an SOA implementation, services are tightly coupled within a particular process -- banks are unable to decouple the process, and the services held within each process need to be rebuilt to get the same services in another channel. SOA, however, allows banks to decouple services and make them modular so they can be reused across channels. The number of connections among various systems should be seen as an indication of the success of its reusable components, experts say.
Banks should look for the low-hanging fruit first, says Greg Haslip, managing director for banking in the U.S. for Redmond, Wash.-based Microsoft. Look for the systems in place 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 the bank's 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 -- it's almost a transformation of a bunch of verticals into horizontal planes."
According to U.K. IT research provider The Butler Group (East Yorkshire), services should be described in a manner that is standardized across the organization. This will ensure that terms maintain the same exact meaning and 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 -- 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.
Choosing the wrong technology, Haslip adds, can doom an SOA initiative. Some mistakes that banks make are 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. "Technology itself is not a silver bullet," he says. "You still have legacy and you're going to have to work with that."