SOA ensures Guardian gets it right

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.

Click for larger view.

“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.