Over the past 30 years, the world of automating policyadministration in property/casualty insurance has changed a greatdeal: In the early days of computing, companies built their own; inthe '80s, less than a handful of vendors became mainstream; and inthe '90s, riding a wave of technology innovation, an assortment oftechnically astute medium-size and smaller shops decided to trytheir hand at insurance.

However, except for the truly early days, one thing has remainedconstant. Modernizing policy administration has lagged behind theinsurance business innovation it was supposed to support. That gaphas been growing steadily over the last 10 years, particularlyamong mid-tier insurers.

Although difficult to ascertain accurate statistics–old and evensome newer policy processing systems have undergone so many changeseven their creators would not recognize them–plenty of carriersstill are processing policies on aged systems.

Are these old systems that good? Once upon a time they probablywere. In this day and age, though, that's not likely. So why do wekeep putting off replacing the "core" of core insurance businessprocessing? Is reinvesting in the old systems really worth theeffort and the cumulative cost, or is it time to cut our losses andmove on? Let's look for some answers.

This is something we keep hearing time and again: "The systemdoes its job, so why mess with it?" If that's true and the systemreally does live up to business expectations, then such a positionis hard to argue against. But is it true?

To begin with, the insurance business has transformed slowly butirreversibly in the past 10 years. One could cite a number ofsocioeconomic or regulatory changes that have transpired, but thefundamental reason behind this metamorphosis is customers havechanged. Whether "customers" mean agents or the insured or both,maintaining a customer-centric view of the world has becomemandatory for any carrier–large, medium, or small. Unfortunately,the systems in question are not customer-centric. They arepolicy-centric and, therefore, by design, unresponsive tocustomer-centric strategies.

Next, these systems are monolithic, again by design. This means,except for breaking in to tweak lines of code only to recast theconcrete, they cannot be disassembled easily into pieces that canbe independently reengineered or replaced.

Finally, the typical platforms these systems run on are fastheading toward the Antiques Roadshow.

Add it all up and what you get are systems that essentially arebroken. No amount of additional spending in the face of suchbuilt-in limitations can alter that fact. As a result, they'reholding the business back. Yet so many companies spend tremendousamounts year after year to extend the "useful" life of thesesystems. Why?

Indeed! But the argument works both ways. It's the same argumentthe industry has used since its beginnings to motivate our owncustomers into action: "Minimize your risk by investing inprotection." Unfortunately, where IT is concerned, we tend not toheed our own sound advice.

To "play it safe," companies have had to go out of their way todevise methods and techniques for extending the life of legacycode. The more complex methods include: reengineering, designrecovery, functional discovery, wrapping, etc., all of which aredrawn-out endeavors of very low certainty. Some carriers havediscovered successful short-term bandage approaches to protecttheir original investment. Others have not been so lucky. In eithercase, the costs were not trivial. But the really bad news iscompounding spending to hedge one's bets just multiplies theoriginal problem by moving long-term solutions further fromfinancial reach.

The excuses for avoiding a major system replacement are distinctfor different companies, depending on the type, origin, andarchitecture of their systems. The most common three are:

o pain (system inadequacies) not acute enough

o risk and cost too high

o no viable vendor solutions available

The first point speaks for itself: No pain–no problem–noargument from us.

That leaves risk/cost and vendors. We talked about vendors in aprior "CIO Chronicles," so let's leave them for later. Let's firstdeal with risk and cost.

Whichever way you may choose to do it–buy, build, or outsourcedevelopment–the cost of replacing a policy administration systeminevitably will be high. But as we've seen, so is your annualspending on the system you're running now. For the sake of weighingreplacement cost against perceived risk, tally the annualexpenditure on your current system. If you know what your TCO(total cost of ownership) is, great, you're already ahead. If youdon't, be sure to enter every detail, including the cost ofmaintaining historically knowledgeable staff, tools, hardware, andoperating systems. Then add the cost of the lipstick, middlewareglue, and other layers and wrappers you had to put in place just toget the system to work with, for example, the new CRM you bought,or to support mandatory external connectivity hubs and front ends.When you're done, extrapolate the calculated annual total at least10 years into the future.

Since high cost is a given, let's look at risk. Volumes havebeen written about the risks of replacing heavy-lifting back-endsystems–with good reason, too. The stats about the industry's trackrecord on how many projects flat-out failed and how many overrantime and budget are abysmal. But these stats just illustrate thesuccess or failure of IT projects in isolation from the business.What they don't tell you is what these projects were. How many werein-house development or outsourced custom builds, and how many werevendor implementations? Another missing piece of valuable data is:What really happened? Who failed whom, or rather, "whodunit"?

As bad as these track records may be, it is unlikely a failed ITproject will tank the business. Times have changed, and so has themeaning of IT-related risk. Today, the only risk worth examining isthe risk outdated, rigid processing systems can pose to theviability of the business. Although not often the case in thisindustry (a hot topic for some other time), business and IT must bejoined at the hip. If IT can't provide the agility not just tosupport but to help promote business innovation, the gap betweenthe two will widen, and then the business can and will tank.

Where does that leave us? The everlasting four choices are: Donothing, build, outsource building, or buy it from those that havestaked their businesses on it.

Ah, those vendors! "If only there were one that didn't . . .[insert your grievance here]." True, nobody's perfect. But have youtaken a closer look at vendors recently? We did. Earlier this yearwe were asked by a group of mid-tier carriers to examine policyadministration system vendors in the North American market. Welooked at 15 of the most relevant policy administration vendors ofdifferent size, maturity, and technology breed. Not just casually,I might add, but in considerable depth: from productfeature/function (including underwriting, claims, and billingfunctionality where these were parts of an integrated system) tobusiness and technical architecture, staffing, implementationmethods, and delivery capability. Last but not least, we alsolooked at their financial viability and "staying power."

The results? Suffice to say we were nicely surprised.

It has been said "the best is the enemy of the good." Eventhough some of these vendors may not have all of the functionalitywe're looking for, quite a few of them have come a long way overthe past few years. What they do have are functionally-,architecturally-, and technologically-advanced systems that–we haveno trouble saying it–are good. Certainly they're good enough toearn the right to be on your TCO and ROI sheets.

If all the above reads like a case for the vendors, it is forgood reason. First of all, there aren't any silver bullets or majorbreakthroughs out there just waiting to happen. Second,technological advancements are happening at such a pace that tryingto keep up with home-grown code requires a king's ransom in annualexpenditures. We've come across companies that internally have tojuggle up to 30 different technology platforms! Third, throwingcustom development "on spec" over the offshore fence certainly ismuch cheaper, but with hardly any exceptions, the returns appear tobe suspect–your core business application is just not a pair ofjeans.

Which brings us back to the vendors. If nothing else, they haveinvested heavily into their own competence of bringing new productsto this market. And they're worth a look. While waiting for thatsilver bullet or a miracle market leader to appear, we're missingout on opportunities to move ahead. It's time we all startedfocusing more on our own core competence instead of competingagainst the competence of others.

Take a keener look at some of the vendors out there. Look for"good enough" functionality among those that offer modern,business-flexible platforms.

Finally, work out a few TCOs and ROIs. Bear in mind, however,vendors operate on a shared-cost model. By sharing the cost of asystem and of its functional and technical improvements withothers, you gradually will be reducing your future cost ofownership.

When you compare the numbers, the relation between yourperceived and real risk may surprise you–perhaps sufficiently tobid a kind "thank you" and a firm farewell to that code ofyesteryear.