Editor's Note: Christopher Goetze is vice president, Technical Services of MphasiS-Wyde

CIOs at the largest carriers know that their existing policy systems can no longer provide the flexibility, workflow efficiency and self-service capabilities that both internal staff and external customers need today.

But existing mainframe systems have one big thing going for them: because of their static, batch-driven architecture, they scale up easily. Huge is no problem.

No CIO at a Tier One insurer is going to dump the current system without being sure that a new, modern policy-administration system will handle the load and not frustrate users. Choosing a system that worked great at a smaller insurer is no guarantee; it might slow to a crawl with huge database and many users.

And getting proof positive isn't easy. Scalability up to a modern PAS to handle 10 million to 40 million policies is a big challenge. Everything that makes contemporary systems so useful—configurability, advanced functionality, flexibility and workflow—can exact a price in performance. All processes are executed in memory in real time, placing a big strain on a system unless it's configured property.

Life and health and property and casualty insurers both have special challenges. Life and health insurers can have individual policyholders as well as group policies. P&C companies have many different lines of business and highly complex personal and business policies packaging many coverages together.

Self-service functions especially challenge modern systems. These transactions are different in nature than those of internal users. A broker or insured making a policy change or an inquiry does it in real time. The service layer in the system can be subjected to intensive volumes of transactions.

Fortunately, modern systems have advanced and some can now be scaled up to become the policy workhorse for a Tier One carrier. But it takes work.

Here's how to get a responsive modern system—one that hums along speedily as it uses data seamlessly from tens of millions of records, responding swiftly to hundreds of simultaneous users.

Choose Balanced Software with a Strong Backbone

At one end of the spectrum is the mainframe system, which is hard-coded, inflexible and scalable. At the other end are some modern systems that are ultimately configurable. They may not even have a comprehensive base-data model; the system is the framework.

But systems offering total configurability probably can't be scaled up for the biggest insurers. They become too complex to stay responsive. There's a big risk in having less code and less technology that's been proven scalable. If building and configuring your system is like putting Legos together, you probably don't have the right one for a big database.

In contrast, a modern system that's balanced between configurability and structure has a strong technology backbone built in C++ or Java or other technology. Around the backbone, the system can be configured to add data elements. It can be scaled up and stay responsive.

Benchmark, Test and Remove Data Bottlenecks

When a system is “chatty”—with many service calls to different tiers, it's not going to perform well with a big database. The key is to minimize the numbers of transaction between the UI layer and the back end.

How can you do that? Test, identify bottlenecks and tune the system. Test again. Repeat until the system is well tuned and optimally efficient.

The first challenge is creating an enormous test policyholder database with 10 million to 40 million policies that acts as a true representation of the insurer's specific book of business.

If it's a realistic test, there will be real data in both the configuration and client database. The test database needs to simulate different groups and different policies. It can't be too vanilla and can't have too many cloned policies. Getting the details right makes a big difference.

Here's one way to do it: First, create a baseline of 100 policies that reflects an accurate sampling of the insurer's actual book of business; base product configurations on the insurers' specifications; have an accurate mix of group policies and individual policies if the insurer has both types.

Next, you'll need tool to replicate this policy sample to create a policyholder database of the desired size. Partial data model replication techniques can replicate the data in stages.

Creating the database and testing the PAS' performance on dry runs and smoke tests is the only way to see behaviors that are degrading performance and correct them. The goal is to completely optimize the system so that it's running the fewest transactions between different layers.

Transactional data models are complex; systems often have 1,000 to 2,000 tables. These complex data models end up being very demanding on the database level. The database tier needs to be properly configured at a macro and micro level, taking into account that data elements can be added dynamically.

A final step is to consider using state-of-the-art database servers with solid-state drives for example. While insurers need to spend their money wisely, hardware is normally only a small fraction of the total cost.

A CIO can be sure that a modern PAS will meet the demands of even one of world's biggest insurers if it's realistically tested and tuned before implementation.

Special Reports /

Overcoming the Challenges of Scaling Up a Modern PAS for a Very Large Policyholder Database

Related Stories

Recommended For You