Over the last 18 months, State Auto Insurance Co. has been using an intranet application that provides its independent agents with Web-based access to the company's mainframe for policy rates and applications.
Based on a technology called "screenscraping," the Web-enabled legacy extension has reduced turnaround time for issuing policies from weeks to days-and even hours in some cases. The technology-from Jacada Ltd.-also has slashed training time for new commercial underwriters to less than two days-from more than two months it took to learn the old green screens.
In addition, State Auto, based in Columbus, Ohio, is saving $600,000 annually in labor costs, and because agents and underwriters are now using the same rating engine, errors associated with policy rating have been reduced 90%.
These are impressive results. And, after initial reluctance to use Internet technology, the insurance industry over the past two years has had much success with "quick-and-dirty" techniques to make client information accessible via Web browsers. These techniques have enabled agents and customers to get quotes, apply for coverage, make changes to policies, and check the status of claims-via the Internet.
Now, however, insurance companies are realizing that this fast and relatively simple approach to legacy-to-Web integration is a short-term solution to a long-term problem.
Legacy applications were written long before "straight-through transaction processing" was even a twinkle in an IT manager's eye. And business rules that define the parameters of policies, claims, and quotes lie buried deep within legacy code. In a world where efficiency and flexibility are now mandatory, extracting those rules for rapid modification and reuse is proving to be not only necessary, but extraordinarily difficult.
LIPSTICK ON THE PIG
"The insurance industry is driven by the need to externalize internally developed, internally focused systems," says Dale Vecchio, research director, application development, Gartner Inc., a Stamford, Conn.-based research and consulting firm. "Often, it's done in the interest of self-service and the call center, where (a carrier) wants to give a unified view of client information that is maintained in a number of different systems."
The simplest method to cull data from legacy systems and present it on a user-friendly Web browser is what insiders call "putting lipstick on the pig," also known as screenscraping, says Ravi Koka, president and CEO of SEEC Inc., a Pittsburgh-based provider of legacy integration and migration solutions.
Screenscraping essentially "wraps" a set of mainframe green screens used to perform a particular transaction-such as submitting a claim-and presents them as a single transaction on a Web browser, explains David Holmes, chief strategy officer at Jacada Ltd., an Atlanta-based provider of legacy-to-Web integration tools.
The value of this screen-based approach is, typically, carriers have no other way to Web-enable their legacy systems, he says. Their applications were written in procedural programming languages, such as COBOL, and they have not been rewritten as "components."
As a result, many carriers don't have direct access to business logic within their applications. "And they don't have the time or wherewithal or don't want to assume the risk of reengineering or rewriting them," Holmes says. "So the only alternative is a screen-based approach."
reluctance to replace
Insurance companies are reluctant to replace or even touch their back-office systems for several reasons, says Martin Folb, chief technical architect at WorldGroup Consulting, an Emeryville, Calif-based firm that specializes in legacy transformation.
"Developers of the old systems are scarce." In addition, he says, insurance carriers write policies, such as life policies, based on products and plans sold 100 years ago. Since then, their products have changed and their rating processes have gone through many iterations.
"We have encountered customers who have tried to rewrite old legacy rating processes but they can't duplicate the rates the old system produces," Folb says. "So, until those policies expire, they have to keep the systems running to process claims and rate premiums."
Because legacy transformation is such a monumental endeavor, carriers have taken the "phase one" approach of legacy-to-Web integration, according to SEEC's Koka-the cheap, noninvasive screenscraping solution to enable their agents, customers and call centers to have Web access to legacy applications. "You can get it done for less than a million dollars in less than 90 days," he notes.
Although screenscraping has accomplished carriers' goals of quickly providing Web self-service to customers and agents or of improving call center service, the problem with the technology is that workflow isn't being improved, Koka explains.
"So if you have a policy processing system, it's going to work just like your old legacy system works. And the legacy system was designed for call centers and internal staff that used green screens. The workflow was not designed for straight-through processing from an agent or customer."
Although the industry has "laggards" who are still relying on simple legacy extension, many "early adopters" are moving into phase two of legacy-to-Web integration, Koka says. These carriers want to reduce costs of processing a transaction, he says. "Since insurance costs are all tied up in workflow and processing paper-there are no plants or machinery-if you can improve efficiency, you reduce costs," he says.
In order to gain these efficiencies, leading insurers are redesigning and automating workflow by taking a more invasive, more costly, and more time-consuming approach to modernize their legacy systems.
Today, a carrier may want an instantaneous quoting system, for example, Koka says. And providing instantaneous quotes may require a company to extract the business logic out of the legacy application and put it on a Web server.
To do that, a carrier would have to invest in a technology such as business rule mining, which isolates the business rules for providing quotes buried in millions of lines of COBOL or another procedural programming language. In this way, the rules can be grouped as "components" and implemented in a modern Web architecture, such as IBM Corp's Java-based WebSphere or Microsoft's .NET platform (see article, page 24).
THE MIDDLE TIER
Carriers are moving in a reasonable progression from "presentation" to "programmatic" methods of integrating the legacy and the Web environments, says Gartner's Vecchio. Programmers even use a hybrid approach, he says, using screenscraping techniques to access the original systems through programmatic interfaces and build a composite application in the middle tier.
In fact, many carriers are in the process of building this middle tier. 21st Century Insurance, for example, is migrating from the "quick-and-dirty" screenscraping approach-which enabled it to provide Web self-service very quickly-to IBM's WebSphere platform.
"What we're trying to do-and it's no different from any other company-is to establish an 'N-tier' or middle-tier architecture on application servers," says Marina Lubinsky, assistant vice president and manager of Internet business development for the Los Angeles-based carrier.
Beyond legacy-to-Web integration, she says, 21st Century's goal is to integrate the Web, the call center, and the interactive voice response system. "Last year, everybody was focusing on Web-enabling and going to the Web," she says. "Now, the issue is channel integration, so customers can interact with the company through multiple channels seamlessly."
IBM's WebSphere will enable 21st Century to establish a "service" layer in its IT infrastructure, which contains clear protocols on how the presentation component of a legacy application is required to interact with that layer, explains Bruce Millar, senior project manager at 21st Century.
This protocol-defining layer is a major step in channel integration, according to Millar, because it resolves the difficulty of accessing back-end functionality. "The biggest problem we've always had was that we had back-end functionality, but there were no clear rules or protocols to get at that functionality."
These emerging protocols-known as "Web services" standards-enable applications to integrate more easily-without customized solutions previously required to accomplish that task. In fact, Web services are heralded by many observers as the next generation of middleware.
"The magic of Web services is that finally there's a single set of standards that companies can use to modernize their IT assets," says Scott Hebner, director of Web services for IBM Corp., White Plains, N.Y.
WEB SERVICES
Just as HTML became the standard for Web browsers, protocols for Web services are the emerging standards for putting an interface on an application, Hebner says. "What HTML is to the user, Web services standards are to the programmer." Now, the programmer can extract "services"-such as renewing a policy or checking the status of a claim-from multiple backend systems and more easily integrate them into a new workflow for internal use-or make those services available to the outside world.
Travelers Property Casualty Corp. is a case in point. The Hartford, Conn.-based carrier recently collaborated with one of its business partners and streamlined its process of handling auto glass damage claims and repairs 30% by using Web services.
"We have a network of glass shops, and a customer with our auto glass policy and an auto glass claim can simply drive into any of them," says Diana Beecher, CIO for Travelers. The glass dealer can verify coverage with Travelers over the Web, do the repair, post the repair cost, and be paid electronically.
The Web services enabling this application were built by Travelers and its business partner using Microsoft Corp.'s .NET platform. Travelers built the Web services to verify coverage and pay the shop, and its business partner provided the Web services to locate nearby shops and schedule customer appointments.
Open platform
Using Web services interfaces greatly reduced the amount of technical coordination that was necessary for integration, according to Ron Calabrese, second vice president for Travelers' claims services information systems. "In the past, we've 'hand-crafted' interfaces with our business partners. Working (with Web services) was much smoother."
In the broader context, as Internet standards have progressed, an open, standards-based, networked platform is emerging, says IBM's Hebner.
"We started off with TCP/IP for communications, HTML for browsers, Java for programming, and XML for how you interchange data. And Web services builds on that," he says. "Think of it as the rings of a tree. Web services protocols are just the next ring of the open standards platform. And the Internet itself is becoming the platform to build and deploy to. It's not just an interconnection protocol like it used to be."
Indeed, pie-in-the-sky pundits even claim ultimately companies will publish their Web services in a directory on the Internet, thereby enabling outsiders to use them and potentially turning IT departments into profit centers.
But industry experts say companies aren't buying into that marketing spin on Web services. "It's a problem of trust," says Gartner's Vecchio. "I don't know who's on the other end of this thing."
"Although the marketing hype is that Web services will create a new industry whereby companies can share their services, we just don't think enterprises are ready for that," WorldGroup's Folb concurs. "Their data is their business." Instead, sources say, carriers will use Web services internally or with trusted business partners-to integrate applications among diverse IT departments and systems.
RIP AND REPLACE
Observers also see most carriers continuing to extend their legacy systems, rather than forcing the dinosaur into extinction. "My experience with insurance companies is they don't want to rip and replace everything," says IBM's Hebner. "They want to evolve the assets that they have-build new applications and integrate with their business partners."
Carriers are beginning to invest in rewriting or reengineering their applications-not laying the legacy to rest, according to Jacada's Holmes.
"If you have a mainframe application running today, it has survived the best opportunity you ever had to get rid of it, and that was Y2K," he says. "If the legacy system survived Y2K, it's probably going to be around a while longer."
Nonetheless, insurers will inevitably face the limitations of using "presentation" rather than "programmatic" methods of legacy-to-Web integration, according to Gartner's Vecchio.
They'll also need to determine a long-term strategy for dealing with the IT reengineering challenges of Web-enabling batch systems, and of providing Web-based transactional capabilities that can reliably update multiple back-end systems simultaneously, he says.
Not surprisingly, some carriers are taking the "Pac-Man" approach -replacing their legacy systems piece-by-piece with new technology that is inherently Web-enabled.
WorldGroup Consulting is working with a mid-tier carrier whose legacy environment was unable to support any "quick-fix" Web integration efforts because its systems were too antiquated, according to Ron Lang, director of insurance solutions at WorldGroup. As a result, the carrier decided to embark on total legacy replacement.
First, the carrier replaced its claims system, integrating it with its existing underwriting and billing systems. The company is currently rolling out the underwriting components. And early next year, its new billing function will be deployed. When the project is complete, the company will have one common system of record that is inherently Web-enabled and compliant with the Java 2 Platform, Enterprise Edition (J2EE), says Lang.
Most importantly, carriers must approach legacy-to-Web integration strategically, rather than applying point-in-time "Band-Aid" fixes, says James Bisker, senior analyst at TowerGroup, a Needham, Mass.-based research and consulting firm. "Technically, that means you must make sure you're not compromising architectural standards for the benefit of merely getting something accomplished," he says.
"If you don't have a Web-enablement architecture, you need one-so you don't end up with a spaghetti mess in the middle like you have on the back-end."
