1.1 Purpose of this document
This paper is written to provoke thought about the problems that 20 – 30 year old legacy systems bring to the Property & Casualty insurance industry and what a CIO can do to resolve those problems.
1.2 The Background
Property & Casualty Insurance Companies have for over 30 years relied heavily on �enterprise wide� policy management systems. Arguably, more than in any other industry, these systems have been critical to the insurance industry impacting everything companies do (on a policy basis anyway) from policy design through the application of underwriting rules to the interactions with their distribution networks. As one vendor states it �The Software is the Business� and although we�re not sure the insurance companies would necessarily agree with that statement, it would be hard to argue that systems have not had a major impact on the business.
Starting in the 1970�s, an entire �vendor� industry developed, vendors started to sell software products to the P&C insurance industry that offered pre-developed solutions. These solutions were typically installed into the P&C Company via a large company-wide project that not only installed the software but also customized it to reflect the company�s unique needs, products and processes. In most cases, both the vendor and the company would participate in the initial project but then, with few exceptions, most P&C Companies would slowly take the maintenance and enhancement to the systems in-house.
Occasionally companies would take additional �modernized� releases from the vendors, but as the installed systems were subject to more and more changes over the years, the take-up of any new releases diminished as the effort required to �re-fit� the customization into the new version of the software grew significantly.
Eventually, most companies ended up with systems that, although they had started from a set of common vendor bases, were heavily customized and in many cases bore little resemblance to the original system. These systems have universally become known as Legacy Systems.
1.3 The Problem
The difficulty today is that even though the legacy systems perform most of the functions that are required in running an insurance company, and they unquestionably process transactions quickly and efficiently, the underlying architectures are 20 to 30 years old and are more �monolithic� than modern systems. As such they are more time consuming and more expensive to modify than �modern� architectures, which tend to see a separation of different functions within the code and are designed specifically with ease of change in mind.
These difficulties are now to the point for many companies that it is starting to impact their bottom line. Information Technology always finds themselves on the critical path for product or distribution changes and in some cases the complexity, difficulty and cost in changing these systems makes it impractical to make many of the desired updates. Simply keeping up with legislative change is taxing enough without doing anything pro-active.
This inability to keep up with business needs is becoming more acute by the year. Simply put, any CIO who does not address the lack of flexibility within his or her legacy system(s) is dooming that company to an ever-reducing ability to be on the leading edge of business innovation. In addition, the problem has been compounded by acquisitions and mergers; many companies, arguably most companies, now have two, three or even more of these systems.
Additionally, these systems have become the de facto repository for underwriting, pricing and policy design information. Frankly, for many companies, it could be said they are the only all-in-one-place repository for this critical corporate information.
So, what is an insurance company CIO to do? The status quo is, in most cases is simply no longer acceptable.
1.4 The Options
There are, in reality, only two options, replace the legacy system with a new system or renew the legacy system by web enabling it and then rebuilding it with a Service Oriented Architecture. Replacement entails, in effect, starting all over again with a new system. Renew means taking what is already in existence and turning it into a modern system with a modern architecture and design. Neither are trivial tasks and both options have pros and cons. We will examine each option in turn.
Replacement
Replacing a legacy system is a viable option that results in a modern system that has far greater flexibility, better ability to accommodate new and innovative products and better communication capabilities with trading partners.
However, the act of replacing a system is not trivial, it involves a series of steps, each one of which culminates in a key decision, a decision that is difficult (or at least expensive) to reverse if further information comes to light that demonstrates the decision was perhaps not the optimal one. Plus this is a process that will take anywhere from 3 to 5 years from start to finish and is by any measure a large multimillion dollar project.
There are two substantial risks in undertaking a replacement project.
The first is the sheer size of the project. A replacement project is a very large project with many players and many interest groups all vying for their requirements. The Standish Group, which has done substantial research on project success and failure, has factual evidence that links the likelihood of project success in inverse proportion to the size of the project. In other words the larger the project the smaller the chance of success. Standish estimate that only 29% of all major projects succeed, 53% are challenged and fully 18% fail. The whole philosophy behind the Rational Unified Process (RUP) supports this conclusion.
Additionally, and to a large extent related to the size of the project, the elapsed time, from the start of the project to the time the company starts to see any economic value, will be measured in years not months, possibly as long as two years or more. That is a long time for a CIO to operate a project on a trust-me-it�ll-be-worth-it basis, and it�s a long time for a CEO to tolerate such a project without showing economic benefit to the Board.
Finally, and perhaps controversially, for many insurance companies it will have been a long time since it has undertaken a project of this magnitude. There are different management requirements to undertaking a project of this size than there are for most of the projects that insurance companies manage on a day to day basis. Far stricter project management controls and processes have to be in place for large projects than are required for smaller projects. The savvy CIO will want to ensure all those processes and controls are in place long before the project starts. Adding such processes as the project progresses is a recipe for disaster.
The second problem is the actual loss of the legacy system. Many legacy systems have become the sole repository for all of the rules, practices and product designs within an insurance company. It is highly likely that at some point over the last 20 years or so, someone will have implemented a rule within the legacy system that is not documented, or the documentation was not properly updated when a change was made. It is difficult and time consuming to ensure you have extracted all the rules etc. out of a legacy system on replacement.
The corollary of this problem is also true, there are likely many rules and product designs that have occurred due to restrictions placed on the intended design simply because the legacy system could not manage the preferred method. A replacement project needs to be very careful that such rules are not built back into the new system because �we�ve always done it that way�.
Renew
The renew option is a relatively new option; it was only a few years ago, in September 2002, that Giga (now part of Forrester Research) stated:
�It is clear that new technology will no more replace legacy in total than legacy technology alone will satisfy the needs of today�s web-savvy users. The truth is that modernized legacy applications play a critical role�
They were not specifically referring to the insurance industry; however, the option is as applicable to insurance company software as it is to any other company software and, it is gaining momentum within the industry, as Marc Cecere from Forrester Research says �Application renewal within the insurance industry is on the upswing�.
Within most legacy systems the processing part of the software is tightly coupled to the screen display part of the software. To provide the flexibility that is required today, that tight coupling has to be broken.
Products like OARBIC�s transactional insurance portal, OSEA, can accomplish that de-coupling of the processing and screen display. Consider the following diagram
OSEA gathers data through its web interface, from legacy systems or directly from external Broker / Agency Management systems (BMS). It then applies edits, third party data, underwriting rules, and cross-data verification to the data in its �work in progress� database. It then passes, through pre-built Application Program Interfaces (API�s) the accumulated and edited data back to the legacy system for transaction processing, storage, downstream printing, reporting and other interfaces.
The problems of the replacement option (project size and loss of the legacy system) are resolved in a Renew process by use of a three-phase implementation process.
Phase1. The first step is to execute a project to install OSEA as a web front end only. Within this project, it is suggested that no processing (editing / underwriting etc.) is moved from the legacy system to OSEA. The intent is to �web enable� the legacy system as quickly as possible. This will demonstrate progress within the overall project to the company and allow the economic benefit of the overall Renew project to start to accrue quickly. Although estimates will vary from system to system, this process should not take longer than six months.
Phase 2. This step is actually a multi-phased process within its own right. This phase will see the removal of the rules, errors, help and workflow processes from the legacy system and implemented in OSEA. This can be done as one project, or, better still in several smaller projects. This will provide the dual benefit of having the underwriting, rules, pricing and cross data validation executed in a modern multi layer environment, yet will leave the more static and transaction oriented processes such as reporting and printing in the legacy system.
Phase 3. Once the complex underwriting and rules processing is occurring in OSEA, the legacy system can now be reviewed and rebuilt into a Service Oriented Architecture. As an example, the diagrams below represents 3 typical Legacy System transactions; New Business, Amendment and Inquire. The diagram on the left is the Legacy System as it would have been implemented. Notice that all three transactions do different things yet large pieces of identical code are duplicated across all three transactions.
The diagram on the right represents the system after a redevelopment of the transactions into a Service Oriented Architecture. The common code, (ADD UPD INQ etc.), have been turned into services that are consumed as required by the transactions. The advantage is threefold:
-
The common code only has to be maintained once, not multiple times.
-
It is far faster to change any of the programs that consume the common code, because they as smaller and more nimble
-
When changes are made to the consuming programs (the majority of all changes), given that the common code is not exposed to change, those programs do not have to be regression tested as there is no possibility of accidental change to the code.
The end result is a system that has a web based front end with a multi layer architecture that makes changes and additions faster and smoother and a Services Oriented back end that provides flexibility in design and change and robustness in processing.
Additionally, the Renew process has eliminated both of the major risks in a Replacement project because the project is broken down into multiple stages with production deliverables at the end of each stage and it eliminates the risk of losing rules that are buried in the legacy system as each part is thoroughly reviewed during the SOA rebuild.
1.5 The Conclusion
Which option is better? We don�t think there is a black and white answer to that question. It all depends on circumstance, if your legacy system is in really poor condition with lots of �spaghetti code�, no documentation, source code missing and so on, then you may be better off to replace your systems. On the other hand if your legacy systems have been reasonably well maintained and documented then the Renew option is clearly a viable choice.
From a software point of view, at the end of whichever project you select, done properly, either option will provide a flexible, modern system with which your company can move forward and tackle the market in a progressive and assertive fashion.
However from risk point of view, we believe there is little doubt that the Renew option has significantly lower risk than the Replace option. Very large, long projects are inherently risky, a Replace project, typically, has longer delivery cycles (1 to 2 years), fewer and much larger decision points and more difficult and expensive recovery options from incorrect decisions. A Renew project by comparison has shorter delivery cycles (4 to 6 months), a greater number of smaller decision points and, because the results of any decision are seen much quicker, faster and less expensive recovery options.
Peter Symons
Managing Partner, OARBIC.
[email protected]
416-362-4743
About OARBIC:
OARBIC Inc. is a specialized IT consulting firm helping the property and casualty insurance industry make older systems behave like new ones – and new ones behave the way they should.
We offer an array of consulting services, plus our OSEA software solution is specifically designed to extend the life of legacy applications to allow them to keep pace with change.
Our in-depth knowledge of the property and casualty insurance industry and our access to a global network of talented, specialized IT professionals, sets us apart from other consulting companies.
