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 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
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.
K 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?
K Does the vendor provide tools or services to ease the up-
grade path? Young and growing vendors are resource-con-
strained and 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.
K 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 have the freedom to create a highly-customized vendor solution and to create attendant
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. ITA
George Grieve is a popular writer and speaker on the
subject of insurance technology solutions and will lead a
session on the CEO/CIO relationship at ITA LIVE. He is the
author of the book “Shop Talk” and is CEO of the consulting firm CastleBay Consulting. The views and opinions in
this column are those of the author and do not necessarily
reflect the views of the Insurance Technology Association.