Responding to this constantly moving target requires a design, maintenance environment and software distribution method specifically with a “world of change” in mind. It is critical that enhancement, maintenance and distribution of software introduce only desired changes without the adverse effect of unwanted surprises–all too common in many of todays insurance solutions.

One way to solve this problem is to construct systems where application components prone to change are isolated from the rest of the system and each other. These components can be arranged relationally, with each component able to communicate with all others in the system. Or they can be arranged in tiers with communication occurring with only the tiers above or below.

Arranging components in tiers has the advantage of easy control over communication between components. The most common form of this architecture is three-tiered, comprised of:

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

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

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

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

This three-tier architecture allows developers to modify volatile and continually changing presentation and data storage layers. Over years, new technologies applied to these application areas have kept most insurer and vendor maintenance programmers more than busy.

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

However, even with all the benefits it delivers, there is a fly in the traditional three-tier ointment. Three-tier architecture assumes that business rules will stay fairly constant and require little change, but this is rarely true in the insurance industry.

One might still argue that there is little change even in business rules, in that premium will always be equal to rate times exposure basis, and the description of coverage for an insured is fairly constant. However, the complexity of change does become a formidable challenge when we look beyond the obvious and evaluate elements such as the 1000-plus changes published by bureaus each year, including new rates, new coverages, combining or splitting of classes of business and so on.

While bureaus promulgate “standard” policy material and file in all states and jurisdictions on behalf of their members, each state and jurisdiction decides which parts to accept and at what time (effective date). In turn, each insurer independently decides what portion 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 new markets and adapt current insurance programs to maintain their competitive advantage. Throw in a few more variables–like multiple lines of business, multiple states and varying underwriting qualification parameters–and the resulting areas of change quickly become unmanageable.

All of a sudden, the encouraging promises of three-tier architecture fall short of delivering on the insurance industrys need.

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

For the user presentation layer, focus on what data is presented to 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 is stored and accessed, and how.

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

The needs in insurance have morphed from the traditional three-tier architecture to an “N-tier,” where “N” can represent any number of layers depending upon the application and business need.

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

Small software solutions that will require few changes, created by 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 demanded by p-c rating and policy issuance systems, often require multiple teams of developers to deal with the complexity. System design and architecture for these complex solutions must properly isolate the tiers while ensuring adequate communication between the tiers.

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

While this sounds simple, too often a large section of software must be accessed to make a seemingly small change. If this component was not properly designed and isolated, introducing change during maintenance could adversely affect the applications behavior, introducing instability and errors.

Extreme care must be taken to create and sustain a maintenance environment that is consistent across time, especially given the rate of change in the technology and tools used in the maintenance effort.

Once a change is successfully made, the distribution mechanism must ensure that the change and only the change is packaged, sent, and installed correctly. Distributing more than the necessary change increases the chances that something unwanted will be introduced into the installed software.

In addition, the distribution mechanism must be able to recreate the 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. Today this is an increasingly difficult task. The distribution mechanism must distribute the appropriate software component to the appropriate place in a sea of servers and desktops.

Mastering change in the p-c rating and policy issuance software world is a difficult and complex task. It is not enough to have a well-designed architecture or simply isolate areas of change. The software architecture, maintenance environment and distribution mechanism must all be designed to support the appropriate tiers.

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

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

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