Taking Technology by the Horns

Insurers looking to upgrade legacy systems to modern platforms are faced with the dilemma of whether to bring in developers familiar with new technologies and teach them insurance, or to utilize legacy developers and teach them a new development environment.

When Great American Insurance Group looked to revamp its policy admin system, the company wanted to leverage its legacy development staff. “We firmly believed we needed to utilize the expertise we had,” explains Donald Maddox. “Even though the technology may have changed, when you have people with 15, 20 years of insurance and insurance technology background, they are extremely valuable to any project.”

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

Their presentation detailed how Great American successfully transitioned its mainframe development staff to a web development environment in order to deliver a J2EE policy admin system based on a service-oriented architecture and to support other internal Java-based systems.

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

Real-World Insight

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

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

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

That's where Great American's training and mentoring programs came into play. The programs not only helped legacy developers learn new methodology, but also allowed them to realize how their wealth of systems development experience could be applied to modern platforms.

“At a fundamental level, core insurance systems are designed to support the same processes and functionality developers already know. You need to help developers translate that knowledge into new terminology and methodology,” Maddox says. “The biggest obstacle in transitioning from a legacy environment isn't technology, it's your organization.”

Working Through Challenges

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

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

“You need to put the right people in mentoring roles,” Webster says. “You need to understand that when you transition a development 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 development staff can go a long way toward addressing team friction. “It can be a real challenge for managers not to overlook legacy developers with a tremendous amount of knowledge simply because they are unfamiliar with new platforms,” he says. “If you have someone who understands the insurance system end to end, that's the type of person you need to seek out and recognize.”

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

The Bottom Line

Maddox hopes that attendees leave with a recognition that for developers, things haven't changed as much as they might sometimes seem. In one of the session's most powerful demonstrations, he shows an architectural diagram of Great American's J2EE, n-tiered architecture that utilizes web services. Next to that is another diagram of what the COBOL, CICS mainframe architecture had looked like.

“The point is, they are relatively the same,” he says. “We've just changed some of the terminology, colors, and functionality.”