Applications can now be built from components that can be recycled and reused. Dan Barnes reports on how banks are reducing the need to design systems from scratch.

It seems that every three letter abbreviation – or TLA – heralds the next big thing (or NBT) in information communications technology (or ICT). The latest push from technology providers’ marketing departments is service-oriented architecture (SOA).

The idea is to provide an architecture that can link data from disparate sources to applications. These are built from components that can be reused to create new applications, which are delivered as services for the business user, changing the IT provision model.

Many of the concepts involved have been around a while – developing, as this idea has, through object-oriented technologies to component-based programming and finally to the provision of services rather than applications.

Chris Swan, data architect at Credit Suisse First Boston (CSFB),explains that the earlier technologies had ‘fine grained’ components and were technology focused. “Service-oriented architecture is coarser grained and focused on a business service.” John Cady, chief architect, infrastructure solutions at Perot Systems, explains this difference with the example of an inventory. This could be both a single service and application, unlike an order entry system that has multiple activities involved within it and can, therefore, be built from several services where it would previously have been built as an all-in-one application.

Thanks to the development and increased understanding of particular technologies – XML and web services being cases in point – finance houses are now able to create services that can be re-used to create systems for a number of purposes without having to build them from scratch. By adding metadata tags to data, effectively ‘wrapping’ it in XML, it can be moved between these systems without them being concerned about the data’s point of origin.

Mr Cady says: “There has been an almost tectonic shift in that, pre-XML, it was very difficult to get peoples’ systems to interoperate.”

Understanding the upside

So what does this mean for the business? Tony O’Donnell, financial services director at BEA Systems, says as long as a bank does not allow development to happen in patches, there could be the potential for big savings in time and expense, which, with an average of 80% of IT cost going on maintenance, will be a welcome relief.

Phil Head, business development manager at BEA Systems, concurs that a ‘toe in the water’ approach is only going to recreate the situation that banks are trying to avoid. “If you are regression testing a service each time it is incorporated in a new system because you are testing the systems and not the services, you are duplicating the work. You could test the service as a whole, knowing that it exists in a number of systems,” he says.

The dedication to such a project can require enforcement of the strategy – one anecdote cites a bank that rewards developers for reusing components and, similarly, takes disciplinary procedures against those who duplicate work. Given the savings and benefits involved, this attitude is understandable. Stefan Van Overtveldt, vice-president, ICT Propositions at BT, notes that one bank that emerged from a major merger made the provision of service interfaces across all of its core applications an integral part of the merger, facilitating the operation.

At CSFB, the move toward a service-oriented architecture, driven by the research and development department, is notable in that it is looking two years ahead with its strategic vision. One purpose for the ‘service-oriented computing’ strategy being implemented is cost transparency of IT spend, allowing the business functions to determine the level of service they receive for expenditure. To achieve this, information technology is currently putting work into the development of internet services.

“This is providing us with a common set of protocols that allow integration to occur at a lower cost than before” says Mr Swan.

“We have a standards based approach – through using XML, the applications should all understand a piece of data, so the business user doesn’t have to worry that we’ve implemented it on a particular box using such and such technology.”

Vendor assistance

The vendor community has naturally leaped aboard SOA with a passion and, of course, the marketing team can get a little over zealous. It is important that the whole organisation gets behind the project to implement SOA.

Mr Head of BEA systems notes: “This cannot be done in silos. The business has to get involved in SOA. There must be cross-business project funding. The whole point is that you can reuse the components that are built in different systems.”

Although technologies that help build the overall architecture have their individual benefits, banks must not be fooled into thinking they are SOA solutions. Peter Tebbenhoff, product marketing director, financial services industry at Tibco, says: “There is some daft, simplistic, technology marketing out there, but a lot of marketing has value where it serves to give guidance on when and where to use SOA.”

Mr Swan, referring to the phenomenon as ‘marketecture’, notes: “Web services do not equal SOA. They play an important part in our SOA but there’s more to it than that.”

This is also not a cure all for every IT system. There are only certain areas where SOA is suitable. The technology is designed to be both open and flexible – it is suitable for a wide audience. That has its drawbacks, however, as Mr Tebbenhoff explains: “The trade-off is that the more flexible and open a system is, the slower it is. There is a lot going on under the covers to make it that open and flexible.”

Although there is a large amount of interest from banks in making integration cheap and well distributed, it will be a while yet before vendors begin to open their own standards – for obvious commercial reasons. That is not to say that banks are finding this easy to implement alone. Third-party systems are often used because there are a number of difficult issues, such as creating the SOA registry, to overcome. This registry allows the bank to look at the services that it has – necessary to ensure that duplication is avoided – and without it, growing the architecture to an enterprise scale can be difficult.

Improvements are being made regularly to improve what the architecture is capable of – to enhance speed is crucial if some mission-critical front office systems are to see any shift towards this computing. At BT, enhancements to the network are being used to assist this. Mr Overtveldt gives an example of how this might be achieved. “You can allow the network user to define priority to particular types of traffic,” he says. “With trading there is huge requirement for speed. If the trading volume goes up, we can increase the size of the network that will be made available to certain XML traffic with particular characteristics. This can take latency from the seconds range down into the milliseconds range.”

Roll out

The big bang approach has had its day. Roll out to systems is gradual and starts with areas that are less critical and non-operational but will clearly benefit. For CSFB’s human resources, the implementation of SOA allowed a performance management system to be created with a 30% reduction in build time.

Shankar Iyer, executive vice-president of marketing and strategy at GemStone, notes there are cases of large scale roll outs, such as within Wachovia Securities, where SOA is seen as something of a blueprint for the organisation and is being built enterprise-wide. Often, he says, it will be deployed in specific areas to begin with. “Customer portals are a good example where it is often necessary to get data from different systems,” Mr Iyer explains. “In retail banking, there could be data in mortgage systems, loan systems and so on. Although the corporate customer portal will require different data, the construction of the architecture across the customer services area allows similar components, such as customer status information, to be reused across systems.”

3082.photo.jpg

Shankar Iyer, executive vice-president of marketing and strategy at GemStone

Potential

Despite the issue of speed, trading systems for certain asset classes – such as fixed income – are suitable for deployment across this architecture. At CSFB, Mr Swan sees further potential for the technologies to provide business advantage. “With derivatives, we have a great deal more complexity but the volumes traded are very low. That’s an area where we could use XML technology because it is beneficial to describe complex financial instruments in an extensible language. If we take an XML schema as being the DNA of a financial instrument, then we can start doing gene splicing to create complex derivatives.”

The long-term possibilities are the creation of systems alongside the products that they support. However, Mr Swan warns: “The technology is a little way behind us.”

Remodelling the architecture and the provision of technology will help involve information technology as part of the cost-saving and efficiency measures a bank can take. But when such a task is undertaken, the developer’s eye must look to the where top-line growth can be achieved.

Mr Swan believes a real paradigm shift is driving this. “We spent the last decade thinking that technology would give us a competitive advantage,” he says. “Now we have to get specific about where that advantage lies. We have to realise that building a faster settlement system than the guy next door isn’t going to give us a competitive advantage. If we can get our guys to build a better algorithmic trading system than next door, we can make some real money out of that.”

PLEASE ENTER YOUR DETAILS TO WATCH THIS VIDEO

All fields are mandatory

The Banker is a service from the Financial Times. The Financial Times Ltd takes your privacy seriously.

Choose how you want us to contact you.

Invites and Offers from The Banker

Receive exclusive personalised event invitations, carefully curated offers and promotions from The Banker



For more information about how we use your data, please refer to our privacy and cookie policies.

Terms and conditions

Join our community

The Banker on Twitter