It's safe to say that you won't find any punch-card readers inuse at insurance companies anymore, and you'd probably behard-pressed to even find a typewriter. Those two machines wereinstrumental to record keeping and data processing at insurers fordecades but, ultimately, they made way for a new generation ofbusiness technology.

Every technology in place at insurers today will be obsoletesome day; however, many companies aren't willing to give up ontheir legacy systems just yet.

"The truth is, there are many companies that have been chuggingalong for decades with back-room systems written in RPG or COBOL.You don't talk about it at conferences because it's not 'cool,' butit's the reality of the industry," says Gregory M. Lawler, vicepresident of information technology at Government Personnel MutualLife Insurance (GPM Life).

"Especially at smaller to medium insurers, sometimes it is justa practical to retain legacy technology. Given the market they arein, the business they want, and the fact that a current systemrepresents sunk cost and does what they want and they know how tosupport it, the decision makes sense," says Frank Petersmark, CIOadvocate at architectural consultancy X by 2.

Surprisingly, cost is not the main inhibitor to technologymodernization. "We find the most commonly stated reason whyinsurers are not migrating to a new platform is that they feel therisk of replacement outweighs the benefits," says Martina Conlon,principal in Novarica's insurance practice.

The risk lies in trading the known for the unknown. Systems,particularly core platforms, contain business rules that reflectdecades of company history, records of products and customers, datathat can be mined and other valuable assets.

"Companies worry that new solutions on the market won't meetwhat they need, won't meet their needs quickly enough, or will comewith new problems of their own," Conlon says. "In some cases,organizations also have a sense of the risk involved with thetransformation because they've had failed projects, problems withvendor management, or other problems that have derailed previousreplacement projects."

A Solid Core

When Lawler was CIO at with his previous employer, SWBC, heannually assessed whether to replace the company's insurancetracking system, which was the core support for SWBC's collateralprotection insurance business.

"Every year we evaluated the system, and every year we came tothe same conclusion — the code was working fine," says Lawler. "Itwould have cost between $10 and $15 million to replace that system,and we would not have sold one more policy if we did. Therefore, wewere going to ride it as long as we possibly could."

In business for more than 130 years and writing a full array ofpersonal and commercial lines products, Michigan Millers hasaccumulated a collection of core processing and ancillary systems."We have deployed modern technology wherever we can, although wehave a few dinosaurs," says Maria Jasinski, vice president of IT atMichigan Millers.

One of those dinosaurs is its AS400-based commercial policyadministration system. Although the company replaced its personallines system in 2009, Michigan Millers is retaining the commercialplatform for now.

"The two lines are different in that automation is a much moreimportant part of personal lines than commercial, and we needed tomodernize personal lines to achieve that automation," Jasinskisays. "Our strategy in all lines of insurance is built onleveraging strength of relationships with agencies, and our currentcommercial lines system can support that based on the changes we'vemade."

Those changes include a new web front end for commercial lines,which Michigan Millers deployed in 2010 for use by both agents andinternal staff. "Having drop-down lists, automated class codelookups, underwriter-agent communication, and other featuresincreased the usability of the system," Jasinski says. "From ouragents' perspective, they are getting responses faster and reducingthe manual work they or their staff needs to do."

Michigan Millers is also in the process of adding anunderwriting rules engine, scheduled for completion this month, totarget straight-through processing of smaller commercial accounts.Their initial goal is for 50 percent of accounts to pass throughwithout underwriting intervention.

A Legacy of Challenges

Keeping legacy technology does have its share of challenges. "Onthe negative side, they're not making any more RPG or COBOLprogrammers. That is the hardest challenge to solve," Lawlersays.

The technology industry is trying. IBM has partnered with dozensof colleges, proving COBOL curricula and donating hardware fortraining. However, even with those efforts, there is likely to be agrowing shortage of COBOL programmers.

"We do have a greying of the workforce," Conlon says. "Insurersneed to address talent management to be sure they have the peopleon staff they need, whether it's training people internally orpartnering with third-party technology resources. Also, if insurersneed to address the fact that if they are maintaining older code,they may have a challenge attracting workers who want to work withnewer technology."

No matter how well a legacy system is designed, there will betechnical limits companies also need to address.

"We've definitely dealt with some compatibility issues that havelimited our ability to integrate between the front end and backend," Jasinski says. "As a result, we've had to limit thefunctionality of the front end, such as putting in new businessprocessing functionality but not endorsement processing. There aremany more data fields that need to be mapped with endorsements, sowe run up against more integration issues that would be much easierto handle with a modern, object-oriented architecture."

There are other challenges a company faces the longer it keeps alegacy system. GPM Life faced a licensing issue.

"We've been running the Genelco back-office system for 25 years,and the license runs out next year," Lawler says. GPM Life is inthe process of upgrading to a Java-based version of the system fromConcentrix, a process that is complicated by the fact that theinsurer extensively customized or changed the original base codeover 3,000 times in the last 25 years.

The company decided to rewrite all 3,000 custom changes itself,hired a Java programmer to train its RPG staff in Java, and spentthe past year "going over all the code in excruciating detail,"Lawler says. The company plans to complete the rewrite by December1 to allow testing before a 2015 deployment.

Incremental Modernization

How long a company can keep a system depends on the system."Generally, if a solution is maintainable and flexible, and ifusers can get access to the data they need, then it will have alonger life in an organization compared to one that is not designedwell, not well documented, and a bear to maintain," Conlonsays.

"Well-designed systems have databases in accessible formats witha normalized view of data, even if that view is in flat files.Applications that are data-driven are often more flexible, so evenif the system is written in COBOL, you can change the behavior ofthe system by changing the data in the database rather thanrewriting code, which helps address speed-to-market and otherobjectives," she adds.

Unlike the all-or-nothing switch that was required when leavingthe proverbial punch card machine behind, incremental modernizationhas been a strategy employed by some insurers.

"Companies start to look at code, eliminate redundancies, movedata out of code and into database files, and clean the data. Theyexternalize the rating engine. Over time, they can break the legacyup into little pieces and work through modernization in stages,"observes Jeffrey Scott Haner, principal research analyst inGartner's insurance industry advisory services.

"Insurers tend to do at least two common things to keep systemsrunning," Petersmark says. "One, almost everyone has found a way tounbundle the data from the transactional processing system and putit in a warehouse repository, operational data store, or some wayto make the data more usable and clean it up. That is a good lifeextender because, on the business side, what they want isinformation out of whatever system they are dealing with. Two, theyalways do something with the user interface to make it moremodern."

Michigan Millers bolted on a rules engine to its commerciallines platform and integrated the new front end with the company'sdocument management system to achieve greater workflow automation.This type of approach helps reduce the risk of replacement thatmany companies fear and also puts business objectives at theforefront.

"We see companies taking measured approach legacy modernization,starting with asking what their business goals are, whether theyare getting the functionality they need out of current systems toachieve those goals, and how to move forward from there," Hanersays. "They may see, for instance, that the functionality of asystem is in pretty good shape, but the underlying technology isdated to the point of being unstable, or where they don't have theskills to maintain it. We've seen a definite shift to abusiness-first approach to code transformation over the past fewyears."

Reaching the Limit

However, just like punch cards and manual typewriters, therewill come a time when any legacy — or current — technology needs tobe replaced.

"Unfortunately, we are getting close to hitting the limit of howfar we can take our technological capabilities without makingdramatic changes. There will come a point where we will need a newplatform that offers greater flexibility and easier functionalityenhancement. There are also financial savings on the IT side thatwe could gain from new technology due to easier systemmaintenance," Jasinski says.

"Right now we can meet our speed-to-market strategy, but as wecontinue to grow, we will eventually need to change," she adds. "Iwould say in the next three years, we will need to making someserious decisions."