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

To continue reading, register here to become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

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.

Modernization

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.