Activity level has remained high among both insurers and core system vendors. Just in the month of July, at least five insurers announced a new policy administration system purchase. As of February 2014, approximately 160 insurers were in the process of implementation, and in the past two years, nearly all policy administration system vendors have made major investments in upgrading features, functions, usability and integration methods, according to research and advisory firm Celent.

Successful integration can make or break a core system project. In fact, 54 percent of 203 insurance executives surveyed by SAP in 2013 believe the best practice for managing core systems modernization is to find a trusted partner with an integrated solution platform. In the same survey, 38 percent of respondents felt that their systems are completely outdated, poorly integrated and cannot be modernized incrementally.

As insurers take on more core system transformation, here’s a look at a few system integration dos and don’ts.


Strong, flexible architecture is key and where it all starts, says Oleg Sadykhov, principal of X by 2, a technology company specializing in software and data architecture and transformation projects for the insurance industry. “Lack of it can ruin it all,” he says. “When you embark on these things, there is so much that needs to get done and you have to have strong principles to deal with that complexity. When you dig into the specific details, you have to have very strong principles built in the technical approach to the project.”

It sounds simple, Sadykhov says, but surprisingly it’s often not emphasized as much as it should be, and the focus turns too much to the integration platform and what it can do. “I always propose to focus more on architecture and design principles and patterns, versus really zooming in and trying to use the tool.”
PricewaterhouseCoopers also says needed integration and enterprise infrastructure changes are often ignored or made in parallel with policy transformation. In its Viewpoint report on implementing fast, flexible policy admin systems, the firm says insurers must develop and execute needed enterprise infrastructure changes prior to the policy transformation to lower project risk and duration.


Foresters, a fraternal life insurance and investments provider with more than a million members, recently completed a massive transformation project involving its infrastructure, new business systems and policy administration. New infrastructure included an enterprise service bus and a data warehouse built on a Teradata platform and leveraging SAS tools. Applications included MajescoMastek’s New Business & Underwriting System and its Elixir North America Policy Administration System, as well as Microsoft Dynamics CRM. The multi-vendor, multi-system nature of the project made over-year planning and integration of project plans a challenge.

As part of the effort, systems vendors and services providers participated in daily, weekly and monthly review sessions and project tracking. Senior company executives were kept informed of progress, and Foresters created a monthly steering committee to deal with any priority items that came from the joint project teams.

In all, the project team included more than 100 internal IT staffers as well as about 300 contractors, distributed across six locations. The project, which took about two years to complete, involved multiple systems replacements and additions.

“There was a lot more than just the new business engine and the policy administration engine,” says Peter Sweers, SVP and chief operations and information officer. “It was an image-enabling and an enterprise-services bus, a new voice-over-IP network and outsourcing deal. Taking the barometer of your organization’s preparedness to embark on a journey like this is a key point.”

Integrating all the work and coordinating those partners and teams responsible for the specific areas was a challenge, Sweers says. “For example, launching the new business system in the absence of having the image enablement platform in place wouldn’t have driven any value for the organization. And then you have the infrastructure play of putting the whole Red Hat Linux stack for the back end, and the enterprise-services bus to manage all of the transactions. All of it was required to culminate within weeks if not months of each other, that one got delivered and the other one was consumed. It was tested as an integrated service. It was a lot of coordination.”


Testing is one of the most important parts of any project. Thinking about testing a little harder up front, and preparing a more automated way to test will help, X by 2’s Sadykhov says. In a transformation project where it isn’t practical to discontinue every single wire from the existing system and replace every single wire, sometimes preservation is the way to go. “In a recent project [I worked on], we were talking about bringing data from the new system to the portion of the old system and continuing to keep that portion alive for the integration purposes. There was a whole other effort to build testing around making sure that various scenarios can automatically be tested. Automation of testing becomes even more important, and a little bit of effort to build the tools around that will be worth it.”


Maintenance accounts for 56 percent of North American insurers’ IT budgets, according to the Celent report “IT Spending in Insurance: A Global Perspective.” Insurers have seen the benefit of replacing legacy systems with service-oriented architecture and implementing other practices to ease integration issues. How- ever, while all of these efforts reduce maintenance costs, maintenance during a large integration project can turn into a last-minute, fast-fix situation.

Looking back, Foresters’ Sweers says he would’ve benefitted from designating someone to keep the lights on while he focused on the larger project. “Aside from running IT, I also run all the operations for the organization. I’m responsible for business continuity, disaster recovery and underwriting claims, and the amount of time and attention that this [transformation] took, as well as personal energy of mine, was phenomenal. I would have benefited from having a senior kind of lieutenant on a day-to-day basis.”


“Insurers have their legacy systems that they have built and accumulated over many years,” Sadykhov says. “So the cost comes from just the sheer amount of components that they grow over time. Just to be able to get your arms around it and understand every component and think about how to organize it [is a challenge]. You have to be pragmatic; you have to be clear that boiling the ocean is not always possible. If cost and time really get in the way of getting practical wins in this project, sometimes you need to get creative in terms of hybridizing or keeping some of the components alive a little longer. Otherwise, trying to get everything at once will be what killed the project.”

Register or login for access to this item and much more

All Digital Insurance content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access