Five years ago, Guardian Life Insurance decided to rethink the basic structure of its application silos, which had been developed with little attention to business goals, says Jaime Sguerra, chief architect at Guardian. "There was no standard way to build or connect applications, or any habit of reusing code," he recalls.

A new IT management team decided to change that, mainly to make application development faster, more nimble, and better aligned with business priorities. "We wanted to stay away from the one-off application and instead provide a single, common service wherever possible to reduce overall complexity. A service architecture is the way to make disparate technologies work together," Sguerra says, adding that, with an SOA in place, IT can focus on developing new applications, not reworking old ones. "Our philosophy is reuse. There's a ton of money invested in the legacy technology, and we wouldn't be able to justify a business case just for modernization."

Sguerra estimates that the SOA approach has saved approximately 30 percent of the application-development budget. After 28 months, about 60 services used by three key systems -- benefits plan administration, claims processing, and policyholder administration -- are now in place, as is the basic communications infrastructure. Of those services, about 50 are used by all three systems. And the work continues: Guardian plans to create 22 more services for those systems and then bring its other systems into the SOA model, Sguerra says.

At the heart of Guardian's SOA is its enterprise service manager, a collection of J2EE workflow and connector middleware tools and an IBM CICS/MQSeries message bus for managing requests. Requests come from one of three client systems -- a Web portal used by customers and independent agents, a CRM system, and an interactive phone system used by customers -- or from applications themselves. The enterprise service manager decides what services to invoke, in what order, and what data resources are needed. It then queues up the services and manages their interaction. At the end of the transaction, the client receives the requested result or an error message. Before the SOA was implemented, "users needed a checklist of all the system to run" for each task; "now, that workflow is built into the enterprise service manager," Sguerra says.

"We chose a central enterprise service manager because it was the best way to gain reuse," Sguerra says. Although it may make sense to have a decentralized architecture where service logic resides in multiple locations so that services communicate directly, that approach increases the risk of ending up with multiple versions of the same service as development gets out of sync across the systems, he adds.

Because independent agents use the claims, policyholder, and benefits systems as well, Guardian chose to implement its SOA through Web services. "It's harder to deploy applications to someone else's computer," Sguerra says. Developing a Web-based interface proved crucial in serving internal and external users with a single communication system.

The SOA uses Web-based intermediaries in an IBM WebSphere server environment as the framework for translating and massaging data and procedure calls as needed between applications and data sources, as well as SOAP for messaging. Although services reside in a variety of physical locations -- within mainframe applications, as discrete component services on other application servers, as part of a modern application, or as an external service -- the Guardian SOA groups them logically by system or as a shared service.

Because Guardian uses a large number of mainframe applications, its IT team faced a challenge in exposing all those applications so they could be used as services, Sguerra notes. Guardian uses WSTL (Web Service Transaction Language) in most cases to translate service requests among services, but in some cases, mainframe applications don't support that. Rather than rewrite the mainframe apps to accommodate WSTL, Guardian uses EJBs to perform the translation outside the application. In the application itself, "we just open a door to see the EJB," he says.

Sguerra emphasizes that developing applications as part of an SOA requires a new way of thinking about application development. "You need to know up front that it is a cultural change. You can't go into it pretending it's not going to be a challenge. It takes a lot of coordination," he says, adding that business units and application developers oftentimes resist sacrificing custom interfaces that prevent services from supporting multiple applications. Such objections usually disappear when the efficiency benefits have been proved, Sguerra adds. When a custom interface or function is truly needed, developers can usually supply a separate service that relies on a common service for the remaining functionality. There's always a trade-off, but Guardian is discovering its happy medium.