Insurance Software Must Adapt Or Die

The property-casualty commercial insurance industry hascertainly learned to leverage software automation to enjoy itsbenefits, ranging from reduced costs to operational efficienciesand competitive advantages.

Given the heavy reliance on software automation, the industryrequires software that is stable, dependable and bug free.Moreover, providing flexible, yet stable software that easilyadapts to the dynamics of the insurance industry is a formidablesoftware architectural challenge.

Creating a stable, reliable software solution for the insuranceindustry requires more than simply having a well-thought-out designbased on the latest industry standards in technology. In theinsurance industry, software needs to evolve over time, continuallyadjusting to regulatory and market-driven changes in businessrules, forms and rates.

Responding to this constantly moving target requires a design,maintenance environment and software distribution methodspecifically with a “world of change” in mind. It is critical thatenhancement, maintenance and distribution of software introduceonly desired changes without the adverse effect of unwantedsurprises–all too common in many of todays insurance solutions.

One way to solve this problem is to construct systems whereapplication components prone to change are isolated from the restof the system and each other. These components can be arrangedrelationally, with each component able to communicate with allothers in the system. Or they can be arranged in tiers withcommunication occurring with only the tiers above or below.

Arranging components in tiers has the advantage of easy controlover communication between components. The most common form of thisarchitecture is three-tiered, comprised of:

A user presentation layer, providing easy-to-use interfacethrough a thin client.

A business rules layer, where business logic and rules areimplemented on an application server.

A data storage and access layer, where data resides on adatabase server.

This tiered approach allows developers to develop, maintain anddeploy each tier independently, without affecting the other tiers.It is even possible to distribute these layers across workstationsand servers in separate locations for possible performance loadbalancing or geographical considerations.

This three-tier architecture allows developers to modifyvolatile and continually changing presentation and data storagelayers. Over years, new technologies applied to these applicationareas have kept most insurer and vendor maintenance programmersmore than busy.

Through the transition from “green-screen” terminals to PCs(first DOS and now Windows) to hand-held wireless devices, thecontinual change in user presentation has been staggering–hardlyfor the faint-of-heart developer. Data storage has also introducedits share of change and challenge along the way, from flat files toindexed files, relational databases and data warehouses.

However, even with all the benefits it delivers, there is a flyin the traditional three-tier ointment. Three-tier architectureassumes that business rules will stay fairly constant and requirelittle change, but this is rarely true in the insuranceindustry.

One might still argue that there is little change even inbusiness rules, in that premium will always be equal to rate timesexposure basis, and the description of coverage for an insured isfairly constant. However, the complexity of change does become aformidable challenge when we look beyond the obvious and evaluateelements such as the 1000-plus changes published by bureaus eachyear, including new rates, new coverages, combining or splitting ofclasses of business and so on.

While bureaus promulgate “standard” policy material and file inall states and jurisdictions on behalf of their members, each stateand jurisdiction decides which parts to accept and at what time(effective date). In turn, each insurer independently decides whatportion of the policy material it will adopt, and at which time,based on the insurers business strategies.

Adding to the complexity, p-c insurers continually target newmarkets and adapt current insurance programs to maintain theircompetitive advantage. Throw in a few more variables–like multiplelines of business, multiple states and varying underwritingqualification parameters–and the resulting areas of change quicklybecome unmanageable.

All of a sudden, the encouraging promises of three-tierarchitecture fall short of delivering on the insurance industrysneed.

Three-tier architecture works when it isolates areas of change.If we were to construct an insurance industry software solution toisolate frequent areas of change, it would have to take intoaccount the three tiers:

For the user presentation layer, focus on what data is presentedto users, and how.

For the business rules layer, focus on rates and rules, forms,and underwriting for each market the carrier writes.

For the data storage and access layer, focus on what data isstored and accessed, and how.

However, in the insurance industry, the quantity of change,types of change and amount of change require more than three layersfor an effective architecture.

The needs in insurance have morphed from the traditionalthree-tier architecture to an “N-tier,” where “N” can represent anynumber of layers depending upon the application and businessneed.

The key to managing the constant changes in many tiers requiresan architecture that encompasses the design, distribution mechanismand maintenance environment of the software solution.Unfortunately, there are many seemingly well-designed softwaresolutions that quickly lose their usefulness because themaintenance environment and distribution mechanism cannot supportthe ongoing changes.

Small software solutions that will require few changes, createdby one or two developers, are typically easy to design and develop,allowing for easy control in a stable development environment.

However, large, complex software solutions, like those demandedby p-c rating and policy issuance systems, often require multipleteams of developers to deal with the complexity. System design andarchitecture for these complex solutions must properly isolate thetiers while ensuring adequate communication between the tiers.

The maintenance environment must give information technologypersonnel the ability to make an isolated change.

While this sounds simple, too often a large section of softwaremust be accessed to make a seemingly small change. If thiscomponent was not properly designed and isolated, introducingchange during maintenance could adversely affect the applicationsbehavior, introducing instability and errors.

Extreme care must be taken to create and sustain a maintenanceenvironment that is consistent across time, especially given therate of change in the technology and tools used in the maintenanceeffort.

Once a change is successfully made, the distribution mechanismmust ensure that the change and only the change is packaged, sent,and installed correctly. Distributing more than the necessarychange increases the chances that something unwanted will beintroduced into the installed software.

In addition, the distribution mechanism must be able to recreatethe entire software solution in case of disaster recovery,alternative site deployment, or major system reconfiguration.

This was easy in the days where one program did it all. Todaythis is an increasingly difficult task. The distribution mechanismmust distribute the appropriate software component to theappropriate place in a sea of servers and desktops.

Mastering change in the p-c rating and policy issuance softwareworld is a difficult and complex task. It is not enough to have awell-designed architecture or simply isolate areas of change. Thesoftware architecture, maintenance environment and distributionmechanism must all be designed to support the appropriatetiers.

They must work together and support each other to create astable, reliable software solution. Integrate good softwarearchitecture, a stable maintenance environment and a reliabledistribution mechanism, and you are on your way to mastering changein the ever-changing p-c insurance industry.

Steve Felt is director of project management at INSTEC,based in Naperville, Ill. He can be reached [email protected].

Reproduced from National Underwriter Property &Casualty/Risk & Benefits Management Edition, April 8, 2002.Copyright 2002 by The National Underwriter Company in the serialpublication. All rights reserved.Copyright in this article as anindependent work may be held by the author.