Hyland TL 12 17 2018
Follow Us
ITA MEMBERSHIP

CORE SYSTEMS

CORE SYSTEMS

(Why) Are Technology Upgrades (So) Hard?

George Grieve | March 09, 2015

It is generally accepted that the P&C industry is on the middle of a generational wave of core systems modernization. By any measure the activity level is extraordinary. We are probably four or five years into what will be a 10-year cycle by the time we are done.

The cycle, as we have also discussed, is the result of various trends which have come together in a “perfect storm” to create this massive investment. Those trends include the rise of the Internet in everyday life, the need for carriers to compete and win more business in a mature slow-growing market, the evolution of modern core systems, the arrival of “C” level executives from outside the industry with high(er) expectations of IT, and the growing perception that these kinds of enterprise-wide legacy modernization projects can be done successfully. 

There is no doubt that one of the key factors in this generational wave has been the rise of a new wave of vendors writing configurable systems using modern software platforms.  If we had the data—and we don’t—to compare the frequency with which various vendors were short-listed by insurance carriers 10 year ago versus today, I venture to suggest a majority change. Most of today’s dominant vendors were not dominant a decade ago. Further, for those that made the short list 10 years ago and remain today, you are looking at a modernized base version of the software written in .Net or Java, with configuration capabilities. 

So, if we ask a different and more useful question, which is how many core system products that might have been short-listed 10 years ago would be short-listed today the answer is virtually none. My company recently proposed and reviewed a vendor shortlist with a client. When we do this one of the facts we present is the date of the last full software rewrite for each proposed vendor. In this instance these dates are 2004, 2005, 2008, 20012.  In other words all of these systems were (re)written in the last 10 years.     

Ten years is a lifetime in the tech world so maybe this doesn’t sound remarkable but given the sheer complexity of these systems, the broad functional footprint, line of business variations and the state by state regulatory requirements a 10-year-old core insurance system is just hitting adulthood.

How does a system (any system) get from infancy to adulthood? By a more or less painful process called upgrades. Upgrades, like human development and growth, can represent baby steps such as a bug fix release, or a major developmental leap, such as releasing a configuration tool kit. The former, generally are referred to as “dot releases”, the later are “versions”.  

We are all familiar with dot releases. Every time Apple tells me there is a new iTunes upgrade available or Microsoft takes control of my laptop my computer software is undergoing an upgrade. The result, most of the time, is that once I get my machine back things appear pretty much as they were. 

For example, many of today’s upgrades address security issues rather than provide functionality which is visible to the user. Version upgrades are something entirely different. Remember when people with nothing better to do used to line up to buy the new version of Windows and the tech press would breathlessly announce the major new system features incorporated into the system?  What happened when we got the box home and the DVDs out was a more or less painful installation process followed by significant teething problems.  But if a few days of irritation were all that was involved in a core systems upgrade you wouldn’t be reading this article, because it wouldn’t have been written.

The reality is that the analogy used so far, which is concerned with operating system software, breaks down for the following reason. While most Windows users don’t configure, customize, modify or extend the system functionality, every core system client does to some extent. Indeed, in this age of configurable systems the ability to do exactly that is a major selling point. Let’s return to this later.

We noted above that in most instances carriers are purchasing software that is relative new—written within the last 10 years. In general, the newer the software the less functionally and technically mature it is. The less mature the software the more clients will modify and extend it and the more frequently the vendor will issue major releases in response to market demands.  Most vendors issue major releases every one to two years. Given that a core systems replacement project takes between two and five years to complete the client is either looking at an upgrade during the core replacement implementation or is faced with one shortly after completion.

As we said earlier, not all upgrades are born equal, some are small and some are big. The key question facing a client is when and how much of an upgrade to take; how long, costly and risky the upgrade will be; and what the carrier will get from it. Like all projects an upgrade has a more or less explicit cost benefit case. 

However, in the case of upgrades, the choice is not always at the clients’ sole discretion.  A major challenge for software vendors is to keep its client-base somewhat current, usually within a couple of versions, in order to control maintenance drag. From the carriers viewpoint there are several issues to be considered in planning an upgrade. 

  • Can the upgrade be done in one step?  A carrier may find that if they are more than one or two major releases behind then a single upgrade is not possible and a two-step upgrade is required. For example, this may be caused by data structure extensions and enhancements, which the vendor added two releases ago. If data changes are involved does the vendor provide migration tools to assist with this upgrade? 
  • Does the vendor provide tools or services to ease the upgrade path? Young and growing vendors are resource constrained and very focused on the growth and expansion of their software to meet market demands. While that growth will generate upgrade pressures on their client base don’t assume the vendor has the bandwidth to create tools to ease the upgrade path for its clients.
  • What are the core functional advantages and issues? As we noted earlier a key question in any upgrade concerns the amount of modification and enhancement done by the client. Every carrier wrestles with functionality issues when implementing a vendor system. If key functionality is missing what should the carrier do? Wait for the vendor to create the capability? Build the capability inside the system using its tools? Build it outside the system and integrate to it? Unless the answer to option one is that the vendor will provide the capability as part of the implementation, options two and three are the only acceptable answers from a business viewpoint. The carrier’s IT shop is then inevitably faced, at upgrade time with a list of functionality questions: Has the capability that we wrote been replaced by vendor code? If so, does the vendor version provide similar enough capabilities and results for us to replace our version with theirs? Can we use part of their new capability and use the remainder of ours? If we decide not to use the vendor’s capability do we have to do anything to “switch off” their capability, or to reengineer or reintegrate our home grown capability?

The size and shape of an upgrade is also driven by the environmental constraints which the vendor creates and the amount of freedom the carrier is given. So far we have assumed that the carrier has a dedicated system footprint and the freedom to make changes as they see fit. This may be an in-house installation or it may be hosted, but as long as the carrier has control of their own instance of the system they both have the freedom to create a highly-customized vendor solution and to create attendant upgrade headaches. 

In a more tightly controlled environment, for example, a multi-tenant solution, the carrier may have less freedom during an implementation but will probably avoid much of the effort and risk associated with a major version upgrade. In the end, the nature, complexity and scope of an upgrade are a direct result of how the vendor views control—whether the vendor governs the extent to which carriers can control the system and what the carrier decides to do with the control it is given. 

Every choice to stray from the base system has an implementation cost and an upgrade cost. It is beholden on the vendor and carrier to jointly explore and justify the implications of these choices.   

 


Featured articles

Guidewire Feb 2018 MR

Majesco RH

ELECTRONIC CHAT

The Email Chat is a regular feature of the ITA Pro magazine and website. We send a series of questions to an insurance IT leader in search of thought-provoking responses on important issues facing the insurance industry.

ITA LIVE 2019

The tide is up! It's time to register for ITA LIVE 2019, our annual educational and networking conference! Our theme is "The InsurTech Revolution: Cutting Through the Hype." and we'll be bringing in a torrent of industry thought leaders, amazing insight and wonderful perspectives on the world of insurtech and its impact on the insurance landscape.

ITA LIVE 2019 will present real-life examples of true startup technologies that are helping insurers gain real advantage -- and a competitive edge -- in the marketplace. We’ll highlight the more successful InsurTech partnerships, while offering case studies that demonstrate exciting innovation and cutting-edge techniques impacting all aspects of the insurance ecosystem.

Ride the wave to LIVE 2019. Sign up today! We look forward to seeing you in May, 2019!

BLOGS AND COLUMNS

only online

Only Online Archive

ITA Pro Buyers' Guide

Vendor Views

Partner News