Posts Tagged ‘Policy Administration’

Getting the Most Out of Your Investment: Three Steps to Revitalize Your Legacy System

Tuesday, October 4th, 2011

Companies don’t need to “rip and replace” large portions of their IT investments in order to gain the set of features they wantBy taking a multi-phased approach to incrementally roll in functionality, organizations can benefit from quicker ROI without the costs and risks associated with “big bang projects”. This multi-step approach is a win-win for business and IT; business can reap the benefits of go-to-market features sooner and IT will be able to adapt to changes more quickly.  Here is our recommended three step approach to revitalizing your IT architecture:

  1. Leverage What You Can: Revitalization efforts have to be carried out with a focus on leveraging your existing architecture. Wrapping your existing assets in web services keeps some of the older technologies in play.
  2. Implement As Needed: Keep it simple and only add functionality that’s really needed. By purchasing pre-built components that augment your existing systems, you can add the functionality you want with minimum configuration and customization.
  3. Rapidly Build New Functionality: Once you’ve decided on the new functionality that you would like to add to your system, we recommend that you rapidly develop these applications using software development automation frameworks such as FAST 8x. By rapidly building SOA-compliant components, you can leverage modern technologies and get the benefits of development efficiency.

Once you have implemented all three steps, you are on your way to fulfilling immediate business needs while achieving long term architectural goals for the future.

20 Questions to Understand What Your Vendor Means by “Re-Architect”

Friday, July 29th, 2011

I think the term “re-architect” needs to be stricken from our vocabulary.

Whether you’re building a home or a system, the architecture is the first thing you decide upon.  It’s fundamental.  Just as the architecture for a home lays out the blue print for the physical structure, the architecture of a system lays out the blue print from which components and functionality are developed. Before the first batch of concrete is poured or the first line of code is written, you put that blue print in place, and from it every piece of the home or system is defined and developed.

With large-scale systems like policy administration, every line of code is written with that architecture in mind and it is core to everything in the system.  The architecture defines the very essence of the system – it is beyond “foundational”.  Once you go down an architectural path, you might be able to make changes to it, but there’s no re-doing the architecture unless you throw everything out and start from scratch.

So when vendors throw around the term “re-architect”, I think it can be very misleading.  “Re-architect” seems to imply that they have applied some fundamental, structural changes to the software without compromising the system itself; yet, to truly “re-architect” anything would mean a complete overhaul of the architecture that defines it. So, it’s kind of a misnomer.  If they had actually rewritten the system, they would say “we did a complete 100% rewrite from the ground up”.  If they didn’t rewrite it, then there is NO WAY the system is not compromised by the legacy architecture it had.  When you’re purchasing a system – large or small –, there’s a fair amount of legacy architecture and legacy code that comes with the package in almost every case.  You may be OK with that, but you need to have a good appreciation for the extent of it.

Along the lines of finding the “freshness date” or newness of the architecture of the system – as well as just doing some good due diligence – here are 20 key questions I think you need to be asking your vendor as part of the assessment:

  1. When was the last time you “re-architected”?  What parts were not rewritten and why?
  2. Why was the “re-architecting” deemed necessary? And what was the overall impact to the system in terms of % of code rewritten?
  3. What year was the oldest code in your system written?  (I suggest you have the vendor make that a contractual representation and you should get an honest answer.)
  4. For your policy administration system, do you have a monolithic or component based object structure within your code?  If component, do your components reference each other within the code?  Are there database joins that go across your components?
  5. Can you tell me how many lines of code your software is (by language)?  (The purpose here is to gain an understanding of the ratio of newer code to legacy or older code.)
  6. How many customers have converted or committed to converting to this new architecture? For those who have converted, what was the average project duration?
  7. How many lines of code did you write for each of your last three new client implementations?  How long did those implementations take?  (Make sure you can reconcile the lines of code to the duration and that it passes the “smell” test – in other words “if there’s that little code, why did it take so long?”)
  8. Assuming coding changes are required (and they will be), what restrictions are there on using external consultants?   Here the vendor will likely represent that you don’t need to make changes to the core system – do not under any circumstances accept that answer.
  9. How many developers do you have supporting clients offshore and onshore on this platform today?  (Given the low amount of programming you will be told is required, make sure you can reconcile this answer to the answer in #7.)
  10. Am I forced to use your proprietary rules engine?  How easy is it to swap out?
  11. What contractual guarantees are you willing to make about maintaining this platform in the future and future releases?
  12. What is the biggest implementation (# of policies) that anyone who is running on one of your past two releases of the platform we are buying?  (Work to make sure that the answer IS for the platform you are buying.)
  13. List your current clients for the platform I am buying and version of the platform they are running.   (Accept that some clients can’t be named, but insist on a complete list.)  Exactly what functionality are they using and what is the product mix?
  14. Can I have the attendee list from your last user group meeting?  This IS NOT highly confidential and they should be able to give it to you.
  15. Who was the last policy admin customer to go into production for individual life?  Individual annuity?  What were the released version those companies used?
  16. How long did it take your last policy admin customer to go into production (from initial requirements through production)?
  17. Over the past five years, how many companies who have selected your platform where you started projects and the customer never ended up going into production?  (This is information you can learn for yourself in the industry.)
  18. How many policy administration customers do you have that haven’t made a significant number of code changes for customization?  Please name them.
  19. How many policy administration customers have done production upgrades to a newer version over the past five years?
  20. How many customers have terminated maintenance agreement in the past three years?


John Gorman


If Policy Admin Systems Are a Thing of the Past, What’s Next?

Friday, August 27th, 2010

Last month, I shared the reasons why I believe large policy administration systems are a thing of the past.  As a follow up to that post, I would like to offer some insight into what I think the next generation might look like.

Certainly, the future solutions will leverage SOA and small re-usable components.  Here is an example of a life insurance financial transaction and how it can be constructed using a series of web services sitting on top of standalone components.    A series of discrete web services sitting on top of standalone components can be orchestrated to perform the overall transaction.  Typically this logic is buried in code somewhere, but by doing it this way, the components are decoupled.

It is fairly easy for people to describe and agree on what is needed, but pretty difficult to actually get there.  So, here is a brief explanation of the steps that can be taken.

  • Build all new components to be small enough and able to stand alone – All functions your components perform must assume all data is received from the outside.  They will only have access to read data that is specific to and contained within the component.  All other necessary data should be received as parameters.
  • Leverage an existing component when you can - To leverage your existing functionality, functionality needs to be walled off and you need to integrate with it however you can (not one size fits all).
  • Separate out orchestration – Using 3rd party software for orchestration forces a discipline to make the components truly standalone and guarantees the isolation of orchestration logic.  We use Microsoft Biztalk and IBM Process Server to do this.  However, there may be times for performance that you need to write code to have these components truly talk to each other.  This code has to be isolated into a separate level.
  • Find the right level of granularity, which can be an art – I have debated this point with people over the years.  On one hand, you can make every single method its own web service that can be orchestrated.  The other extreme is what most people have.  Like most things, the answer is in the middle and unfortunately case by case.  We draw the line at useful components that can do their own jobs.
  • Assume data can come from anywhere –The user interface, orchestration, web services and business process logic should not care where that data came from.  The data source should be abstracted from those layers.  In addition, the data translation needs to be handled “outside” your core code (either isolated in its own code or preferably in a 3rd party tool).
  • Continuously eliminate redundancy – There is no way to completely eliminate redundancy, but you can certainly try.  Purchasing existing components that have single functional purposes is the best way to start off with less redundancy.  However, you will still have to evolve and continue to find the places where there is redundancy and pull it out.
  • Use a modern “technology stack”– Wrapping your legacy keeps some of the older technologies in play, but if you limit its functional purpose, you are also limiting what needs to be maintained.  The newer components can leverage more of the modern technologies and get the benefits of development efficiency as well as scalable organization.
  • Implement as needed – Keep it simple and only add functionality that’s really needed.  It’s important to avoid the “bloat” of having every feature possible.  Only add components and functionality that is needed to run the business.  By stringing together the components that are needed, you can avoid having to maintain things you don’t use.

In the future policy administration model, companies can incrementally add functionality into their enterprise without major conversions and “big bang projects”.  The business can get benefits sooner and when the priorities change, you can adapt.

If you want to learn about the next generation of Life Insurance enterprise components, see

Tom Famularo

8 Reasons Why Large Policy Administration Systems Are a Thing of the Past

Friday, July 9th, 2010

Today, it’s clear that insurers will stop placing big bets on large systems. They’re moving to a model where small components and web services combine with their legacy components in an incremental manner. Here are some of the reasons why:

  1. All systems want to be the “center of the universe”. In a future world of SOA and architectures of small re-usable components across an enterprise, components need to be built from the ground up to be standalone and ready for integration.  Most vendors of “systems” or “platforms” say they are built for integration (and some of them even are). Of course, you need to make that system the “hub”.
  2. “Throwing the baby out with the bathwater” – much of what insurers already have in place works just fine and can be leveraged in some way without significant expense.
  3. The full software package has a number of awesome features that are just not applicable to your business.  It has been estimated that more than 50% of the overall functionality a system has to offer is not even needed or used in the average implementation.   The customer is paying for this functionality one way or another (with higher than needed fees to vendor and higher maintenance costs due to “code bloat”).
  4. There is no comparable “one-to-one” match to your existing legacy platform you want to replace.  So, a significant mapping, customization, “configuration” and integration job is required.
  5. Redundant functionality in the admin system to other areas.  Typical redundancy consists of client, product, policy, agents, and even generic functionality like content management, users, security, work queues, correspondence and much more.
  6. It’s all legacy anyway.  The “newest” US life Policy Administration system with any substantial customer base is about 10 years old.  With technology generations coming and going faster than ever, this is already out-dated.  Compound that with the fact that it will take you 3-4 years to convert your legacy onto this “new” system that is now almost 15 years old when you are finished…time to start looking again for a new system.   Now, let’s look at some of the other “good” systems on the market…they have all been re-branded by slapping on new technologies onto their old core code.  In those cases, you’ll be looking at a 20-25 year old system by the time you’re done.
  7. Instead of incremental improvements sooner, systems are designed to be implemented as “big bang” by converting full blocks of business or put up new products.  They do not allow you to implement one major business function at a time.
  8. Most of the top vendors out there have been acquired by a large company who has significantly increased costs, are primarily looking for the “big deals”, have stopped innovating, and diluted the domain expertise and talent.

If you want to learn about the next generation of Life Insurance enterprise components, see

Tom Famularo

Buying Another Policy Administration System: Negotiating Tips

Thursday, April 29th, 2010

Buying Another Policy Administration System:  Negotiating Tips

We recently met with some of the senior technology people at a life insurance company here in the US.  After a long exhaustive analysis, the company was completing the selection process for a new policy administration system.  They had narrowed it down to two leading systems from a short list of 7 or 8. 

While both of the finalist systems had their attributes and selling points, it struck us that the newer of the systems had been around for almost ten years and the older of the two had been around for twice that long.  Surely, they had been re-architected and improved in that time, but for both of these systems “new” is not exactly the right description.

In terms of track record, the insurance company openly acknowledged that neither of the finalists had had much success actually implementing their solution in the past 5 years.  Their estimation was two or three truly successful implementations between the two vendors since 2005.

Anything a company can do to improve the likelihood of success with a policy administration vendor relationship is important.  From a contracting perspective, here is what we recommend:

  • Get source code.  Regardless of the administration package or the vendor-speak about not requiring source code, we strongly recommend that you negotiate rights to code (not source code escrow).   If the vendor claims that they don’t provide source code access, the vendor should be able to represent in the contract that they have not licensed source code (or given the option to buy source code) to any other client.
  • Get reasonable provisions around your rights to use third parties to maintain and configure the system.  The vendor should have to earn your business on an ongoing basis.  Most vendors will have a list of competitors that cannot access the system.  Be sure to limit this to providers of competing SOFTWARE.  You need the flexibility to contract with outside experts who can do some or all of the implementation and maintenance.
  • Do not start the project without a signed license.  However, you should have the ability to opt out (and get a refund of the license) if the services estimate exceeds a certain threshhold.  Also, to facilitate the contracting process, you should agree to a term sheet with the MAJOR deal provisions (like getting source code).
  • Get the “A team” from the vendor and get that commitment with named resources in the contract.

Obviously, a good license contract is only part of the equation, but it’s a start.

John Gorman