3. critical reviews and certain other noncommercial uses permitted by copyright
law. For permission requests, write to the publisher at the address below.
Art Pennington, President
Xcelorate, Inc.
301 N Riverwalk Dr #402
Buffalo Grove, IL 60089
Email: Art.Pennington@Xcelorate.com
Phone: 312-231-7107
Ordering Information:
Quantity sales. Special discounts are available on quantity purchases by corpora-tions,
associations, and others. For details, contact the address above.
Rescue/ Art Pennington. —1st ed.
ISBN-13: 978-1494845230 (paperback)
ISBN-10: 1494845237 (paperback)
4. 1
i1
1
Contents
Introduction......................................................................................... 71
The Environment..............................................................................191
The Problem......................................................................................251
The Solution ......................................................................................311
Business Benefits ...............................................................................411
IT Benefits.......................................................................................... 491
Mission Critical Spreadsheets ..........................................................551
SharePoint..........................................................................................611
A New Customer Centric System....................................................651
Next Steps...........................................................................................711
5.
6. 1
Dedicated to life insurance leaders who struggle with time-to-market and
legacy software issues.
1
7.
8. 1
“It is not the strongest of the species that survive, nor the most intelligent,
but the one most responsive to change ”
1
! CHARLES DARWIN
9.
10. 1
CHAPTER 1
Introduction
on was excited and anxious. The new product was indeed
something to be excited about. Ron and his management team
had been meeting and planning for weeks. It was all coming
R
together. Legal, financial, actuarial, and marketing had all signed off and
felt the product was doable, in a reasonable amount of time, with huge
market potential. The only remaining question mark was IT, and that
was a big question mark.
IT had been involved from the start and was busy performing their
analysis of the legacy system to determine the scope and size of the effort
to support the new product. They had already voiced reservations about
the project but had no concrete estimates. Then it came – and landed
like a ton of bricks – two years and two million dollars!
The new annuity product, from all indications so far, was going to be
a real barnburner. The field was excited about the coming offering. All
estimates of volume indicated it was going to really take off. So, the two
million dollar price tag was actually doable. But the two years was a
showstopper. Some alternative had to be found.
That’s when I met Ron. My company, Trimark Technologies, Inc.,
had just completed developing a new policy administration system. It
was the first client-server solution for the industry. The software had
been in use at the Keyport Life Insurance Company (now part of Sun
Life) for about a year. And they had nothing but praise for it. They were
11. 8 • CHAPTER 1 - INTRODUCTION
able to double their business without hiring any additional staff. So, it
had certainly proven its effectiveness. And the software already con-tained
1
most of the features Ron needed for his new annuity product.
Since time was of the utmost importance, I promised Ron we could
deliver the software, with his new product installed, within three
months. We delivered the software on time. Ron made his date, re-ceived
a standing ovation from his board, and the new product was a
roaring success. That system eventually managed over a million annuity
policies – 20 billion in assets.
Most people would consider that a big success, and it was. But there
is also a downside. Ron now had two legacy systems to live with and
maintain. The new system definitely served its purpose and was in-strumental
in ensuring a successful product launch. It also supported
many other new products along the way. But that was over twenty years
ago. Ron’s company has been saddled with double the ongoing cost of
ownership for all that time.
I know this twenty-year-old event may seem like ancient history –
sadly, it is not. Carriers still wrestle with those very same time-to-market
and legacy system issues. Nothing has changed. Ron’s situation is
still a good example of how policy administration systems can become a
big black hole when you do something different in the way of products.
You may get a quicker more efficient solution – a new system of some
sort. But now your albatross just got heavier around your neck.
You can do that once or twice and you may be okay, but you can’t do
it ten times because now you have all these systems and nobody knows
them all and you need to have experts in each one. And you have all this
extra work you need to do – like commonality in terms of documents
and interfaces or whatever and you have multiple systems that must
provide them all. It becomes a giant mess.
Today, there are many carriers with multiple policy administration
systems. In fact, that is the norm. According to benchmark data collected
by Computer Sciences Corporation (CSC) from AM Best 2011 and sur-veys
of carriers:
12. RESCUE • 9
1
“A typical mid-to-large U.S. insurer maintains four or more policy admin sys-tems,
and many have portfolios of 10 or more systems”
The need to get products on the street is not the only reason we add
legacy systems. Sometimes they accompany mergers or acquisitions, or
come with acquired blocks of business. The acquired policies then re-main
spread across this growing collection of systems. All of the prod-uct’s
business rules and policy value calculations are embedded in
complex programs. It is just too costly to recode them and migrate to a
single system.
Executives like Ron are forced to just live with these consequences
and take the only viable option to get the business results required. If it
were easy to add new products to legacy software, no carrier would have
more than one system. And the all-important time-to-market, for new
products, would be short and predictable.
Does this sound anything like your business? How long does it take
you to get innovative new products to market? Is it months, or even a
year or more? How many legacy systems do you wrestle with?
All carriers struggle with these time-to-market and legacy software
issues. In a 2011 survey of two hundred insurance carriers, the industry
analysis firm Strategy Meets Action (SMA) polled carriers’ expectations
of a modern policy administration system. Seventy percent of
life/annuity respondents cited these two factors as critical:
• Decreased time-to-market for new products
• Functionality to enable non-technical users to update rates
and business rules
According to Karen Furtado, a partner at SMA:
“People want to be able to implement these systems to be interactive and configur-able,
rather than dealing with a significant amount of embedded code”
13. 10 • CHAPTER 1 - INTRODUCTION
Whether you plan to upgrade to a newer policy administration sys-tem
or stick with your current one indefinitely, the “Embedded Code”
problem will continue to be an issue. All policy administration systems
have their product code locked inside complicated software programs.
This embedded code is the direct cause of Ron, and the life insurance
industry’s, time-to-market problem. It is also the direct cause of the
growing collection of legacy systems at most carriers.
1
14. RESCUE • 11
Figure 1
1
Figure 1 clearly demonstrates the reason for this problem. The back-ground
squares represent the programs in a typical legacy policy admini-stration
system. The red, blue, and green lines represent the logic path
that must be followed for a typical transaction for a policy from each of
three plans. As you can see, there are programs that are heavily used by
more than one product. Many of these are the programs responsible for
calculating policy values such as: loans, funds, death benefits, etc. And
15. 12 • CHAPTER 1 - INTRODUCTION
those are the complex programs that most often require changes when
we add new products.
For example: Any product that makes loans available must use the
legacy system’s loan program. That program is necessarily complex,
since it must support loans for all products. That loan logic is not
viewable or modifiable by non-technical people. Also, the program must
be changed anytime you introduce a new product with a different flavor
of loans. That is the embedded code problem in a nutshell.
I’m not disparaging the design of our legacy systems. That is actually
an efficient way of designing software. It is good practice to write one
routine that can be shared. The problem is that no two products are the
same. When we add a new product, with different features, we need to
modify these common programs. This consumes an inordinate amount
of expense and time. In addition, with each change, these programs be-come
more complex and more difficult to modify the next time.
Within the legacy system’s programs, there is really no good alterna-tive
to the way changes are made today. But we do have the ability to
eliminate this problem.
If you think about it, there is an obvious solution that is staring us all
right in the face – spreadsheets. Your actuary probably already creates
pricing spreadsheets for each new product. With a new approach, we
could use those spreadsheets for all policy values calculations. We could
stop depending on our legacy software for those values – just enable the
legacy system to access that spreadsheet instead. We wouldn’t even need
to bother the IT department – to change those complex programs –
when deploying new products. All of the policy values would be calcu-lated
1
externally in spreadsheets written by the product experts (actuar-ies).
Just think of the advantages this brings. Each new product would be
independent of the legacy system. It would have its own spreadsheet for
all policy values. This completely eliminates the embedded code problem
– the time-to-market problem for executives like Ron would be elimi-nated.
16. RESCUE • 13
IT development time and cost is not the only impediment to getting
products to market quickly. But it certainly is the most egregious one,
especially for innovative products. This approach dramatically reduces
the IT time requirement for new products. IT would only need to be
involved if the product required new data fields on screens or in the da-tabase
1
or during acceptance testing. And those would be pretty minor
tasks, compared to product values changes. Just think of the time this
frees up for IT to address other major items on their to-do list – impor-tant
things like technology upgrades – that are delayed today due to re-quired
new product work.
Using spreadsheets for mission critical functions like this would have
been unadvisable in times past. Excel was a desktop program as part of
Microsoft Office. But, as I explain later, Excel has come a long way from
the desktop. Microsoft now provides Excel as a scalable, robust server
product and also provides comprehensive spreadsheet management ca-pabilities.
There are many organizations now using spreadsheets in mis-sion
critical situations.
17. 14 • CHAPTER 1 - INTRODUCTION
Figure 2
Figure 2 illustrates the advantages of this approach: it shows the
same process that figure 1 does, except now all three products are sup-ported
1
by their own independent logic. This architecture is much sim-pler,
and that simplicity yields major benefits. Following this concept, if
a new product with new features were added, there would be no changes
18. RESCUE • 15
required for any of the three existing products. Then, the only testing
needed would be to validate the spreadsheet logic for the new product.
It does take some work to get the spreadsheet concept up and run-ning.
1
But once that work is done, there is an incredible payback in busi-ness
and IT benefits:
• Turn off the Embedded Code - Remove the responsibility for
business rules and policy value calculations from your legacy
software for new products going forward
• Use Spreadsheets Instead - Place those rules, formulas, and rates
into spreadsheets, for each new product, so they can function in-dependently
and also be understood and maintained by your ac-tuaries
and non-technical product experts
• As an Internet Service - Enable those spreadsheets to be man-aged
by a central “Spreadsheet Engine” that is available to your
legacy system or any other system or service that needs policy
values
Spreadsheets are a much better choice for any calculation than em-bedded
code. They are the standard universal tools for financial comput-ing.
The “Spreadsheet Engine” enables a plug-n-play reuse of the pricing
spreadsheet for your legacy system’s policy values. This eliminates sev-eral
of today’s major business obstacles:
• Time-to-Market - This eliminates the need to modify your leg-acy
software’s values calculation programs when introducing new
products, so the cost and time required for analysis, program-ming
and testing of those programs is reduced to nothing, vastly
improving upon your time-to-market.
19. 16 • CHAPTER 1 - INTRODUCTION
1
• Regression Testing - Since no product programs are modified,
and all product calculations are independent, you no longer need
to regression test your legacy system, to make sure no other
products were affected.
• Conversion Costs – You can stay with your current legacy sys-tem,
and use the Spreadsheet Engine for all new products, as long
as it is useful to you. But, if you ever decide to upgrade to a dif-ferent
policy administration system, the Spreadsheet Engine
makes that conversion much simpler. Converting from older leg-acy
systems to newer improved ones is much less costly, since the
new system’s values calculation programs will not be modified for
any of your products. They will continue to use the Spreadsheet
Engine.
• Blocks of Business - Acquiring blocks of business is now a prac-tical
alternative for growth, since products can now be added
quickly to your legacy system. You will no longer need to leave
the acquired blocks on their incoming software – no more legacy
systems added to your collection.
• Product Visibility - All business rules, rates, and product calcu-lations
are now readily viewable, understandable, and modifiable,
by your non-technical product experts
• Quality – The policy values are now produced by your actuary’s
own spreadsheet. So, calculations, precision, and order of opera-tions
are exactly to their specifications. There is no longer a pos-sibility
of miscommunication during knowledge transfer to IT.
By relieving your policy administration system of the responsibility
for calculating policy values, you gain all of these benefits and more. And
I would love for you to realize every one of them. This can be the “in-
20. RESCUE • 17
flection point” that changes the way we think about new product fea-tures
1
and policy administration. In the following chapters, I explain how
this is accomplished via a "Spreadsheet Engine". I explain what the en-gine
is, how it works, and how you can take advantage of its many bene-fits.
21.
22. 1
CHAPTER 2
The Environment
he time-to-market and legacy system problems of executives
like Ron are probably going to get much worse. We face some
daunting challenges ahead. And our future products may be
T
radically different from current offerings. According to Ernst & Young's
"US Life-Annuity Insurance Outlook" for 2013:
"The US life insurance industry is confronting significant demographic, macro-economic
and regulatory challenges"
These are among the factors that in September 2012 led Moody's In-vestors
Service to cut its outlook for the life insurance group to negative,
from stable. Tackling these challenges requires even more innovative
new products. And, to stay competitive, we must become much more
nimble at introducing them. This points to an even stronger need for
something like the Spreadsheet Engine we are discussing. The Gartner
Group in their "Top 10 Technologies to Impact Life Insurance" states
that:
"One of the top business priorities among life insurers is improving speed to mar-ket
for new products, with growing interest in improving product quality, includ-ing
pricing accuracy and better fit to customer needs."
23. 20 • CHAPTER 2 – THE ENVIRONMENT
That phrase "better fit to customer needs" is a key to the challenges
ahead. As far back as 2010, the State Street Bank, in their "Vision"
document for life insurance, stated:
1
"The operational model of the life insurance industry is undergoing a significant
overhaul and massive changes are in store. Trends in the long-term savings needs
of consumers are driving a re-examination of purpose and product. Post-crisis,
capital challenges and regulatory changes are also having an impact."
Clearly there are many factors influencing the design of our future
products. And, though we don't know the exact form they will take, they
will certainly address many of the factors identified by Ernst & Young,
Gartner, the State Street Bank, and others, such as:
Demographic Factors
The population is aging, longevity is rising, and young people are
buying much less life insurance. This has many ramifications, primarily
in the area of product design and marketing.
Aging baby boomers need some type of guaranteed payouts from
their assets. Variable products may not be appropriate for that need. But
our low interest rate environment makes it very difficult to price a prof-itable
product. Still, they will need to somehow translate lump-sum re-tirement
savings into income.
There has been a 50% decrease in the total life insurance carried by
young people. Products that will better serve their needs must be created
and a marketing approach that will reach them must be designed. They
are much more tech savvy than the traditional life insurance policy-holder.
So, there are opportunities to explore in that area.
Pension Reforms
There has been a dramatic shift from defined benefit retirement
plans to defined contribution forms. In addition, there is an increase in
the amount of regulation of pension plans. The investment risk is also
24. RESCUE • 21
being gradually transferred from corporations and governments to indi-viduals.
Technology
Technology is transforming the way people make financial decisions
and the way organizations operate. This will precipitate major changes
in the life insurance business model.
Interest Rates
Interest rates have been steadily declining since the early 80's. But,
since the 2008 crisis, they have sunk to very difficult levels for life insur-ance
1
companies to manage many of the older guaranteed rate plans prof-itably.
Low interest rates are creating significant losses. In addition, new
products with any kind of rate guarantees are difficult to design.
The Future
We need new revolutionary products to meet these needs. You may
have a good idea of what your future products might entail. But, in gen-eral,
it is very difficult to know the type of products that will evolve.
They will certainly be influenced by all of the factors above. What is
called “Big Data” may also have a large influence.
According to the Price Waterhouse Coopers publication, “Life Insur-ance
2020: Competing for a Future”, by 2020, there will be 5 billion peo-ple
connected to the Internet and 1.3 billion terabytes of data will be
flowing by 2016. In both cases, that is several times the current values.
PwC says this data can have a profound impact because:
Advanced analytical techniques would allow your business to turn this goldmine
of digital information into a complete picture of how individual customers be-have,
what they expect and the risks they present.
Of course, many actuaries are also thinking about the future and cre-ating
ideas that may be incorporated into future products. For example,
25. 22 • CHAPTER 2 – THE ENVIRONMENT
Ken Beckman, ASA, MAAA, CFA, associate actuary at New Era Life
Insurance Company in Omaha, Nebraska, has written about an interest-ing
1
idea in his document “Risk Management For The Individual: The
Key To Life Insurer Success In 2020 And Beyond”. He states that:
To grow in the year 2020 and beyond, life insurers will need to become personal
risk managers for their customers rather than just a place where insurance poli-cies
are sold. Successful companies will offer a policy that provides comprehensive
risk management services for individuals and families. The product will offer
lifetime protection from all the primary risks in a single insurance policy
Providing a concrete example, he describes a product that covers the
three primary risks of mortality, morbidity, and investment. This prod-uct
includes coverages for:
• Life Insurance
• Longevity insurance
• Disability Income
• Long-term Care Insurance
• Investment Insurance
• Medical Insurance
Software would use the “Big Data” concept, discussed above, to help
the applicants configure the right policy for them. Even post-issue, the
policy would remain interactive, enabling the insured to modify cover-ages
at any time. The software itself could proactively monitor the fam-ily’s
risk exposure and suggest changes.
George Hrischenko, FSA, MAAA, VP of SCOR Global Life America
discusses another interesting concept, in his presentation at the Society
of Actuaries 2013 annual meeting. He identifies the potentially “Game
Changing” trend of genetic testing. If regulators ever allow the wide-spread
use of this technology, it could bring major changes in risk analy-sis
and product design.
26. RESCUE • 23
Clearly, some of our future products will be very different from what
we have become accustomed to. They will incorporate many new ideas
and concepts. They will address all of the factors we have discussed, and
they will shift to accommodate our customers’ changing needs. It will be
a very exciting time for those of us involved in new product implemen-tation
and support.
However, one looming question that remains is, are our legacy policy
administration systems up to the challenge? Not likely – we are still
wrestling with the old time-to-market problems discussed in Chapter 1.
But that problem is about to get much worse if we don’t find a remedy
soon. The Spreadsheet Engine is that remedy!
1
27.
28. 1
CHAPTER 3
The Problem
n this chapter we take a closer look at why it is so difficult and
costly to add new products to legacy software. It is not a design
flaw or poorly written systems. Most of these systems are well
I
constructed and robust. And it is not our IT department’s lack of skill
sets. Our IT people should actually get a medal for performing as well as
they do, given the situation they face. There are several dimensions to
this problem that all add up to making it difficult indeed to add products.
First, software designed to run any business must change as the busi-ness
changes. That is true for any back office system. But with life in-surance,
the situation is magnified. Our products are complex financial
instruments that must be tracked for many years. And our software pro-grams
must reflect every twist and turn the financial instrument can
possibly take over its entire lifetime. That is far different from say a
parts inventory system that just needs to record a sale and then forget
about that part.
In addition, we are continually changing our products. And, for life
insurance products, any change has a major impact on the software. We
are not just deciding to carry a different brand of tire, as could be the
case for parts inventory. We are actually changing how the product be-haves
internally in the software.
29. 26 • CHAPTER 3 – THE PROBLEM
Most new products require calculations and features that are not al-ready
supported by our current policy administration software. So, the
software must be modified. This is complex, tedious, time consuming
work. In addition, products that deliver the greatest potential market
impact frequently contain innovative new features. These are the ones
that take the longest to implement.
Change after change, year after year, these programs eventually be-come
1
a jungle of code. Each subsequent product type becomes even
more costly to implement. We become trapped in a jungle of embedded
code.
Don’t get me wrong. We actually have come a long way from the old
punch card days of decades ago. First, mainframes enabled much faster
processing and higher volumes. Then client server came along with so-lutions
that helped reduce costs. This also introduced better data man-agement
and access through relational databases. But we have still not
gotten out of that jungle.
The logic for our product's business rules and values calculations are
still trapped inside a maze of software programs. In addition, many dif-ferent
products all depend on these same programs. This makes the
situation even more complex. If we need to add or make changes to one
product, we know we had better retest the whole system, to make sure
we didn't break something for some other product. That is an excruciat-ing,
expensive restriction we all have had to live by.
We have tried a number of techniques that have helped, but have not
really solved the big problem for introducing new products. I was one of
the founders of Trimark Technologies in the 1990's. We developed the
first client server based life insurance administration system called Tran-scend.
That is the same system Ron, from Chapter 1, used so success-fully.
Back then, the term "client server" was not yet even a recognized
term but Trimark, and many companies in other industries, were trying
to figure out how to do mainframe type work using networked personal
computers.
30. RESCUE • 27
That turned out to be what is now called client server. Not that we
invented client server. The time was just right for that to come about.
Technology had advanced to the point where that architecture was pos-sible.
1
So, to capture the benefits the architecture offered, many solutions
in various industries were developed.
In Transcend, we made heavy use of business user modifiable tables,
outside of the software programs, to enable product features to be
turned on or off. For similar products, we enabled one product to be
"cloned" from another. The business user, to enable a new product,
could then just modify the copied table settings. This helped the situa-tion
in that some product changes could be implemented by just making
changes to tables instead of changing program logic. The "Business
Rules Engines" in use today are a more sophisticated version of that
same concept.
These rules engines are another dramatic improvement but still the
basic fundamental problem remains. As hard as we have tried, we still
have not resolved the issue of IT expense, risk, and forced regression
testing when implementing new products and features.
Our legacy systems contain complex programs that are common to
most products. This is actually good software architecture. By design, if
you need to write a program to perform the calculations for loans, for
example, you only want to write one program that can be called anytime
that calculation is needed. That is the most efficient way to develop
software. That design though actually creates more work later, when
you need to make changes:
• Complexity – The programs are complex; since they handle all
of the twists we already have in place for our existing products.
So, it takes time to analyze where the changes should be made for
the new plan.
31. 28 • CHAPTER 3 – THE PROBLEM
1
• Risk – Since the programs are used for all products, once the new
plan changes are made, all existing products must be retested to
ensure we haven’t accidentally created problems for them.
The traditional steps followed by an IT department to implement a
new product are as follows:
• Analysis - The actuaries and product designers deliver, in the
form of spreadsheets and documents, specifications for the new
product’s business rules and values calculations to the IT depart-ment.
IT experts, familiar with the legacy administration system
software, must analyze these specifications.
• Planning - All existing product calculation logic and business
rules are embedded in large monolithic programs. These complex
programs must be analyzed and a plan created to modify them to
support the new product.
• Specifications – Technical specifications must be created for the
new product implementation, software changes and required
testing.
• Programming - Software changes must be made and tested.
Sample policies must be submitted, including representative fi-nancial
transactions. All values must be checked, with errors cor-rected
and retested.
• Testing - Since the modified programs are used for other prod-ucts
too, the system must be regression tested to ensure every-thing
that used to work still does.
This can entail a great deal of labor and calendar time to accomplish,
and is a major determining factor in the time-to-market of new prod-
32. RESCUE • 29
ucts. Too much of our product’s logic is still trapped inside complex
software programs that are also used by every other product. Because of
this one reason alone, we are stuck with three difficult business prob-lems:
1
• Time-to-Market - It takes far too long to get new products to
market
• Regression Testing - We are forced to retest the whole system
even when making changes for just one product
• Conversion Costs - Converting from older legacy systems to
newer improved ones, or integrating acquired blocks of business,
is extremely expensive, since the system’s programs must still be
modified and tested for all of our products, which have policies in
force.
This problem is not unique to life insurance. But it is much more
acute in life insurance – since we introduce new products so often, they
are so complex, and we must maintain them for up to 100 years. The
problem exists in any industry where there is software that is intended
to help manage a business.
Professor Meir Lehman, head of the Computing Department at Im-perial
College London, spent over 30 years researching this issue. Dur-ing
that time, he was able to formulate what today is called Lehman's
laws of software evolution. He states that software – like our legacy sys-tems
– that map a real world process, must continue to change because
the real world is constantly on flux. In order to remain relevant, and
useful, systems of this type must change as the world does. His laws tell
us all we need to know about why it is so costly to deploy new products
in our legacy systems:
33. 30 • CHAPTER 3 – THE PROBLEM
1
Law of Continuing Change – These systems must be continually adapted to their
real-world environment or they become progressively less satisfactory and less
useful.
Law of Increasing Complexity – As the system evolves, its complexity increases
unless additional work is done to maintain or reduce it.
Law of Conservation of Familiarity - As the system evolves all associated with it,
developers, sales personnel, users, for example, must maintain mastery of its con-tent
and behaviors to achieve satisfactory evolution. Excessive growth diminishes
that mastery. Hence the average incremental growth remains invariant as the
system evolves.
Law of Continuing Growth — The functional content of these systems must be
continually increased to maintain user satisfaction over their lifetime
Law of Declining Quality — The quality of these systems will appear to be de-clining
unless they are rigorously maintained and adapted to operational envi-ronment
changes.
Feedback System — The evolution processes constitute multi-level, multi-loop,
multi-agent feedback systems and must be treated as such to achieve significant
improvement over any reasonable base.
Most of the legacy systems in use today are at least a decade or two
old, and some much older than that. But even the newest ones still have
their product logic embedded in programs. As Lehman’s Laws demon-strate,
continuing to modify the complex product support programs in
these systems to accommodate new products increases their complexity
and cost.
This problem is precisely what the Spreadsheet Engine concept ad-dresses.
Much like the early days of client server, there is a new architec-ture
that is now possible, due to advances in technology. Spreadsheets
are now safe to use in mission critical operations. This approach enables
a powerful new paradigm for life insurance back office policy admini-stration.
This is the way to stop depending on our legacy systems for
policy values and truly escape the legacy software jungle.
34. 1
CHAPTER 4
The Solution
hen designing your products, do you limit features to
minimize the impact on your legacy system? That is a
common practice – to avoid situations like Ron’s in
W
Chapter 1 – where time frames get so out of line. But what if there were
no limits? What if any feature is OK? In fact, what if you could deploy
the most radical of new products without even bothering your IT de-partment
for changes policy values programs? That is the promise of the
Spreadsheet Engine.
Sure, if the product is so radical it needs new input fields on screens
or in the database, IT would need to do some software work. And IT
must still enforce controls, enable acceptance testing and other impor-tant
steps. But that is all minor compared to cracking open those com-plex
policy values programs and massaging the embedded code. With
the Spreadsheet Engine, that embedded code is not even used. It is in
spreadsheets instead. Just think about the possibilities this enables.
On Feb. 27, 2009, the Society of Actuaries (SoA) released “Blue
Ocean Strategies in Technology for Business Acquisition by the Life In-surance
Industry”. A “Blue Ocean Strategy” is a concept whereby compa-nies
can succeed not by battling competitors, but rather by creating "blue
oceans" of uncontested market space. This Delphi study (a structured
interactive forecasting technique) gathered opinions, from 43 experts,
35. 32 • CHAPTER 4 – THE SOLUTION
about possible “Blue Ocean Strategies” for the life insurance industry.
One possibility, held by several experts from round one was:
1
“Quantum leap in time to market” – Business Process Management (BPM) soft-ware
will support rapid installation of product variations. This would allow
products to be rapidly configured (without special coding) to different markets
and a wide range of policyholder options. Recognizing that state regulation will
sometimes remain a speed bump in the process, the strategy will nonetheless pay
off handsomely in many cases.
Enabling products to be “rapidly configured without special coding”
is precisely what the Spreadsheet Engine accomplishes. By the final Del-phi
round, the majority of the experts did not believe that reducing
“Time to market” was strictly a technological problem and that other
factors were also important. It is true, time to market does involve much
more than technology. But technology is, by far, the biggest obstacle
today.
In a 2007 presentation entitled “The Need for Speed”, Van Beach
from Towers Perrin, sited results from surveys conducted by the Dia-mandGroup,
Deloitte, LIMRA, and the SoA, among others. In the pres-entation,
he listed the top five of what he called “Snail Makers” in time-to-
market. Ignoring the ones that would be considered just poor man-agement,
we are left with these three:
• State filings
• IT and Actuarial systems
• Actuarial/IT Handoff
Since his presentation, the Interstate Insurance Product Regulation
Commission (IIPRC) has taken a lot of the pain (and time) out of the
filing process – providing a central point of electronic filing for insur-ance
products. And our Spreadsheet Engine will dramatically reduce, or
even remove, the other two as issues. As of this writing, 44 states have
joined the IIPRC, with two more pending. According to the 2012 IIPRC
36. RESCUE • 33
annual report, the average filing review time was 23 business days, ex-cluding
1
company response time for rejection letters. Participating mem-ber
companies include 167 carriers representing 75% of the asset-based
premium volume nationwide. This is rapidly becoming the standard
method for state filings – enabling the time required to be short and
predictable.
Our Spreadsheet Engine will do the same for the other two items on
Van’s list – IT systems and Actuarial/IT Handoff. The time required for
these will also become short and predictable.
So, how much time are we talking about saving for IT systems and
actuarial handoff, as part of the product development process? You may
have a good feel for that in your company. But, here are some industry
numbers that give us a general idea of what to expect with the Spread-sheet
Engine.
A comprehensive 2007 LIMRA "Product Development Process
Study" produced some revealing results:
On average, companies introduced three new products, revised three products,
and changed the rates on two in the year leading up to the study.
That is a total of eight product development efforts undertaken over
the course of a single year. And some companies had even more than
that – as much as double. New product projects consume the most re-sources
and time. But even revisions and rate changes can require pro-gram
changes. It all adds up to a huge allocation of time and resources.
The LIMRA study analyzed the order and length of each step in the
development process, including total calendar time required to take each
new product type to completion:
• Term Insurance – 10 Months
• UL/Whole Life – 12 Months
• Variable Life – 12 Months +
37. 34 • CHAPTER 4 – THE SOLUTION
Here are (see figure 3) some more detailed study results for the average
UL or Whole Life new product steps:
Figure 3
1
Source – 2007 LIMRA Product Development Process Study
As you would expect, there is a lot of work going on at the same
time, with many steps overlapping. Updating IT systems takes the long-est.
That time is divided between Day1 (what a company needs to have
in place before the product is released) and Day 2 (all remaining IT
work).
Often, we are forced to shift as much IT work as possible to day 2 in
order to shorten time-to-market. This can require limiting plan features
for duration one – such as no loans until policy year two. Since the
Spreadsheet Engine eliminates – normally all – legacy software changes,
that limitation is removed. All product features are available at the time
of product launch.
38. RESCUE • 35
1
Most of the 43 weeks in the above illustration for IT work is elimi-nated.
There may still be some time required for new input fields, data-base
fields, process control or acceptance testing. But that is a small part
of those 43 weeks. The calculation logic, policy values, and rates for any
given product are totally independent from all other products and lives
in a spreadsheet. This eliminates most of the current IT cost and delays
for any new product.
There is work to be done, to create the Spreadsheet Engine. But once
you embrace it, the business benefits are astounding. Once this solution
is in place, there is no need to modify existing policy values programs
when deploying new products. So, that time and cost component disap-pears.
Let’s take a closer look at how the Spreadsheet Engine works.
39. 36 • CHAPTER 4 – THE SOLUTION
Figure 4
Figure 4 is a simplified diagram of the Spreadsheet Engine informa-tion
flow. The Spreadsheet Engine coordinates all of the policy related
transactions between your legacy system and the product spreadsheets.
Please notice that each policy has its own spreadsheet, which is a copy of
its product spreadsheet. The flow of information works as follows:
1
• Legacy System –Your legacy system is modified so that, anytime
it is ready to process a transaction that will affect policy values for
a new product, it passes that transaction to the Spreadsheet En-gine
instead. Updated values are returned from the Spreadsheet
Engine after the calculations are performed. The updated values
are then stored in the legacy system database – the same as now.
Note: All policy values, and cumulative transactions, are also re-tained
inside that policy’s spreadsheet.
• API – This is the Application Program Interface (API) between
your legacy system and the Spreadsheet Engine. The engine op-erates
as a web service. There is a comprehensive set of messages
defined that enable creation, update, and query of all policy
spreadsheets throughout the life of the policy.
• Spreadsheet Engine – The engine is always ready to receive mes-sages
requesting some policy operation. After validating any in-coming
messages, it passes the request to the appropriate policy
spreadsheet.
• Policy Spreadsheet – This spreadsheet contains all of the infor-mation
required to process any financial transaction against its
policy. It stores all transactions from beginning to date. Its pur-pose
is to store any new incoming transactions, within its cumu-lative
tables, revalue the policy based on current data, and send
40. RESCUE • 37
1
those values back to the engine – and then back to the legacy sys-tem.
• Product Spreadsheet Template – Anytime a new product is de-ployed,
a product spreadsheet template is created to represent
that plan of insurance. This is a specialized version of the pricing
spreadsheet your actuary already creates. It contains all of the
formulas, business rules, rates and values required for valuing any
policy for that plan, including any allowable riders.
When an application is submitted for a policy with this plan,
through the engine, a copy of this spreadsheet is made. This copy
then becomes that application’s policy spreadsheet. It will then be
used to track all of the values for the policy from that date for-ward.
This is a simplified version of what actually takes place during proc-essing.
However, these are the major steps that constitute the flow of
information with this new concept. I hope you can begin to see some of
the advantages of this approach. We are successfully removing all prod-uct
specific logic from the legacy system and embedding it in independ-ent
spreadsheets that perform all values processing for each policy.
The work required to get new products from idea to production is
dramatically shortened. The time required to model and price the new
product in Microsoft Excel is increased a bit, since that step now con-tains
more work. This is no longer just a model. It is now the “program”
that supports the new product in production. So, it must be thoroughly
tested and validated for every possible policy scenario. Once that is ac-complished
though, the new product is production ready.
We do the same for business rules. Non-technical product experts
can easily define any required business rules in spreadsheets, which can
be integrated with the Spreadsheet Engine.
41. 38 • CHAPTER 4 – THE SOLUTION
This also applies to output document generation. Non-technical
document experts can easily define all output documents in either
spreadsheets or Word files. This also can be integrated with the Spread-sheet
1
Engine to relieve your legacy system of that responsibility. If your
output documents are generated by an enterprise document solution
that accepts extracts, then those extracts can still be generated by a
spreadsheet.
Figure 5
The whole idea (see figure 5) – and biggest reason for productivity
improvement – is that we are taking what is currently some very techni-cal
tasks and making them non-technical. We are enabling the people
who are already the experts in these areas to have direct communication
42. RESCUE • 39
with the legacy system in a language they already understand. And we
enable work that is already being done, such as the pricing spreadsheet,
to provide even greater business value through reuse.
Spreadsheets are probably already a powerful tool in your business.
How many people have spreadsheets skills versus programming skills in
Visual Basic, C or other languages? There is potential for tremendous
productivity improvement.
The Spreadsheet Engine also makes some other things possible that
may not be apparent at first glance. The following chapter goes into
more detail regarding the specific benefits, but I want to point out a
couple of very interesting possibilities. Keep these in mind for future
planning purposes. They may provide helpful options at some point.
Recall, in the discussion above, that all transactions affecting policy
values, from inception, are stored in the policy spreadsheet. In addition,
all product logic required for calculating the policy’s values is also stored
there, along with all current and historical values. This means that all
policy financial values, which are usually stored in the policy database,
can be retrieved directly from the policy spreadsheet when needed. This
could potentially repurpose the policy database.
The policy spreadsheet can always be queried for all policy values.
The only need for those values to be in the policy database at all is for
reporting. This means that only generic policy reporting information
needs to be stored there. All of the transaction detail, and any special
values unique to special plans, can just remain in the spreadsheet only.
That is not a requirement of the Spreadsheet Engine. And it may not be
helpful for you now, but it does give you a great deal of flexibility and
options for the future.
The second item I want to point out has to do with the value of what
remains of your legacy system, now that we have removed the product
logic.
The reason policy administration systems are so expensive to pur-chase
1
is because they are created for a complex business in a very small
vertical market. Of course, life insurance is not a small business, but
43. 40 • CHAPTER 4 – THE SOLUTION
there are less than 1000 companies in the U. S. Even if a software vendor
captured 10% of that market it would only represent 100 customers –
not many customers considering the high development costs. By com-parison,
1
the development costs for Microsoft Office is actually many
times higher but, because there are literally billions of customers in a
huge horizontal market, the purchase price is very small.
The reason I bring this up is that the complex part of any policy ad-ministration
system is the product support features. Now that we have
moved that support to the Spreadsheet Engine, what is left becomes very
generic. Any software created to manage a customer service business can
perform those functions. Now, for future legacy system replacements,
there are much less expensive, and more comprehensive options. We
will cover both of these topics in more detail in later chapters.
44. 1
CHAPTER 5
Business Benefits
ust imagine all of the benefits that accrue from having the logic
for each product completely independent from all other products.
In addition, with actuaries creating that logic in Excel spread-sheets,
even more benefits are enabled. With the Spreadsheet Engine, all
J
product calculations and business rules are now completely outside of
the legacy system and exist only in spreadsheets, created specifically for
each product. When a new product is added or an existing one is modi-fied,
only that product’s spreadsheet is changed. No program changes are
required, and no other products are affected in any way. There are many
advantages to this approach, for both your business users and your IT
department.
This new paradigm in product support enables your business to im-prove
the product development processes using a combination of new
technologies, and process improvements:
More Product Features
With the Spreadsheet Engine, all data and logic for a given policy are
now contained in a single Excel spreadsheet. This means product fea-tures
are enabled at the product level, or even policy level for excep-tional
cases, by just changing a spreadsheet.
45. 42 • CHAPTER 5 – BUSINESS BENEFITS
In addition, you never have to perform the analysis, which is cur-rently
required of your legacy system, to figure out how you are going to
support all of the unique features of the new product. Now, no features
are off limits. There will, no doubt, be some wonderful new product
ideas to address the current life insurance business challenges. The
Spreadsheet Engine enables a quick response to that challenge, whatever
the new product’s features may be.
Shorter Time to Market
You can now get products to market faster than your peers that con-tinue
1
to rely on the traditional legacy system approach. The built-in
delay for the normal IT legacy software change process is minimized.
Your actuaries, or product designers, create the spreadsheet template
for each new product. It can then be tested independently from your
legacy system. The normal requirements for your IT department to un-derstand
the product specifications, analyze your legacy system’s product
calculation programs, make the required modifications, and regression
test the entire system is totally eliminated.
Even the traditional rate files that accompany new products are
eliminated. All rates and values, including variable values such as current
interest rates, are coded directly into the product spreadsheet template.
If the value of current rates and other variable information changes after
production deployment, those changes are keyed directly into the prod-uct
spreadsheet. Those changes are then automatically propagated into
the policy spreadsheet of each inforce policy for that product.
Another big time saving is in the area of policy related documents
and correspondence. All values for each policy are resident in its respec-tive
policy spreadsheet. So, they are easily accessible as a source for
document variables. There are techniques in the engine that enable easy
extraction of those values for use in Microsoft Word merge operations
or as XML data to be sent to an enterprise output document solution.
This too can be defined and tested independently of your legacy system.
46. RESCUE • 43
Reduced Cost
This helps drive down product development costs since the tradi-tional
1
IT timeline is dramatically shortened and labor is reduced.
Granted, there is some additional cost in that your actuaries and product
designers are now creating the spreadsheet templates. But that is much
more than offset by the fact that your legacy system's program changes
and regression testing are no longer required.
Product spreadsheets, for documentation purposes and actuarial
analysis, are probably already created anyway. These are normally re-quired
when products are introduced. The product spreadsheets re-quired
by the engine are very similar to those. For the engine, there is
some predefined data structures required, and they are probably more
comprehensive than what is needed today. But it is still much less labor,
in total, than currently required.
Product Visibility (Transparency)
This also enables much easier access to the rules and content of the
product itself. Product logic, along with the policy data, is always
viewable, by anyone who understands Excel. It is no longer embedded in
computer programs or databases.
You may have already had this experience; after a product is de-ployed,
someone may have a question about the precision of a calcula-tion
or the order of operations used. Also, there may be questions
regarding a particular business rule. All of this information is readily
accessible, both at the product level and policy level, just by viewing the
associated spreadsheet. You will no longer need to have a programmer
or technician look at the software programs to answer those questions.
Production spreadsheets are locked and secure. So, they cannot be modi-fied,
except by those with proper security.
This same benefit applies to documents. If you use the policy spread-sheets
as the source for output document and correspondence variable
47. 44 • CHAPTER 5 – BUSINESS BENEFITS
values, anyone with questions as to where the value comes from, or how
the value is derived, can just view the spreadsheet.
All transactions are available for display in your legacy system,
through the engine's API. But all transactions and all associated inter-mediate
1
values are also stored in the policy spreadsheet, from policy in-ception
forward. This provides a great opportunity for anyone trying to
research a particular policy issue. They can view the policy spreadsheet
and analyze any desired data, intermediate values, and calculation logic.
This enables them to readily trace any specific value for which there is a
question.
Improved Product Quality
The Spreadsheet Engine concept puts the product development
pieces into the hands of the most qualified people for that responsibility,
your actuaries and product designers. This improves product quality
since all product logic and calculations are developed and tested directly
by the product expert. There is no need to interpret product specifica-tions
into procedural programming code – and no actuarial/IT handoff.
Also, recall that the spreadsheet is independent of the legacy system.
So, it can be easily tested using a wide range of input data. All permuta-tions
and combinations of expected application and transaction values
can be quickly generated and used to test the spreadsheet. There is no
need to exercise the legacy system code. Just repeated execution of the
spreadsheet with a list of all of the input test variables will exercise and
validate the logic.
Better Accuracy
You now have better pricing accuracy and values accuracy since the
actuary has complete control over calculation precision and order of
operations in each transaction for a new product. Any issues that due
occur can be readily rectified directly by the product expert.
48. RESCUE • 45
More Agile
You can now respond faster to customer needs and changing market
conditions like population demographics, pension reforms, and new
technology. These all drive the need for new life insurance product
types, and the product limitations of your legacy system are no longer an
issue.
Any "exceptions" needed for a new product or new features envi-sioned
1
can just be embedded into the product spreadsheet. No changes
to your legacy system are required. Even if those new feature require
new data, which would normally mean adding new fields to your policy
database, that too can just be embedded in the policy spreadsheet. It can
always be accessed from there.
Product Independence
You now have much easier product life cycle management, since all
product logic is embedded in that product's spreadsheet. When an in-force
block of business is run off or sold, that product’s spreadsheet and
all policy spreadsheets can just be removed or archived. There is no need
to modify your legacy system code.
Product of One
This is one benefit that has the potential to make an exciting differ-ence
in your marketing. Most of the other benefits are related to cost
reductions and efficiencies. But this one could be a killer opportunity,
depending on your situation.
It now becomes possible to create unique policies. This makes a lot of
sense in certain high-end type sales situations. The work now involved
in creating a new product, that is some twist on an existing product or
even a completely new product, requires no legacy software changes. So,
deploying a single policy product in an exceptional sales situation is very
doable.
49. 46 • CHAPTER 5 – BUSINESS BENEFITS
Attract More Agents
During 2007, the Society of Actuaries published a series of articles
entitled, “A Strategic Analysis of the U.S. Life Insurance Industry”. One
of the items identified in the analysis is the power of agents:
1
Due to the trend toward independent agents and fewer agents overall, the bar-gaining
power of agents is increasing. With the impending retirement of large
numbers of agents, the power of agents is likely to be even greater in the future.
They go on to state that two of the things agents’ value most is cus-tomized
products, and a greater role in product design. The Spreadsheet
Engine gives you the flexibility to deliver both. You can introduce more
products faster – with unlimited features and at a much lower cost. This
delivers a serious competitive advantage in the battle for agents. Accord-ing
to LIMRA statistics, independent producers are contracting with
fewer companies.
In 2004, producers sold business with an average of 13 companies; in 2008, it
dropped to ten.
So, competition is increasing. In addition, a 2008 LIMRA study of
producers entitled “What Producers Value from Companies and Inde-pendent
Intermediaries” shows that product/pricing is by far the biggest
reason producers switch carriers for brokered business:
48% identified product/pricing as the reason for changing carriers for brokered
business.
The Spreadsheet Engine is a great weapon to have in the battle to at-tract
and retain independent agents.
Simplified Policy Conversion
It is now much easier for you to convert blocks of business, either in-ternal
policies or business acquired externally, onto your legacy system.
50. RESCUE • 47
No program changes or regression testing are required to introduce ad-ditional
1
blocks of business. This also means lower acquisition costs and
operating costs for acquired blocks.
The same benefits that enable you to deploy new products quickly
also enable the integration of existing blocks of business. Whether you
need to integrate acquired blocks or merge multiple internal legacy sys-tems,
the engine makes the task much easier.
Also, when merging legacy systems or converting to a newer one,
you can convert just one plan at a time. There would be no need to mass
convert everything in a concentrated time frame. You could even make
it a point-in-time conversion where you establish the policy spreadsheet
with current values and just track from that point forward. That would
eliminate problems with history data that may not be available.
Better SOX Regulatory Compliance
The new architecture helps address the requirement for role segrega-tion.
For this regulation, IT people who support production and have
that level of access cannot be the same people who modify or develop
the software. This has caused some companies to increase IT staff.
The Spreadsheet Engine redistributes the workload – new product
development is now external to IT. So, there is natural role segregation.
Less Risk
I have seen it happen many times – and you probably have too. A
new product goes into production and suddenly policy data for other
products develop issues. You have to quickly fix the data – in crisis mode
– and possibly even contact policyholders to explain what happened.
This is the risk introduced due to all products depending on the same
policy values calculations programs. Sometimes, no matter how well we
do regression testing, errors sneak through.
The Spreadsheet Engine eliminates this risk. New products cannot
affect the values calculations of other products. Regression testing is not
even required.
51.
52. 1
CHAPTER 6
IT Benefits
ome of the largest obstacles to your IT department’s progress
have now been removed. Legacy system modernization and
product development have historically been items high on
S
their to-do list. New products are a requirement of doing business. So,
they have competed with all of the other priority one issues for re-sources.
The Spreadsheet Engine changes that dynamic.
Straight through processing (STP), e-App, e-Signature, automated
underwriting, field technology, social media and mobility are just a few
technology platform issues that could bring great business value. So of-ten,
these are the things that must take a back seat to the next new prod-uct
introduction or legacy system upgrade – due to limited resources.
That time is now freed up to concentrate on these other very important
items that enable technology modernization and integration. Maybe
they will have time now to do these.
I have been implementing life insurance products for decades. And I
don’t know one programmer who thinks it is fun to play around with
those old legacy system policy values programs. They do it because it
needs to be done. But they can now add much more value and focus on
the important technology platform issues above. In addition, there are a
few other benefits that may not be apparent:
53. 50 • CHAPTER 6 – IT BENEFITS
No Regression Testing
Normally, when a product feature is modified, such as changes to a
loan calculation, you need to retest all products that offer loans. This
only makes sense, since a change to one product could impact the logic
for another. But since no programs or other product logic is changed
when introducing new products using the Spreadsheet Engine, system
regression testing is not required. No costly or time consuming testing
process, beyond testing just the new product spreadsheet, is needed.
Now that each product operates independently, through its own
spreadsheet, a new product being introduced, or a change to an existing
product has no affect on any other product. All testing and validation
can be focused on just the modified spreadsheet. That is a far simpler
process than regression testing the entire system.
In addition, the testing can all be performed outside of the legacy sys-tem.
1
The product spreadsheet can be tested stand-alone. This greatly
simplifies the testing process. All permutations and combinations of ex-pected
transactions and policy values could be quickly generated in a
spreadsheet. Then they can be quickly processed through the new prod-uct
spreadsheet to validate the product.
No Database Required
I know this seems a little far-fetched, or even silly, but please bear
with me here for a moment. All policy business rules, rates, calculations,
transaction history and values are now encapsulated in spreadsheets. All
access to those values can now use those spreadsheets instead of your
current policy database. So, there is no longer a need for the database
when processing transactions and viewing policy values.
You, no doubt, have many functions that use the database today. But
for future planning purposes, you now have more options. You can be-gin
to depend less on the database and more on the spreadsheets for pol-icy
values. You may need to retain the database for reporting and
enterprise data purposes but it only needs to contain information that is
54. RESCUE • 51
used for reporting. The policy database can become much less complex –
containing only generic policy data.
Any unique data, that is only stored for certain products can just be
kept in the spreadsheets only. At the very least, this could eliminate
having to add new fields to the policy database for some unique product.
Real-time
Your current policy administration system may already process
transaction immediately – as soon as they are entered. But if you still
depend on a nightly cycle for updated policy values, you now have real-time
1
values. The Spreadsheet Engine executes all policy transaction in
real time.
Scalable Web Services
All functions can be implemented as web services, based on horizon-tally
scalable cloud architecture. The Spreadsheet Engine solution can
then be deployed on either the Microsoft Azure cloud service or on your
own in-house hardware.
What this means in practical terms is that, as your transaction vol-ume
increases, there will be no bottlenecks that develop that require
software changes. The only changes required to support increased vol-umes
are additional hardware resources.
Service Oriented Architecture
All transactions can be executed through a simple message API. And
those transactions can originate from anywhere. So, any function, ei-ther
internal or external, can have ready access to current policy values.
In addition, policy related transactions could originate from anywhere.
This may be useful for a number of things. For example, if you want
to make policy data more available to agents or your policyholders, this
is a possible solution. In addition, policyholders could potentially even
enter policy transactions, such as premium payments or loan requests.
55. 52 • CHAPTER 6 – IT BENEFITS
Industry Standard Technology
The Spreadsheet Engine is 100% Microsoft standard. The compo-nents
consist of Microsoft SharePoint, Office 2013, and .NET.
The engine is a SharePoint web app that can be used either directly
through the Microsoft Azure cloud service or downloaded to an internal
SharePoint installation.
Complete Change and Transaction History
Every piece of data entered, every piece of logic changed, and every
value calculated is saved permanently in the policy spreadsheet to sup-port
1
security, compliance and SOX.
Keep Your Legacy System
This could potentially add new life to your current legacy system, and
delay the expense of upgrading to a newer one. Now that the product
logic is removed, new product implementations do not impact it. So,
there will be much less “churning” of the embedded code. You may have
other reason to want to upgrade, like updating the technology, but time
to market for new products will no longer depend on program changes.
Fewer Skills Required
Lack of skilled programmers that understand life insurance, your leg-acy
system, and your business is always a problem. Now that the respon-sibility
for product values has been transferred to your product experts,
and out of your IT department, that problem is greatly alleviated. The
requirement to have technical people on staff that understands the com-plex
programs that supported product functions in your legacy system
no longer exists for new products.
56. RESCUE • 53
Security
The Spreadsheet Engine is deployed as a SharePoint application. So,
all of the SharePoint platform features are available. If you already use
SharePoint for document control, this may not be anything new for you.
But SharePoint provides a repository with compliance features for stor-ing
SOX control documents.
This includes an integrated security model with Active Directory
that is configurable down to the document level. This enables granular
control of documents, which can secure data and documents from acci-dental
changes and provides a rich audit control.
Also, SharePoint provides deep version control that tracks the date
and time users alter documents or data, including capturing the original
content for reuse or complete restoration.
1
57.
58. 1
CHAPTER 7
Mission Critical Spreadsheets
ou may not be accustomed to hearing about spreadsheets
being used as a part of mission critical software, like I am
proposing. You also may have questions about whether it is
Y
even possible to use a spreadsheet to support life insurance policy values,
inception to date. So, I want to discuss those two topics a little further.
There are obvious advantages to using spreadsheets. However, you may
have questions or thoughts about potential disadvantages too.
Spreadsheets are extraordinarily powerful tools that enable users to
analyze and manipulate data efficiently. They have become ubiquitous in
business, and can provide instant, concise information often driving
critical business decisions. In fact, they are already the most common
method of communicating the calculation specifications for new life in-surance
products.
We are not really breaking new ground here though. Because,
spreadsheets have been used in mission critical situations in business for
years. One industry that may be even more calculation intensive than
life insurance is capital markets. Their products and services often re-quire
real-time valuation of very complex algorithms. And they depend
heavily on spreadsheets to satisfy that need.
59. 56 • CHAPTER 7 – MISSION CRITICAL SPREADSHEETS
In a 2009 survey and report entitled "Spreadsheets and Capital Mar-kets",
the Tabb Group received 65 survey responses from brokerage
houses, hedge funds, and banks. In the answers to the question "How
many business critical spreadsheets exist in your organization?" they
found that:
1
“The number of spreadsheets that are essential for day to day operations is often
in the thousands”
37% of respondents reported more than 1000 spreadsheets and only
35% of respondents reported less than 250. Capital markets were an
early adopter of the spreadsheet paradigm. And that commitment is still
strengthening. 61% of respondents either already have or were consider-ing
running the server version of Excel on high performance clusters of
computers, enabling even faster execution.
Microsoft Excel is a programming language, just like any other. And
any spreadsheet program can be scaled, controlled, and run in a secure
environment, just like other mission critical software. This was demon-strated
quite clearly in an important empirical study conducted by a
group of research scientists in San Francisco.
Professors Thomas A. Grossman of the University of San Francisco,
Vijay Mehrota and Ozgur Ozluk, both of San Francisco State University,
studied spreadsheet use in mission critical situations. The results enti-tled,
"Lessons from Mission-Critical Spreadsheets", were published in
"Communications of the Association for Information Sciences: Vol 20,
Article 60. They performed detailed case studies of eighteen businesses,
across a wide range of industries including financial services, heavy in-dustry,
and high-tech. The major findings from the study are:
1. Spreadsheets are widely used for mission-critical functions
2. Spreadsheets are an effective application development platform
3. There is diversity of development skill in creators of mission-critical
spreadsheets
60. RESCUE • 57
1
4. Sophisticated programmers sometimes choose spreadsheets over other
languages
5. Spreadsheets are amenable to formal development practices, but such
practices seem rare
6. Spreadsheets play a central role in the evolution of business processes
and work systems
7. Spreadsheets are a source of “accidental legacy systems
Spreadsheets entered the business world years ago as a personal pro-ductivity
tool on the desktop. And some people are accustomed to
thinking of them only in those terms. But that is no longer the case.
However, they can also represent great risk. As pointed out in item 5
above, many businesses do not exercise proper control over spread-sheets.
Many spreadsheets are uncontrolled, stand-alone applications
that employees can change and, sometimes, introduce critical errors in
data or formulas. This can have serious consequences. For example: An
internal error in a spreadsheet led the University of Toledo officials in
Ohio to miscalculate the upcoming years available funding by $2.4 mil-lion.
There are hundreds of other examples of just that type of problem.
Because of their ease of use, spreadsheets are often created without
formal requirements and outside of the normal IT development and
testing process. In fact, until recently, there has been a lack of a formal
infrastructure to enable control of spreadsheets in the normal IT source
code control sense.
The Spreadsheet Engine, of course, provides mission critical support
for life insurance policy administration. So, comprehensive spreadsheet
control is required. If you don’t already have something in place to en-able
this control, it can be provided through the Microsoft operating
platform.
I propose the Spreadsheet Engine be created as a standard Microsoft
SharePoint application. SharePoint, with its Excel Server component,
offers many advantages, which will be covered in later chapters. But one
61. 58 • CHAPTER 7 – MISSION CRITICAL SPREADSHEETS
of them is that it provides all of the needed control and management
features for production deployment of spreadsheets. As explained on the
Microsoft Website:
1
• Syntax and Error Checking - The "Spreadsheet Inquire" feature
enables diagnostics, error checking, and optimization, for mis-sion
critical spreadsheets, without specialized expertise. The tool
can analyze workbooks, cells, and cell dependencies. Over 40 di-agnostics
are included such as formula errors, inconsistent for-mulas,
invisible cells, hidden rows and columns, very hidden
worksheets (hidden by macros), formulas referencing hidden or
blank cells, formulas returning text, duplicate formulas, cells with
conditional formatting or validation logic, warnings, and more.
• Workbook Relationship Diagram - This feature maps the data
lineage of a given Excel workbook. If there are linked workbooks
or data connections, you can see where the data is coming from,
whether you have broken links, and whether the data is current.
• Track Changes - The Audit and Control Management (ACM)
Server provides change management features for Excel files. This
enables tracking of changes in all mission critical spreadsheets.
You have the ability to see "who, what, where, and when" for all
changes in spreadsheets down at the cell level. You can see if
someone has modified formulas or VBA code, and you can see
the old value and the new value after the change.
• Compare - Finding differences between two versions of the same
code is a fundamental requirement for managing any source li-brary.
So, ACM Server also keeps the revision history for Excel
files. You can compare any 2 versions, or restore a prior version.
This compare includes formulas, errors, calculated values, links,
data connections, structural changes, formatting, and names. In
62. RESCUE • 59
1
addition, this feature automatically detects when rows and/or
columns have been inserted or deleted and realigns rows for
more efficient comparisons, and also enables line-by-line com-parisons
of embedded macros and VBA code.
• Audit and Risk Management - Microsoft Office Discovery and
Risk Assessment Server automates the ongoing discovery, inven-tory
and risk assessment for mission critical spreadsheets while
enabling audit-ability and better control. This helps reduce the
risk of material errors, while preventing fraud and non-compliance.
• Version Control – SharePoint provides the version control, se-curity,
and collaboration required to enable your product experts
to create and maintain the product spreadsheets for the engine.
In the early days of software, these same problems were encountered
with traditional programs. There was very little control of the source
code. So, facilities like the ones above were developed for software pro-grams
and have been used for many years to ensure stable, controllable,
deployment of software. SharePoint’s spreadsheet control features en-able
those same benefits for the Spreadsheet Engine. You can be confi-dent
that spreadsheets can be safely used in our mission critical engine.
OK, so we know spreadsheets can be controlled and safely used, but
will they actually work for maintaining policy values? Well, I know they
can because my partners and I have actually done it on several occasions.
The first time was over a decade ago.
The company I cofounded, Trimark Technologies, which I discussed
in the introduction, was purchased in 1999 by PeopleSoft. One of the
conditions of the sale was to rewrite our policy administration system,
Transcend, using their proprietary language called PeopleTools. After
analysis, we discovered that PeopleTools was not robust enough to han-dle
the complex life insurance product values calculations. So, we pro-
63. 60 • CHAPTER 7 – MISSION CRITICAL SPREADSHEETS
posed that we perform the generic business logic in PeopleTools but all
product logic in spreadsheets – very similar to the Spreadsheet Engine
concept. We accomplished the rewrite and the solution passed all re-quired
1
PeopleSoft acceptance and stress testing. Not long after that,
PeopleSoft began having financial issues. They decided to exit all of their
vertical markets and focus more on their core horizontal market of hu-man
resources software. So, that solution is no longer available.
Since that time, there have been several occasions where my partners
and I have utilized spreadsheets in mission critical situations supporting
policy values calculations. We have supported products of all types
through spreadsheets including, variable annuities, universal life, and
whole life. It is an exciting way to perform product support. Spread-sheets
work very well indeed for managing policy values, and they are
much simpler than embedded code.
64. 1
CHAPTER 8
SharePoint
ou may already be familiar with Microsoft SharePoint and
why it makes sense to use it with the Spreadsheet Engine.
So, feel free to skip this chapter if you are. SharePoint is a
Y
very useful and popular product. Microsoft claims that SharePoint is the
fastest growing product in company history. According to Jared Spataro,
Director of SharePoint product management:
Microsoft has been adding 20,000 SharePoint users per day, every day for the last
five years
That is an astounding adoption rate and due, of course, to the com-bination
of benefits versus cost. It solves some major problems that al-most
every business has, and it can run either in-house on your own
computer hardware or in the “Cloud” using Microsoft’s Office 365 serv-ice.
There are many reasons to use this software in your business. Instead
of offering a specific business solution, SharePoint is comprised of a long
list of features. Each feature adds business value stand-alone. These are
all integrated with each other to deliver much more benefit than the
sum of the parts. As many SharePoint experts point out, SharePoint can
65. 62 • CHAPTER 8 – SHAREPOINT
be the glue that holds your business together, delivering increased effi-ciency
1
and lower costs.
I have no affiliation with Microsoft, but I do see the advantages this
product delivers. The feature list is not only integrated to deliver more
value, non-technical people, with proper training of course, can use all
the features.
For the Spreadsheet Engine, here are the features that make Share-
Point a good choice:
• First, it enables some spreadsheet specific controls required for
production use of spreadsheets, as we discussed in Chapter 7.
These are:
! Syntax and Error Checking
! Workbook Relationship Diagram
! Compare
! Audit and Risk Management
• Second, and this applies to all documents in addition to spread-sheets:
! Document Archive – All documents and spreadsheets are lo-cated
in a single document archive. This enables much easier
management, audit control, and security.
! Version Control – As a document or spreadsheet is created
and evolves through various revisions, SharePoint maintains a
version history.
When a person needs to make a change to the document,
SharePoint enables them to “check out” the document and
then do a “check in” once the changes are completed. During
check out time, nobody else can make changes. They can take
the document out for viewing only.
66. RESCUE • 63
1
Multiple people can still look at the document, but changes are
frozen until the document is checked back in. Also, anyone
looking at the document can readily tell whom has it checked
out, and it is easy to revert back to an earlier version, if
needed.
• Collaboration – This enables a team of people, as would
probably be the case with the product spreadsheets, to work
together on the same document. In addition to the version
control above, access to the document is enabled from any lo-cation
with access to your intranet. People can just as easily
work on the documents from home or while travelling, as they
can at work.
• Spreadsheet Server – SharePoint utilizes a version of Excel
that runs on a server instead of a local workstation. This pro-vides
stability and speed of execution. SharePoint’s spreadsheet
server is specifically designed for speed of execution and ro-bustness.
• Development Platform – Microsoft’s .net framework devel-opment
platform is integrated with SharePoint. This means
that .net programs have access to all of the SharePoint fea-tures.
Using .net, we can automate the execution of spread-sheets
from the document archive for maintaining policy
values.
! SQL Server – Microsoft’s relational database product is also
integrated with SharePoint. So, any data we need to store in
related form can be readily accomplished.
67. 64 • CHAPTER 8 – SHAREPOINT
1
! Security – The entire SharePoint platform provides robust se-curity
at every level. This enables our spreadsheets to be pro-tected
from both accidental and malicious changes.
There are many other integrated features too embedded within
SharePoint that can benefit your business. There are features like, cal-endaring,
email, project management, web site development, business
intelligence, enterprise search, and business integration (see figure 6).
If we use SharePoint for the Spreadsheet Engine, you may also be
able to make use of some of these other features.
Figure 6
68. 1
CHAPTER 9
A New Customer Centric System
mentioned back in Chapter 1 that I would be discussing some
options for replacing your current policy administration system.
I want to make clear that this is not required for using the
I
Spreadsheet Engine. It will work with any policy administration system
– your current one or any new one. However, there are some possibili-ties
that I would like to make you aware of for your future planning.
Now that we have the Spreadsheet Engine, all of the functionality
that remains in your existing policy administration system – other than
any underwriting functions – is generic business functionality, which
has nothing to do with life insurance. This can now be replaced – even
the underwriting piece – with new innovative software that is customer
centric, much less expensive to purchase, and has a lower cost of owner-ship
than any policy administration system.
Policy administration systems are developed for a vertical market;
life insurance companies only. Horizontal market software on the other
hand, like Microsoft SharePoint or Office, can be sold to any business,
which is potentially millions of customers. Microsoft has spent billions
developing Office but an individual license is less than 200 dollars. Ac-cording
to Steve Clayton, editor of Microsoft’s TechNet Blog:
We get a lot of questions about what Microsoft does with the more than $9 billion
we invest in R&D every year. There’s a lot of research for sure, but most of that
69. 66 • CHAPTER 9 – A NEW CUSTOMER CENTRIC SYSTEM
1
investment goes toward development. With 850 Ph.D.-level researchers in Micro-soft
Research and around 40,000 developers in our product teams, that should give
an indication of how we balance that $9 billion between research and the devel-opment
of shipping products.
Those are the dynamics that cause policy administration systems to
cost so much. A very limited customer base must cover the development
cost.
There are several horizontal software products that provide the ge-neric
business functions we need now to replace what is left of your leg-acy
system. They are all very inexpensive compared to any new policy
administration system available. In fact, they are a small fraction of that
cost.
However, cost is not the biggest advantage to these choices. Some of
these software products are also customer centric CRM solutions. Of
course, that is one of the conundrums with legacy systems – how do you
make a policy centric system into a customer centric system? This is a
great solution to that problem. As you know, transitioning to a more
customer centric workflow is very important for a number of reasons.
The Gartner Group identifies CRM as one of the top 10 Technologies to
Impact Life Insurance:
Customer relationship management (CRM) has been a growing priority among
life insurers during the past 10 years. However, unlike the early days when suites
were the primary solution option, insurers are now opting for targeted solutions
to support vertical processes unique to managing field sales, agent and broker
management, and customer service via the call center. By employing CRM, life
insurers can improve the relationships with their sales network, enhance sales ef-ficiency
and improve customer experiences. Empowering the channels with more
customer information (including customer analytics and a whole view of the rela-tionship
with the customer) and tools to assist in the sales process, insurers can
drive more profitability in sales and customer service processes.
I think the best choice among the options, for our purposes, is Mi-crosoft
Dynamics CRM. It is a comprehensive customer relationship
management system. However, it also comes with a free template that
70. RESCUE • 67
enables it to perform the CRM function for a life insurance business.
There would be some customization to tailor it to your specific needs
and to interface it with the Spreadsheet Engine. But what the product
already has embedded is most of the functionality required. Here is Mi-crosoft’s
1
description of the life insurance template:
This business process helps insurance companies sell life insurance policies from
start to finish, including from prospecting for clients to quote, application, un-derwriting,
and policy issuance. Agents, customer service reps (CSRs), and district
managers can use it to capture information from prospects, convert leads into op-portunities,
send price quotes, and create the policy. Customer service reps can
also follow the process to cross-sell insurance products during service calls.
You can also easily modify this business process for selling other types of insur-ance.
Microsoft goes on to state the template contains the following:
• A business process to help you capture all the required data from
leads and follow best practices to close sales.
• Dashboards to track the top clients by agent, the number of ac-tive
opportunities by stage and segment, book of business by cli-ent
age class, and upcoming phone calls and appointments.
• Workflows to add applications to the case manager or under-writing
queue, and send email alerts to agents at key milestones.
• Seven custom entities:
! Application
! Client
! Household
! Illustration
! Insurance Product
! Policy
71. 68 • CHAPTER 9 – A NEW CUSTOMER CENTRIC SYSTEM
1
! Rider
• Demo data so that you can experiment with the process and see
how it works.
You have probably already figured this out but the Spreadsheet En-gine
can easily be configured to do illustrations too, in addition to in-force
policy values. This also includes inforce illustrations. So the
illustration feature of the SharePoint template above can use the engine
for its policy values.
72. RESCUE • 69
1
Figure 7
The completed new policy administration system (see figure 7) con-sists
of these major components:
• SharePoint – To provide a collaborative environment for creat-ing
and managing documents and spreadsheets. It provides all of
the needed controls to keep the documents organized, centrally
managed, stable, and secure.
73. 70 • CHAPTER 9 – A NEW CUSTOMER CENTRIC SYSTEM
1
• Spreadsheet Engine – A custom .net application to enable policy
values to be resident in and maintained by spreadsheets
• Dynamics CRM – A solution to provide a customer centric
workflow process, contain any needed structured data (like client
& agent data), and an interface to the Spreadsheet Engine
Now we have a comprehensive, customer centric, state of the art pol-icy
administration system:
• The technical platform is 100% Microsoft standard
• It is extensible, with most changes doable by non-technical peo-ple
• New innovative products are defined and deployed by your prod-uct
experts
• With no regression testing required
• And the ongoing cost of ownership is much less than your cur-rent
system
I believe this constitutes a comparatively simple, realistic and effi-cient
path to a customer centric workflow – when you are ready to un-dertake
a project like this. It is a much larger undertaking though than
the Spreadsheet Engine, since it involves reengineering the workflow
for your entire business. Everyone’s job will be affected and it will re-quire
a lot of planning, training and testing. But there is potential for
enormous payback. And, if you already have the Spreadsheet Engine in
use, there will be no policy conversion required for any of the supported
plans.
74. 1
CHAPTER 10
Next Steps
ook at the alternatives. Yes, we don’t have to do anything but
is the situation going to get better? Not likely. From a time-to-
market and policy administration standpoint it is not go-ing
L
to get better unless we take some action.
It could get marginally better with technology upgrades. But we are
not going to get far with marginal improvements. Something may help
two percent or three percent, but ultimately – with the complexity of
policies over time and the fact it’s a hundred year problem – there has to
be the equivalent of a landline phone to cell phone change. We need a
profound fundamental change – a change in how we support complex
policy calculations.
That is what life insurance needs on the inside, in the bowels of pol-icy
administration. That is what we’re talking about with the Spread-sheet
Engine – a fundamental change in insurance processing for
complex policy calculations. I would consider it an inflection point in
time-to-market. Andy Grove, Intel co-founder, defines an inflection
point as:
"An inflection point is what happens to a business when a major change takes
place in its competitive environment"
75. 72 • CHAPTER 10 – NEXT STEPS
Unless we have an inflection point – where we basically change the
whole way we do things – we will continue to wrestle with the same old
problems with the new product introduction process in our legacy soft-ware.
The Spreadsheet Engine enables that change. It is a very simple con-cept.
The spreadsheet has already proven to be successful. Product actu-aries
already use spreadsheets to do the very thing that we’re talking
about doing. It’s just never been put in the mode of policy administra-tion.
1
It’s been put in the mode of product design and pricing – not the
actual processing of a policy. It’s been used for many years, very success-fully.
The next step is to get started building a Spreadsheet Engine. Of
course, you don’t want to just turn your business upside down. If you
believe the Spreadsheet Engine might help in your business, then we
need to prove it without spending a great deal of time and without
spending a fortune. That should be the first step.
The project requires people with an expert level of knowledge and
experience with SharePoint, Microsoft Excel and .net. In addition, an
extensive background in life insurance policy administration software is
required. My partners and I have all of those qualifications. We can lend
a hand with any part of the project needed, including developing the
entire solution for you. So, if you have any questions at all, or need clari-fication
on how the Spreadsheet Engine might work in your business, or
want to get started on a prototype, please contact me.
Start a pilot project, to begin iteratively building a prototype Spread-sheet
Engine. But make the project cancellable at any time you decide it
is not what you expected. That is the same strategy we used at the com-pany
I co-founded (Trimark Technologies) when we created the Tran-scend
solution that Ron purchased back in Chapter 1. I have used that
approach to projects several times with great success.
We created that system initially as a pilot project for the Keyport Life
Insurance Company (now part of Sun Life). The project could be can-celled
at any time, if Keyport became dissatisfied. With each iterative
76. RESCUE • 73
demo of the evolving solution we received valuable feedback from Key-port’s
1
business users, which made the next iteration even better – closer
to Keyport’s vision of the perfect solution for them.
The Spreadsheet Engine is a much smaller project. But the same con-cepts
apply – start small and cancel early if things don’t work out. That
minimizes your risk and gives you early feedback.
I have more detail about the design and implementation of the
Spreadsheet Engine. But I want to keep this book at an executive level –
with as little technical jargon as possible. However, I would be happy to
share it with you, or anyone you choose, if you would like to explore the
concept further.
79. 76 • ABOUT THE AUTHOR
1
ABOUT THE AUTHOR
Art Pennington
Art Pennington has had a distinguished career in life insurance policy
administration software research, design, and development. He has co-founded
several successful software firms that have developed ground-breaking
policy administration systems:
• At Trimark Technologies, he created "Transcend", the life
insurance industry’s first client server based policy admini-
80. RESCUE • 77
1
stration system. This patented software architecture is today
managing over $50 billion in annuity and life insurance pol-icy
assets.
• With the Pride-Tech Corporation, he developed the first
hardware independent life insurance underwriting system.
• With Assurance Systems Inc., he created the "Asyst" policy
illustration and pension administration systems.
In addition, Art has consulted with dozens of life insurance compa-nies,
installed and tailored many different vendors’ systems, and sup-ported
hundreds of different life insurance products.
Now as co-founder of Xcelorate Inc., along with his partners, Art is
working to resolve some of the thorniest problems inherent with our
existing legacy policy administration systems. His purpose in writing
this book is to discuss these issues and propose solutions in a way that
everyone can understand and benefit. His proposed “Spreadsheet En-gine”
is truly a revolutionary method of solving the legacy system co-nundrum
– enabling both speed to market for new products and
customer centric policy administration.
If you have any feedback or questions concerning any of these ideas,
please contact Art at:
Art Pennington, President
Xcelorate, Inc.
301 N Riverwalk Dr #402
Buffalo Grove, IL 60089
Email: Art.Pennington@Xcelorate.com
Phone: 312-231-7107
