Revisiting the Assumptions of Core System Selection: Does Size Still Matter?

In today’s insurance core system market, it is critical to treat information such as vendor size, installed base and technical modernity claims as data points to be explored further, rather than facts that can be evaluated in isolation.

Collisseum-Rome

(Colosseum, Rome: still impressive, but not what it used to be. Photo Credit: David Iliff.)

As insurance carriers emerge from the great recession, I’ve seen a definite movement toward investing in transformational policy administration replacement projects. I am encouraged by the move away from a “do nothing” strategy where carriers continue to maintain and expensive, inflexible and out-of-date technology.  In the same vein, I’m concerned that many carriers will ultimately be disappointed because the tried-and-true selection criteria, such as vendor size, install base and architecture, may no longer be as relevant or lead to true platform modernization.  In fact, they may find themselves settling for only marginal improvement.

Here are a few selection criteria that you should consider reevaluating:

Selecting a larger vendor  does not automatically mean less risk for your modernization initiative.

While larger organizations may tout employee counts in the thousands, generally the people who actually work on the technology and are available to the customer are far fewer.  Greater scale also translates into more hurdles for contractual, strategic, and investment decisions.  These add complexity, risk and cost, while simultaneously necessitating a less nimble and empowered team.

Instead of focusing solely on company size, I recommend that carriers assess whether the vendor has a viable plan to scale up to meet their needs. I encourage evaluating the company by the specific team that will be partnering with your organization.  This solution provider team should bring experience and an approach that can assist in rapid product implementation practices and creative thought processes for solving problems.

Selecting a vendor with a large installed base does not mean that the current version of the application is established, comes with a seasoned implementation team, or ultimately presents less risk.

Earlier versions of a given software solution may share little with the current offering.  In fact, many of the systems at larger vendors are the result of an acquisition which might not have included the bulk of experienced implementation talent. In some scenarios, a system may have been completely re-written, thus nullifying the value of a broad install base and equating to the same risk of early adoption associated with newer system vendor.  This also means that the staff on hand might be more focused on maintenance than experienced in implementation.

I recommend finding out how many customers are on the current version versus how many are on an older version. These numbers will provide some insight into the potential challenges of upgrading, the level of customization among the current client base and the maturity of the current solution.

Sometimes the terminology that vendors use is more marketing speak than reality.

All systems have an “architecture.”  Regardless of the platform, design, or structure of the application, every vendor is going to present their offering in a positive light.  All vendors are responding to RFPs with the pea soup of buzzwords – “modern”, “component-based.,” etc.  – that make it difficult to compare on paper the differences in how this architecture supports all the insurance features. Larger organizations have entire marketing departments skilled at presenting their technology as configurable, flexible and service-oriented.

However, It is important to take the time to determine what is actually configurable by performing actual live functions and measuring the effectiveness of implementing the change.  In today’s environment, insurance product development processes can be accomplished without traditional coding. Carriers should expect that the “configuration” can be performed without proprietary syntax or complicated programmer-like tasks.  They should also look for common, intuitive techniques for accomplishing business rules, screen edits, and calculations.  They should verify that advanced infrastructure techniques, including virtualization and high-availability, are inherent to the offering’s technology stack.  The solution should enable either a native or responsive design-based approach to support the proliferation of mobile strategic plans.  Verify that web services are exposed as real-time events – not placement of data for later processing.  The real benefits of the architecture of the system should be evident in its ability to enable a component-based approach to fulfilling scalable SOA orchestrations in a straight-through processing approach.  This is key to enabling agent and customer portals with up to date information and the ability to perform self-service transactions.

In today’s insurance core system market, it is critical to treat information such as vendor size, installed base and technical modernity claims as data points to be explored further, rather than facts that can be evaluated in isolation.  Unfortunately, these data points only tell part of the story and are prone to inferences, and can result in sub-optimal system selections.

Don’t let this happen to your team. Following these guidelines will help you to ensure that the system – not just the sales presentation – gives you what your company really needs.

Kevin Walma // As head of Product Strategy at FAST, Kevin Walma is focused on strategic product direction, design and architecture. He brings over 18 years of experience in insurance and technology. Walma began his career at AIG where he held a broad range of roles including business analysis and programming, installing policy administration systems internationally, and ultimately serving as CIO of the insurer’s Caribbean operations. Later, as CIO at core system vendor AdminServer, Walma’s responsibilities included managing several client implementations as well as leading product development. After Oracle’s acquisition of AdminServer, Walma’s responsibilities grew to include managing product development for the vendor’s full suite of insurance applications managing teams in multiple sites across several countries. Most recently, Kevin was CIO of Adminovate guiding the company’s startup and initial product development.

Comment (1)

  1. Large vendors can write certain “guarantees” into their agreements that aren’t known upfront from traditional analyst research. Likewise, they can do bundling of hardware, software and services in ways any component standalone cannot match.

Leave a Comment

(required)