Insurers looking to upgrade legacy systems to modern platformsare faced with the dilemma of whether to bring in developersfamiliar with new technologies and teach them insurance, or toutilize legacy developers and teach them a new developmentenvironment.

When Great American Insurance Group looked to revamp its policyadmin system, the company wanted to leverage its legacy developmentstaff. “We firmly believed we needed to utilize the expertise wehad,” explains Donald Maddox. “Even though the technology may havechanged, when you have people with 15, 20 years of insurance andinsurance technology background, they are extremely valuable to anyproject.”

Maddox, formerly a software developer at Great American andcurrently technical architect at ACORD, teamed up with GregWebster, lead application analyst and developer at Great American,for a session on “Legacy Insurance Developers in a New TechnologyWorld” at this week's ACORD LOMA Insurance Systems Forum.

Their presentation detailed how Great American successfullytransitioned its mainframe development staff to a web developmentenvironment in order to deliver a J2EE policy admin system based ona service-oriented architecture and to support other internalJava-based systems.

“We've replaced our entire infrastructure, moving from amainframe COBOL environment,” Webster says.

Real-World Insight

“What we learned in the transition process is relevant tomanagers, senior level developers who have a background inmainframe systems, and to people who are experienced in newtechnologies as well,” Maddox explains.

Webster has a first-hand view of a developer going through thetransition process.

“It can be a humbling experience,” he recalls. “You areessentially starting over. One minute, you're the person everyonecomes to with questions; the next minute, you don't even understandthe terminology being used.”

That's where Great American's training and mentoring programscame into play. The programs not only helped legacy developerslearn new methodology, but also allowed them to realize how theirwealth of systems development experience could be applied to modernplatforms.

“At a fundamental level, core insurance systems are designed tosupport the same processes and functionality developers alreadyknow. You need to help developers translate that knowledge into newterminology and methodology,” Maddox says. “The biggest obstacle intransitioning from a legacy environment isn't technology, it's yourorganization.”

Working Through Challenges

For Great American, the biggest organizational challenge wascaused by turning the knowledge hierarchy upside-down.

“There were 'people problems,'” Maddox explains. “You suddenlyhad people knowledgeable about new technologies but without a lotof experience at the company who were responsible for training andmentoring developers with a decade or more of experience. We had towork hard to build trust and establish effective teams comprised ofpeople with different styles of development, different backgrounds,and different expertise.”

“You need to put the right people in mentoring roles,” Webstersays. “You need to understand that when you transition adevelopment staff, it's not just about imparting new knowledge.It's about nurturing respect among all the people involved.”

Maddox says that recognizing the talents of legacy developmentstaff can go a long way toward addressing team friction. “It can bea real challenge for managers not to overlook legacy developerswith a tremendous amount of knowledge simply because they areunfamiliar with new platforms,” he says. “If you have someone whounderstands the insurance system end to end, that's the type ofperson you need to seek out and recognize.”

At the same time, insurers need to understand there is alearning curve involved. “Right after the transition, I wasn'tproducing as much code as before, even though my work ethic didn'tchange,” says Webster. “You do need to be patient with your staffas they get up to speed with new programming.”

The Bottom Line

Maddox hopes that attendees leave with a recognition that fordevelopers, things haven't changed as much as they might sometimesseem. In one of the session's most powerful demonstrations, heshows an architectural diagram of Great American's J2EE, n-tieredarchitecture that utilizes web services. Next to that is anotherdiagram of what the COBOL, CICS mainframe architecture had lookedlike.

“The point is, they are relatively the same,” he says. “We'vejust changed some of the terminology, colors, andfunctionality.”