"From an operational standpoint, what this very often causes is changes and exceptions are done outside the system, and it's these manual workarounds that most often are the cause of problems," says Nathaniel Palmer, chief analyst at the Delphi Group. "Also, customers' service expectations outpace the ability of [legacy] systems to keep up."

These problems, however, typically pale in comparison with the challenges presented by legacy system replacement. "More often than not, insurers choose to deal with their legacy applications," says Steve Discher, practice director at Robert E. Nolan Company. "Technology obsolescence is less of an issue for our clients these days. They're stretching out the life of mainframe and midrange systems."

To solve the inherent contradiction between "legacy" and "process savvy," insurers have done everything from wrapping system components with modern interfaces to performing complete architectural overhauls. They also have leveraged EAI, workflow, and business process management (BPM) technologies both to augment the functionality of legacy systems and to create completely new end-to-end processes.

A New Lease on Life

"We can rebuild him. We have the technology." In the 1970s television show, scientists rebuilt the fictional Steve Austin using the latest bionic components to make him the "Six Million Dollar Man."

The buzz today around technology promising to make systems "better, faster, stronger" is focused on service-oriented architecture (SOA). Under an SOA framework, insurers can build new and rebuild existing applications as interconnected services (often referred to as Web services for their XML-based nature), and a single service can be used as a component in any number of applications. SOA addresses the problems of locked-in business logic and integration difficulties that traditionally have made it difficult for monolithic legacy applications to respond to process changes.

Yet creating an SOA isn't for the faint of heart–or thin of wallet. In general, plan on a rebuilding project–like that of Steve Austin–to be measured in multiples of millions of dollars and to take several years. The SOA development contract between Fireman's Fund and IBM, reported at $157 million over seven years, is a recent, well-publicized example of that fact.

Estimating legacy system transformation costs is a difficult task for any insurer, involving an assessment of the size of each application targeted, the amount of "dead" code that can be eliminated, and the overall complexity of each application. "Those who have not already invested in 'Web enablement' initiatives, who have older infrastructure, older applications, and more 'home-grown' applications, will be facing potentially significant investments to implement an SOA," says Rod Travers, senior vice president of technology at Robert Nolan Group.

Rather than rearchitecting entire applications from the ground up within an SOA framework, many carriers are using SOA technologies to work from the outside in, picking off legacy system functions that can become reusable components and exposing existing system interfaces through services wrappers that can be accessed and used more easily by other systems that are part of the end-to-end process.

State Auto Insurance, for example, had no interest in replacing or rebuilding legacy policy administration systems from CSC (originally from PMSC) the insurer uses in both commercial and personal lines. "Those systems are pretty well entrenched here," says Doug Allen, director of IT at State Auto.

Rather than being obstacles to work around, he emphasizes the systems are assets that work well for State Auto. "Over the years, we've made a number of [company] acquisitions and migrated a lot of other systems as a result to [the CSC platform]. We feel good about the fact we have only two policy issue systems here and we have all our policies on one platform."

When State Auto deployed a commercial portal for its business-owners line in 2000, it had used a screen-scraping application against the CSC system. However, that wasn't a good solution in the long term. "As a screen scraper, the functionality is limited. It's not what the agents are expecting to see and do on their portal," Allen says.

Therefore, when the insurer deployed its personal lines portal, it wanted a more active connection between the portal and the company's admin systems, and it was committed to using ACORD XML both as the messaging method for that connection as well as for bridging rating and application processes directly to management systems used by agents. "At the time, CSC didn't support transformation for ACORD XML, so we wrote our own transformation application using .NET," Allen says. CSC since has added ACORD XML support to its platform.

Having created XML adapters for the legacy system, State Auto was able to integrate more easily Fair Isaac's Blaze Advisor underwriting system, running as a Web service, into its application process in early 2004. The company also has targeted specific mainframe functions for wrapping with Web services interfaces to make those available to other systems.

For instance, State Auto previously had built a mainframe-to-mainframe connection with ChoicePoint to retrieve credit scores. "Today, with our Web-facing applications, instead of building a new connection, we created "get score" as a Web service using .NET, which makes a call back to the original mainframe interface," Allen explains.

State Auto still does face some process challenges posed by its legacy environment, the primary of which is the batch nature of the system. Though the insurer runs "mini batches" based on workload, there still can be a day delay between application submission and acceptance.

Better Orchestration

Regardless of how much an insurer may modernize any particular legacy processing system, there are typical limitations to how much any end-to-end process can be automated using application-level capabilities. That is, system X may be perfectly adept at handling its part of the process and passing a completed task to system Y, but neither system provides visibility into the entire process life cycle.

That leads to business process management systems (BPMS), the current evolution of workflow technology. "BPM is workflow plus EAI [enterprise application integration]," says Art Barrios, business process management practice leader for BusinessEdge Solutions consultancy. "It's different from previous workflow technology, because before workflow was specific to one application, and if you tried to extend it horizontally, then the proprietary nature of the workflow systems wouldn't talk easily to other systems."

While a BPMS typically provides the process-modeling capabilities and the process-monitoring dashboards of a typical workflow system, the defining characteristic of a true BPMS is an "orchestration layer." This layer serves as an integration hub through which various applications, components, and services connect.

By establishing an application-independent orchestration layer, a BPMS can allow companies to create automated workflows that cross not only different systems but also different processes. As an example of this, Barrios cites the common processes associated with hiring a new employee. "You need to issue technology to a person, find a place for him to sit, and develop a benefits package. All those were typically handled by several different [legacy] systems with e-mail acting as the middleware. Employees would show up and be unproductive for days or weeks because they didn't have a computer, didn't have an ID, even didn't get paid," he says.

Contrast that with the same process orchestrated by a BPMS. "The [BPMS] 'knows' based on the recruiting system that someone is hired and moves that information to the HR system and then to the benefits system. It sends an order over to facilities to make sure the person gets a cube and to IT to get technology. Now, you've developed an end-to-end 'employee and contractor onboarding' process that is defined, controlled, and monitored. If it's start date minus three and you don't have a task completed, you can query the manager who is responsible for that task, yet you're still achieving that visibility using legacy systems in the process," Barrios explains.

Gaining better visibility into and control of processes while retaining legacy systems was a key objective of a BPM project at Brazilian health insurer DixAmico. The company was formed when Dix purchased Amico from CIGNA, giving the insurer locations in S?o Paulo and Rio de Janeiro that used different legacy plan administration systems. Having two different systems and a paper-based application process meant the company often had no idea where a plan proposal was in the underwriting process, let alone whether or not an agent had begun a proposal.

The company took a two-pronged approach to the problem. It consolidated the plan administration systems to the Rio de Janeiro platform, an internally developed mainframe system using Visual Basic, Cach?, and an Oracle database. In July 2005, it finished installing a BPMS from Fuego, which connects to the legacy system as well as its ERP and CRM platforms and a new Web-based plan-application system, which will be the carrier's only method of accepting applications going forward.

Whereas previously, DixAmico would not know a proposal was in progress until the plan was received in the mail at either the S?o Paulo or Rio de Janeiro office, now the company knows when an agent begins working on a proposal using the Web front end and can monitor it through the entire process. "Today, if someone calls and asks, 'Where is my plan,' we can say, 'It's in the branch office,' or 'We're analyzing it.' The process is totally under control," says Mauro Penha Bastos, technology director at DixAmico.

For DixAmico, the strength of its BPMS was its ability to orchestrate the application process while leaving legacy systems intact. "The difficulty [with previous workflow solutions] is we could design processes, but design tools couldn't automate the process. Fuego can make the connection with systems and processes regardless of language, allowing us to rebuild our processes without rebuilding our systems," Bastos says.

DixAmico spent about $225,000 (U.S.) on the Fuego project and on related consulting services from systems integrator Decision Warehouse, and the insurer expects to obtain a return on that investment within six months. "Before, we had 12 [manual] steps in the process; today, we have three because Fuego calls the rest automatically," Bastos says, adding the electronic workflow will allow DixAmico to reduce staff by centralizing certain tasks, such as the review of plan proposals by on-staff medical experts. "Before, we needed the physical document. Now, I can have people analyze the plan [anywhere]," he notes. The carrier also hopes to increase sales by providing timelier plan issuance and faster payment of commissions.

Grand Vision

To achieve the maximum benefit from a BPMS, companies need to think at the enterprise, cross-process level. However, enterprise deployments often start by addressing particular legacy system limitations and department-level pain points. That approach works fine as long as there is a larger vision at the outset. "BPM can start divisionally, but to achieve the greatest value, you have to look at it from an enterprise standpoint," asserts Barrios. Otherwise, "you'll find three divisions have installed BPM systems, but each has done it differently because the divisions weren't talking to each other."

Workers' compensation carrier Republic Indemnity first looked to a process management system because it needed to reduce cycle times in its claims process to improve customer service, reduce claim leakage, and avoid fines it had been incurring for the late payment of workers' compensation claims.

The main culprit behind the cycle time problem was not its claims system–an in-house developed AS/400 system using RPG and COBOL with a DB2 database–but the 200,000 documents it handled annually as part of its mail-driven claims process. Therefore, the company installed Exigen's imaging and BPM solution in 2003. "We wanted to wind up with a solution that would be used not just for claims but for underwriting, accounting, [and] billing," says Mike Kirrene, senior vice president and CIO at Republic Indemnity.

Republic Indemnity's legacy systems "relatively easily" supported integration with the new front end and workflow system, according to Kirrene. Exigen operates in a WinTel environment, although Republic transformed the database components of Exigen to DB2 under its AS/400. "We wind up with all our structured business data in DB2, which allows us to integrate more easily our business application worlds," Kirrene explains. The carrier also deployed new Citrix servers to deliver the new application to remote offices.

Rather than dealing with paper claim documents and files at each of its branch offices, today Republic receives all documents at a central post-office box at its headquarters, where they are imaged and OCR-processed. Claim data is keyed into the Exigen front end, which transfers that data to the legacy system and initiates a new claim workflow. If a claims examiner determines a claim is compensable, the Exigen system initiates an assignment to Republic's bill review partner. When the bill review is completed, the Exigen system prompts the AS/400 system to issue a check together with an explanation of benefits. And throughout the process, management uses the system to monitor the workflow to make sure tasks are handled within established time frames.

Increased efficiency related to the electronic workflow has reduced Republic's claim payment cycle by two days. Workload is distributed based on capacity, not location, and process monitoring practically has eliminated fines for late payments. The company plans an enterprisewide application of the system: It recently deployed Exigen to support the premium collections process and will next tackle the underwriting process.

Secret to Success

Insurers are keenly aware of legacy system characteristics that make it difficult to automate or improve processes; however, the Delphi Group's Palmer says they tend to overlook business issues. "The biggest impediment to process change may not be your legacy systems. It's cultural resistance and fear of change," he says.

That definitely was the case in DixAmico's BPM project, according to Bastos. "We didn't have problems with systems," he says. "We had other problems, such as having 25 processes and having to negotiate with two groups before changing any of them."

Companies often err by taking a systems-focused approach to solving process problems, Barrios adds. "Business comes to IT and says, 'The market is shifting; I need to provide new functionality.' Companies tend to look first at what legacy systems they need to modify, update, or replace, but that is a very vertical, siloed focus. Instead, they should look at the problem in terms of what needs to be fixed in the process," he advises.

It's all part of not just having process-savvy systems but being a truly process-savvy organization. "Yes, there is a tool suite you will need to get eventually, but [better process management] is a mental discipline you will need to wrap yourself around and get your company to adopt," Barrios states.

For carriers that can do this, the change is fundamental. "Today, we have stopped seeing 'systems' and begun seeing 'processes,'" Bastos says. "Our operation runs like an automobile production line."