Badly merged banks are often in danger of going off the rails when service channels continue to work independently. Can SOA keep them on track? Wendy Atkins investigates.
What does a badly merged bank IT system have in common with the Australian railway network? Quite a lot, according to some industry experts. Without a standardised way of providing products that work together seamlessly, a merged bank could end up with any number of individual service channels that work independently and do not take advantage of the synergies of a merged entity. Compare this with the way in which the Australian railway system is set up. Historically it has operated on three different gauges and relies on a time-consuming break of gauge so products can be transloaded.
So during the process of merger and acquisition (M&A), banks must consider how they can build uniformity. One approach could be forced migration, something that works best when a big bank acquires a small one. In this case, the acquired bank could migrate its bank deposit business to the acquiring bank’s system. “Alternatively, in a merger of equals, the banks may break off each core and look at the two banks’ solutions to see which has the better one for each line of business (LOB),” says Bart Narter, senior analyst at consultancy firm Celent.
Another approach is to adopt a service-oriented architecture (SOA), a method that has been gaining in popularity in the banking industry in recent years. “The main advantage of SOA is the flexibility it provides banks,” says Mr Narter. “If an acquiring bank has a SOA infrastructure, it is relatively painless to integrate the extra bank’s core payment and core lending systems, etc. Without SOA to put a simple face on an organisation, you need custom processing, which is time-consuming and costly.”
Alain Gendre, business process management/SOA programme manager at solution provider ILOG, says: “The real value of SOA is reuse: reuse of existing IT assets, and building business services that will be reusable, flexible and auditable. Already having a SOA strategy in place enables banks to reuse quickly – and at minimum cost – the IT assets from the banks they are buying, such as business processes, product catalogues, business services and business policies.”
Mr Gendre also believes SOA is a key element of an efficient IT M&A. He cites the case of a European bank that bought an insurance company: “Because SOA had not been established before the purchase, it took a long time and a lot of expense to realise the synergies of the two organisations and to realise the benefits of the M&A.”
Although SOA may be an increasingly popular approach to an M&A situation, banks still need to think carefully about its implementation. Ian Smith, executive consultant at system vendor CGI, explains: “When considering SOA in a merger environment, you need to think of Stare: scalability, time to market, agility, robustness and economy (see box).”
When to strike
Although SOA can bring advantages to banks in an M&A situation, opinion in the industry differs on when is the best time to move to it. “SOA is such a big and long-term project, you can’t start it before a specific M&A,” says Mr Narter. “However, the technology will work at any time to address the multiple architectures created following previous mergers and multiple overlapping business areas.”
Meanwhile, Mr Smith says: “In a post-acquisition phase you need to keep things simple – and this can be achieved with SOA. Some banks go some way down a SOA route before a merger with the hope that they will be in a better position to move to the post-acquisition phase.”
Technology can be applied to SOA in a number of ways. For example, some banks favour web-based services as a way of implementing it. Others use old-fashioned programming language with some service-enabling technologies such as XML to finish the job. “The main advantage of using web services-based SOA is that it allows legacy transactions, which are often very difficult to understand, to be easily accessed using self-describing data languages that are supported by all server environments,” says Andrew Price, director of product management at ACI Worldwide. “In an M&A environment, banks are able to utilise SOA and web-services to bring all parts of the business together and provide wide support across environments.
He also believes web-based services can address some common challenges. “Security compliance is a challenge throughout banking infrastructure. To address this, web services include a number of security-oriented standards and the entire process can be encrypted using SSL (Single Socket Layer). Auditability is also a challenge. To address this, web services have been widely deployed, and have all the messages tagged and use third party tools. Legacy transactions are typically complex and require specialised knowledge and training to understand and operate them. By moving to web-based SOA, you can get application developers who don’t need a great deal of detailed knowledge of systems – and you can take advantage of modern tools.”
Lessons learned
SOA is also being implemented in other business areas, and the banking industry can learn from some of them. “Generally, people think SOA isn’t suitable for high-performance, low-latency projects,” says Vijay Oddiraju, CEO at Volante. “Understandably, banks are worried they could lose the high-performance aspects of their architecture. However, they are learning from other business sectors that high performance can be achieved by implementing solutions in C++ to convert from a proprietary format to XML and vice versa. They can also improve their performance by choosing standards selectively and remembering that web services are not the only vehicle for implementing an SOA.”
Darshan Chandarana, financial service principal consultant at BEA Systems, says banks can learn from the step-by-step approach taken by other industries transforming their existing IT environment into a service-enabled infrastructure. “The most successful strategy employed in SOA implementations has been an incremental project-by-project approach. As services are developed for one project, they can be stored in a searchable, standards-based repository and reused in subsequent projects, leading to an increase in development speed and a decrease in costs.”
Going cross-border
When the merger or acquisition moves cross-border, the challenges for the bank can be even greater. Mr Chandarana says: “Cross-border M&As are likely to bring heightened levels of complexity in terms of seamlessly amalgamating differing national principles. In recent years, the growth of policy description standards in SOA has been, in part, a response to such challenges. The advent of these standards has meant that business policy variation can now be handled in a reliable, flexible manner. Variations in business data processing can now be dependent on a variety of dimensions, including origin, destination, content, regulatory considerations and so on.”
When merging cross-border and through different regulatory regimes, banks need to examine how they can tackle compliance with SOA. “SOA becomes harder across countries because you have to decide how you capture information – so you need the core systems to agree, for example, on what a customer is, and what information should be captured,” says Mr Narter. “One advantage of SOA is that it is easier to get a consistent view of customers. And because this works across channels, it could help with compliance with regulations such as Basel II, which requires banks to know the risks associated with their customers.”
While SOA helps to address many problems associated with merging two banks’ activities, there will still be challenges ahead. Mr Narter says: “You must have discipline. Banks don’t want to create multiple services that all do the same thing. There is limited reuse if a bank has a different service to perform the same function at each acquired bank. They need to build shared services that are usable by the acquired bank.”
Mr Gendre agrees. “The challenge is for IT to build reusable, flexible and auditable business services to achieve the benefits of adopting a SOA strategy. To do this, you have to examine how you can make sure the business service is not a liability in the future, how you can adapt to future legislation and how you can ensure the business service is auditable by business teams. What about the highly volatile business services changing very frequently and for which IT is a bottleneck?” he says.
Mr Smith goes further. “What is paramount is growth, retention and profitability. In an M&A context, it will not work unless you continue to give customers a good experience and ensure the service is relevant to them, regardless of whether they are high net worth individuals, businesses or students.
“Retention will be achieved if you give a good customer experience and business services that are more relevant from a customer point of view. If you implement a good SOA and good architecture, you can save a considerable amount of time. You must also be responsive. Finally, profitability is key. There’s plenty of evidence that a lot of functionality in a system is never used. Collectively, this adds up to a huge cost. Over time, SOA can cut out these underlying costs by streamlining the clutter of unused functionality.”
With the right technology – and the right advice – merged banks should be able to offer standardised products and channels that take full advantage of the synergies planned during merger negotiations. Like the railway system, this is best achieved by looking at the bigger picture – not by maintaining a tunnel vision.
WHAT IS STARE?
- scalability: When two entities have merged, volumes may suddenly go up and banks need to be able to cope with this.
- time to market (TTM): Can the organisation still get products to market quicker than its competitors?
- agility: How easy is it to respond to competitor and regulatory activity? For example, it may be that you are diversifying through acquisition, so you have to ensure that you can still sell through new regulatory regimes.
- robustness: When you fix something, you want to fix it everywhere that it is used in your system. With SOA, you can fix a problem once so you can continue to guarantee business transactions and data integrity.
- economy: The marginal cost of new applications should drop as the rate of reuse goes up. Banks implementing SOA need to ensure that the total cost of ownership goes down.
