By providing a standard approach across multiple vendors and technologies, service-orientated architecture will become simpler to manage. Heather McKenzie highlights the latest initiatives.

Among the reasons financial institutions consider implementing a service-oriented architecture (SOA) is the promise of unlocking data stored in disparate systems. Paradoxically, data can also cause real headaches during SOA projects.

Martin Prater, head of integration technologies, Credit Suisse Group, picks out metadata (the descriptions of the services within the SOA and the implications of them) as the difficult aspect in data management for SOA. “The problems are similar to those experienced initially in building data warehouses when we had to ask how we wanted to organise the metadata – where to store it and what processes we needed around the administration of the metadata,” he says.

Credit Suisse, which began its SOA implementation in 1993, remains one of the few success stories in the financial services industry when it comes to the realisation of an SOA strategy.

Data management issues

In terms of operational data, says Mr Prater, in principle management should not be a problem unless there is redundancy. “If data is in multiple services, then dealing with concurrency issues or data inconsistencies is necessary. You could also have the situation where one service is responsible for providing access to certain data however it is stored in a different location. These kind of data management issues are unique to specific situations and are not specific to SOA.”

Ken Rugg, vice-president of data services at Progress Software, a US-based software developer, agrees that some of the issues those adopting SOA face regarding data “would have occurred anywhere in more standard architectures, but they may be magnified in SOA”.

An SOA is a collection of services, which themselves are functions that are well-defined and self-contained. These services communicate with each other, either through data passing or through two or more services co-ordinating some activity.

Mr Rugg says one strategy in SOA is to pass a complete set of data for the business process with the business process. Every time messages are passed around the architecture, an XML document will go with it, containing all of the information required to fulfil that business process.

“These messages can get very big and will put a lot of stress on the infrastructure to move that data around,” says Mr Rugg.

“Once you start dealing with XML documents that are many megabytes, transparency can be lost because certain individuals may no longer be allowed to look at them and decipher the information contained therein.”

Another challenge, says Mr Rugg, is that through the lifecycle of a business process, information will be added to the XML document as services are added. “All of the data is being accessed from a source database, but at different points in time. This causes a problem with the consistency of the information.

“Financial institutions have to understand that the information does not have the same transactional characteristics and data consistency guarantees you would get in more traditional data management approaches.”

One way around this is to implement complex synchronisation of how documents are passed around an organisation, he adds. Another would be to pass references to information that is held in a single master, or to have access to multiple master copies and to implement some co-ordination between them.

Data storage

Martin Percival, senior EMEA technical evangelist at BEA Systems, says the financial industry wants to store data where it exists and where it understand it. “In building an SOA, if you talk about creating more information sources to deal with some of the data problems, most people would throw their hands up in horror at the thought of it. They believe they have valid systems already,” he says.

His colleague, Darshan Chandarana, pre-sales manager, financial services, says banks already have data marts or warehouses, which are usually batch-driven. “These are good for storing data, but they don’t give a current position and status. In financial services, many people have to make decisions based on accurate data. If data is exposed as services they can access in their architecture, it becomes a first-class citizen in its own right.”

One of the main problems with SOA and data, says Credit Suisse’s Mr Prater, is that there is no standard or generally accepted model for which information is needed to be stored to describe a service. A number of repository solutions are slowly evolving, he says, such as Systinet and Infravio, which many vendors are offering on an original equipment manufacturer basis in their solutions.

“These solutions originally come from a run-time-oriented area rather than a repository for development and you can still see this heritage in them,” he says. “These are OK for locating services and where they are running, but as soon as you get into policy issues such as security or charge-backs, where the user of the services needs to have this information, the area is much less standardised.”

Control and simplification

In April this year, Systinet launched Governance Interoperability Frame-work (GIF), an initiative aimed at making SOA simpler to manage and control by providing a standard approach across multiple vendors and technology. Systinet’s Business Services Registry acts as the system of record, containing services and associated policy in a standardised way.

Members of GIF include Above All Software, Actional Corp, BEA Systems, Hewlett-Packard and DataPower. They will jointly develop a set of technologies and specifications providing integration at the data, control and user interface level between partner products.

“The Governance Interoperability Framework provides for the first time a systematic approach to SOA governance,” says Systinet chief executive Tom Erickson. “It makes it much easier for enterprises to adopt SOA with confidence, while greatly simplifying the integration of the different components necessary for SOA.”

For Mr Prater, the first step in handling data in SOA is to develop a metadata model for services and decide which information is required and how it is stored. “A challenge is to populate the repository with metadata for each service in production. Credit Suisse chose to implement its own repository, as there were no alternatives at the time.

“In the meantime, we have started an evaluation of a commercial solution. We have looked at the commercial products recently but concluded that not all of our requirements could be met today. As we are not under pressure for starting a migration we will wait for the next generation of repository tools.”

Updating data

Another issue that needs to be addressed, says Mr Prater, is that data tends to go stale and administration processes need to be put in place to ensure that it is kept as fresh as possible.

BEA’s Mr Percival agrees: “Keeping data fresh within an SOA is a very intensive process. But this always has been a challenge for the financial services industry, as firms need to balance reliability with speed.

“If you want speed, you have to cache data, but that provides a problem in terms of access. There are ways to set up a data service platform that ensures the best of both worlds by refreshing information before any work is done on it.”

Mr Chandarana says the focus should always be on avoiding the creation of another data silo. “We can pull information from different data services and push it back to them. The longer you can keep data where it exists, the better. People have built the wrong architectures over the years for the right reasons. As a result, each department has a solution but these aren’t connected. But you can’t create another silo out of the ones that are already there.”

Peace-of-mind contract

Credit Suisse’s approach to administration was to have a binding contract between the service provider and the service user. Both parties should feel safe and comfortable with the contract, says Mr Prater. “All the data related to this contract is also stored in the repository. In our case, the contract data or metadata is made up of 10 tabs, which reside next to the syntactical and semantic interface descriptions, service level agreements and security policies.

“We also store information on all of the clients using the services. This needs to be kept up to date in order to know who is using the services, particularly if you want to make changes to a service.”

In terms of the application level data provided by the services, Credit Suisse defined a domain concept and split the application landscape into logical domains including customer, document, treasury, security and trading.

There are some 25 domains in total, says Mr Prater. Each domain is responsible for different data so when there is a request for a new service it is clear and well defined which domains must provide which data.

He says: “This is how we have eliminated data redundancy at the logical level. At the physical level the data itself may still be distributed across multiple applications and platforms.

“We try to keep the redundancy under control by managing updates in a controlled fashion and by replicating data from the primary system through a publish and subscribe approach.”

One of the drivers of SOA is the more agile approach it offers, says Progress’s Mr Rugg. “The challenge for SOA vendors is to reflect that agile approach in the data infrastructure. We need to build out data infrastructures that support agility.”

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