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

CIOs at the largest carriers know that their existing policysystems can no longer provide the flexibility, workflow efficiencyand self-service capabilities that both internal staff and externalcustomers need today.

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

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

And getting proof positive isn't easy. Scalability up to amodern PAS to handle 10 million to 40 million policies is a bigchallenge. Everything that makes contemporary systems souseful—configurability, advanced functionality, flexibility andworkflow—can exact a price in performance. All processes areexecuted in memory in real time, placing a big strain on a systemunless it's configured property.

Life and health and property and casualty insurers both havespecial challenges. Life and health insurers can haveindividual policyholders as well as group policies. P&Ccompanies have many different lines of business and highly complexpersonal and business policies packaging many coveragestogether.

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

Fortunately, modern systems have advanced and some can now bescaled 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 alongspeedily as it uses data seamlessly from tens of millions ofrecords, responding swiftly to hundreds of simultaneoususers.

Choose Balanced Software with a StrongBackbone

At one end of the spectrum is the mainframe system, which ishard-coded, inflexible and scalable. At the other end are somemodern systems that are ultimately configurable. They may not evenhave a comprehensive base-data model; the system is theframework.

But systems offering total configurability probably can't bescaled up for the biggest insurers. They become too complex to stayresponsive. There's a big risk in having less code and lesstechnology that's been proven scalable. If building and configuringyour system is like putting Legos together, you probably don't havethe right one for a big database.

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

Benchmark, Test and Remove Data Bottlenecks

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

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

The first challenge is creating an enormous test policyholderdatabase with 10 million to 40 million policies that acts as a truerepresentation of the insurer's specific book ofbusiness.

If it's a realistic test, there will be real data in both theconfiguration and client database. The test database needs tosimulate different groups and different policies. It can't be toovanilla and can't have too many cloned policies. Getting thedetails right makes a big difference.

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

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

Creating the database and testing the PAS' performance on dryruns and smoke tests is the only way to see behaviors that aredegrading performance and correct them. The goal is to completelyoptimize the system so that it's running the fewest transactionsbetween different layers.

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

A final step is to consider using state-of-the-art databaseservers with solid-state drives for example. While insurers need tospend their money wisely, hardware is normally only a smallfraction of the total cost.

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