The promise of service-oriented architecture (SOA) is a world where everything interoperates seamlessly, pieces of applications are reused endlessly and development of new systems is quick, cheap and easy. But despite some high-profile deployments and the spread of Web services, when it comes to financial firms doing serious business with each other, SOA is being held back by competing standards and varying implementations.
Wall Street firms use SOA internally to integrate applications, create employee portals that bridge silos, and build Web sites for customers that bring in information and tools from a variety of applications, both in-house and from third-party providers.
The problem is that service-oriented architectures are composed of a complex–and ever-evolving–set of protocols. While the low-level standards are well developed, tested and universally used, they are more appropriate for the transfer of information like market data than clients’ sensitive transactions.
For Web services that connect to back-end systems, SOAs usually employ Soap, or the simple object access protocol, while Rest (representational state transfer) is used for customer-facing technology such as Web 2.0 applications. Soap is well supported by SOA vendors: Whether software is written in Microsoft’s .Net or Java, it can send and receive Soap messages, which are generally simple requests for information such as the price of IBM stock at a particular time.
Companies that use SOA for more complex processes typically select a technology provider’s platform and all the high-level standards that vendor supports. Many SOA platforms come with an enterprise service bus (ESB) that helps join Web services together. But firms are leery of opening up their SOA infrastructure to the outside world, preferring to limit interactions to the most basic level.
“Wall Street companies have deployed SOA and have spent a lot of money on it, but nobody has asked us yet to plug our services into their ESB–they’re just not there yet,” says Stephane Dubois, founder and CEO of Xignite. The San Mateo, Calif.-based company offers more than 60 subscription-based Web services, ranging from market data to interest rates.
According to Dubois, most of Xignite’s 400 clients–half of which are in financial services–use Soap or Rest. “But when they use Soap, they use it very simply, no advanced standards, no technology layers,” he says. “As far as I know, nobody is relying on the standards for security.” Instead, firms protect their data by keeping it behind corporate firewalls or on a virtual private network.
Pablo Grana, chief architect at Globant, a Hopkinton, Mass.-based software outsourcing company, says that data transaction standards are not yet proven. “It would be very risky to base a product or a project on the transaction specifications related to SOA right now,” he notes.
Technology giants such as IBM and Microsoft have backed different standards, with smaller vendors falling in line behind. And standards-setting bodies including the Web Services Interoperability Organization, Organization for the Advancement of Structured Information Standards and World Wide Web Consortium each have their own sets. For example, widely adopted standards for security include WS-Security, WS-Trust and SAML (security assertion markup language), and there are dozens more with highly specific purposes, such as partly encrypting a message so that only certain people can read more sensitive information.
When two companies decide to communicate via Web services, they have to agree on a common set of standards. These individual negotiations make it difficult to deploy complex Web services widely. “The standards question is still a moving target,” says Mike Curtis, VP of strategy at Dallas-based security vendor Critical Watch.
In financial services, security requirements are particularly stringent. “There is a high sensitivity to keeping data on-site,” he observes. “They’re historically on the far end of conservatism, keeping things close to the vest, not connecting out.”
Implementation Issues
Even when vendors adopt the same standards, that doesn’t mean they’re supporting them in the same way, which can mean extra work and higher costs for firms trying to launch external SOA initiatives.
“Conformance with a standard is one thing on paper and another thing to make it work out of the box, on the ground,” notes Vivek Mehra, VP of global financial services and insurance at San Ramon, Calif.-based IT vendor Keane. Because of the way that SOA has evolved, he says, technology providers implement standards differently and many use proprietary messaging. As a result, firms may have to write additional code to make pieces fit, he says.
For internal projects, cross-vendor compatibility is less of a problem, since companies generally pick a single vendor and stick with it. “They tend to use the full stacking inside the corporation,” says Globant’s Grana. “When companies really need to expose their services [to the outside], they tend to use more lightweight specs.”
One of the first decisions a firm makes when moving to SOA is whether to use Microsoft’s .Net or a Java-based framework from vendors like IBM. “Related to Java versus .Net, there’s a lot of talk about interoperability,” Grana says, “but there are still lots of edges that are really rough. No matter which you pick, you always have troubles talking to the other side.”
If custom programming is required to set up each point-to-point link, it defeats the purpose of SOA, points out Matthew Gardiner, senior principal at CA, an Islandia, N.Y.-based supplier of IT management software. “We’re still in the murky transition,” he says. Meanwhile, external SOA is used for cloud computing, software as a service, Web 2.0 and other rich, Web-based applications, he says.
Business Needs
Although internal usage of SOA promises to save firms money when developing and integrating applications, it can be costly in the short term-both in terms of money and speed.
For financial firms, transactions are measured in nanoseconds. An SOA infrastructure, while elegant in theory, is not necessarily optimized for speed. In addition, SOA messages are based on the extensible markup language (XML), a long-winded format for encoding information. The advantage of XML is that it is easily understood by both machines and people, but older messaging standards such as the financial information exchange (FIX) protocol are extremely compact and move quickly across networks. Even if the security standards were all there, switching to SOA messaging would add lag time, and the migration is expensive.
And while the move toward a universal set of standards and implementation processes has been slow, firms aren’t exactly clamoring for progress. Take, for example, OppenheimerFunds, which is in the middle of a full-scale conversion to SOA, using an ESB to pull all the pieces together. The key, says Geoff Youell, the firm’s AVP of architecture, is picking projects that make immediate business sense. “They’re prioritized based on business or strategic value,” he says.
The firm is not currently using Web services to connect with counterparties, explains Youell, and when it does link, it will be for basic information calls. “We are working with a third-party firm, enriching financial information for customers, and we will be moving to Web services for that,” he says.
Globant’s Grana agrees that, for now, SOA is used primarily for integration of internal systems. Connections between firms are “not really a business need right now, at least from what we see here,” he says. According to Keane’s Mehra, it will take two to five years before standards evolve to the point where SOA is the norm for transactions between firms.
Overall, SOA standards are about at the same place they were two years ago, says Xignite’s Dubois. The main difference is that the deployments are much larger. “Some people are pulling 100 million transactions a month,” he says. “These volumes you didn’t talk about two years ago.”
Mayur Pahilajani contributed to this report.
—
Article originally appeared in Securities Industry News, which has since closed down.
