sues rather than provide functionality that 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 took 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-ben-efit 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.
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,
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 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 re-engi-neer or reintegrate our home grown capability?
The size and shape of an upgrade is also driven by the environmental constraints that 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
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 implementation and upgrade costs. It is beholden upon the vendor and
carrier to jointly explore and justify the implications of these
choices. ITA
This column originally ran in the March, 2015 issue of ITA
Pro magazine. George Grieve is a popular writer and
speaker on the subject of insurance technology solutions.
He is the author of “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 ITA.
