Transamerica turns silos into services

SOA integration eases data exchange and exposes legacy systems as Web services that can be plugged into custom apps for insurance agents

One of the real promises of SOA is enabling companies to leverage existing legacy systems as a set of core, reusable Web service building blocks that can be assembled to create new processes and applications quickly and inexpensively. That’s just what Transamerica Life Insurance was looking for when it sought to provide its business partners with self-service access in real time.

“We exchange a lot of data with our different distributors outside the firewall,” says Jeff Gleason, director of IT strategies at Transamerica’s annuity products and services division. “A lot of that was being done via flat-file batch data exchanges.”

Gleason realized that to stay competitive, Transamerica would have to provide its business partners with real-time access to its numerous legacy back-end systems. That’s a complex undertaking, however, for several reasons.

“We live in a very challenging legislative environment, with Sarbanes-Oxley, the Patriot Act, anti-laundering laws, tax laws, and other types of controls,” Gleason says. “As legislation and the competitive environment change, we need to be able to make changes to our internal systems quickly, including changing rules, the ways taxes are calculated, or the way a product functions given specific criteria. At the same time, we often have to customize products and services for each of our different distribution channels. And sometimes we get requests from specific banks or broker dealers to create products for their particular niche markets or new areas they want to compete in. These things often impact our internal business processes.”

To provide real-time access, Transamerica also needed ways to validate agents as licensed and appointed to sell specific products in specific states. “Validating an agent is not as simple as looking something up in a system,” Gleason says. Depending on the commission structure there might be many different rules about how the commission hierarchy, which has up to 10 levels, is set up internally.”

With all this complexity, Web services and SOA were natural choices for Transamerica. “We needed a solution that was both tightly integrated and loosely coupled,” Gleason said. A lot of business logic exists within Transamerica’s current back-office legacy systems. “Instead of continually recreating that logic, it made sense to create a set of core services to expose that logic so that it could be accessed by different applications, processes, and channels, whether they were batch processes, real-time processes over the Web, internal fat-client applications, or even IVR [Interactive Voice Response] systems.” To support all these methods of access, each Web service would have to be capable of accommodating not only straight SOAP Web services calls but also MQSeries and JMS (Java Messaging Service). These core services could then be mixed and matched as part of a larger group of composite services that could accommodate the different needs of various channels and individual business partners.

18FEsoa_in4.gif
Click for larger view.

SeeBeyond’s ICAN (Integration Composite Application Network) provides the tools for exposing as Web services the back-end mainframe transactions that provided much of Transamerica’s existing functionality. One such tool, eGate Integrator, is used to provide the integration broker and message transformation from one data format to another. Other SeeBeyond tools leverage BPM capabilities to create the “agent hub” that handles the complex message routing required. So, for example, in response to a request from a user application, one of Transamerica’s three or four legacy policy administration systems might return a cryptic product descriptor. That product descriptor could then be passed to a separate distributor support system that would return a more user-friendly product name. That or another distributor support system might also handle commissions and manage the information on which agents are appointed in which states to which products.

The end-user applications use an insurance industry XML schema developed by the nonprofit Association for Cooperative Operations Research and Development (ACORD) standards organization. The XML data is then transformed into the proprietary format required by each legacy back-end application. Basically, this ensures the loose coupling essential to an SOA. “If we acquire another company and we need to validate agents against their distributor support system, it’s simply a matter of creating an adapter from ACORD to the proprietary format required by that system. Everything on top speaks ACORD and doesn’t care what the implementation of the service is behind the scenes,” Gleason says.

SeeBeyond also provides the tool for creating portals and graphical portlets. The ultimate dream is to provide each business partner with a single custom application and interface to all the back-end systems necessary to fulfill each partner’s specific needs.

Gleason advises those getting involved with SOA to do as much planning and preparation as possible. “If we had it to do over again, we’d spend a lot more time up front prototyping, testing, and setting up the architecture and standards. After all, you’re creating one object and one service that will be used by lots of different processes. You have to make sure you don’t make changes to the service that help one project but break others,” he says.

More SOA success stories:

British Telecom delivers value-added services

Countrywide reduces redundancy

Guardian Life Insurance uses SOA to get it right

Massachusetts pulls health systems together

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies