Early adopters: SOA worth the effort

The concept of a service-oriented architecture has gained momentum as an alternative to traditional enterprise application integration, and early adopters are drawn to it for all the things old-school EAI didn't deliver: flexibility, standard messaging formats, greater asset reuse potential and reduced integration expenses.

Instead of an architecture of independent applications woven together by proprietary message brokers, an SOA is built from software components wrapped with interfaces that use standards such as Simple Object Access Protocol (SOAP) to invoke them.

Also: Part 1 - Service-oriented hype to meet hard realities

The theory behind an SOA is that users can take new and existing components - such as a credit authorization check - and expose them as services without being tied to any specific user interface. These components then can be shared, reused and linked to create composite applications across a network.

However, the simplicity of the concept belies the effort required to make old systems fit into the new architecture. In Part 1 of our series on SOAs, experts pointed out all the work that needs to be done to service-enable applications and networks. Companies have to retrofit existing applications, build new layers of middleware, and devise new management practices and security defenses, for example.

Among the early adopter sect, companies have decided it's worth the effort it takes to migrate to an SOA-based infrastructure, one project at a time. Along the way, some have found SOA paybacks with reusable services to accelerate and lower the cost of development processes.

The Hartford Financial Services Group, for example, no longer thinks about overhauling monolithic application code, such as a relic from 1997, its Single Entry Multiple Carrier Interface (SEMCI) application. SEMCI lets agents enter data once and broadcast it to multiple carriers searching for a quote.

"If we wanted to make improvements we had to consider changes to the entire application," says Ben Moreland, manager of application infrastructure delivery for the Connecticut insurance and financial services provider. That left the SEMCI application near its breaking point.

To preserve the SEMCI application, a team of nearly three dozen architects rebuilt it by creating a series of Web services that tap into back-end legacy systems. As part of the work, the group also created a reference architecture that would become a foundation for the company's entire Property and Casualty business.

"We put in the [SEMCI] budget a management platform that could be used across the enterprise," Moreland says. On its heels followed a Universal Description, Discovery and Integration (UDDI) registry, and systems for orchestration, and publish and subscribe.

Those pieces set the SOA foundation, which The Hartford continues to develop.


Another reason users might look at SOAs is the opportunity to modernize business processes. Freeing staffers from repetitive data entry led the Naval Facilities Engineering Command (NAVFAC) to consider SOA.

NAVFAC designs and constructs Navy properties around the world, handling about $8.5 billion in facility services annually. But it's no monopoly: Navy building owners can choose NAVFAC competitors such as the General Service Administration (GSA) to manage their facilities. The GSA also isn't bogged down with the legacy baggage NAVFAC is, says Cmdr. Scott Smith, assistant CIO of the Washington, D.C., unit.

In the past there's been a lot of manual data entry required to share information among contract-management applications running on disparate platforms, he says. To even the playing field, NAVFAC looked to streamline its contracts administration processes by automating the interface between two key systems: the Department of Defense's Standard Procurement System, a Windows-based procurement system NAVFAC is required to use; and NAVFAC's custom, mainframe-based Facility Information System, which handles tasks such as funds management and project accounting.

NAVFAC wants to tie those systems to its new composite applications, including eProjects and eContracts, which automate project and contract management processes.

With conventional EAI, NAVFAC would have had to rely on message brokers, application adapters and translators to enable data sharing among the applications. It would have taken too long and cost too much money, Smith says.

Instead NAVFAC wrapped the current systems with Web services that draw out necessary contract information without requiring any changes to the application's source code. Jacada's Fusion software mediates between NAVFAC's legacy systems, Windows-based applications and the new composite applications, Smith says.

Having service-enabled these core business applications, NAVFAC hopes to find opportunities to reuse the components down the line, Smith says. "We're not at 100% reuse, but the tools are improving," Smith says.

Delivery date

For Wall Street Access, it was the desire to improve information delivery to customers, partners and suppliers that led to its SOA.

The New York brokerage firm integrates and aggregates stock market information from about 20 market data providers - including BusinessWire, CBS MarketWatch, Edgar Online, Pinnacore and the New York Stock Exchange - to populate its AccessPoint trading application.

The scenario was a natural fit for an SOA, but the firm arrived at that conclusion almost by default, says Peter Underwood, vice president and director of software development at Wall Street Access. The firm started with plans for a core set of interfaces to be exposed to different applications, then chose a development language - Java - and decided on IBM's WebSphere family for its platform.

The result is a disparate set of services brought together in a common framework. For example, one service automates the data exchanges between Wall Street Access and its external quote providers. Another service handles order management for a series of applications, he says.

"What we've wound up doing is programming things once on the service layer, coming up with one interface, then letting all the other applications utilize that. It's a true write once, use multiple times," he says.

Despite the simplicity of the concept, building an enterprise SOA raises technical and business challenges, Underwood says. For one, maintaining an SOA requires development discipline.

"One of the drawbacks is that when I make a change to one interface, the change affects every single application that uses the service," Underwood says. "When we started off, we thought we were fairly disciplined, but we found out we weren't." Where a lack of discipline hurts is when changes to an interface that's in production are required.

There also are performance issues to be aware of, Underwood says. XML is a verbose language, and Web services communications require serializing and de-serializing of information. "It's like having a conversation through two interpreters," he says.

Work in progress

Users agree SOAs don't get built overnight.

Moreland says over the past 20 years The Hartford has used some form of what is today described as an SOA. The retooling of the SEMCI application simply formalized the idea. Now The Hartford uses its SOA to support other services, such as document processing. It also has used the SOA to create a service around an existing application for providing an agent profile, known as a producer profile, that's used to determine access to systems.

The original idea was to authenticate to the existing profile application and request the data, but it was a cumbersome integration that would have taken months of development. Instead, The Hartford is using its SOA platform to handle agent authentication.

"We were able to do it in a half-day on our services platform," Moreland says.

Moreland says the exercise highlights the benefits of The Hartford's SOA, including reduced development time and maintenance costs, because the company doesn't have multiple versions of the same technology.

"That is what the SOA is all about. You start to abstract away the technical details. When you get business function reuse, that is where the business value is," he says.

While the hard dollar savings are difficult to quantify, Moreland says his staff now is doing twice as much to foster IT within the company.

Another benefit is a reduced reliance on any single vendor. "One of the comments we make to vendors in this SOA world is 'the easier it is to replace you, the more we like you,'" Moreland says. "We want to have a lot of flexibility to pull in a new vendor without having a major 18-month application rework."

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2004 IDG Communications, Inc.

IT Salary Survey 2021: The results are in