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.
More SOA success stories:
British Telecom delivers value-added services
Countrywide reduces redundancy
Massachusetts pulls health systems together
Transamerica gives partners self-service access
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
