Core Systems Replacement Redux

We were having lunch with a consultant colleague last week, and the subject turned to core systems modernization / replacement. It seems that a significant percentage of North American initiatives are running longer than planned, or higher than budget, or narrower in scope. Some are encountering more than one challenge.

We scratched our grey heads — we recalled seeing this movie before — and wondered if our industry has a pattern that needs to be repeated every couple of decades. We have a theory of why this might be. We’d like your thoughts.

It started out so simple …

At the outset of this current century, there were some new approaches brought by new core systems suppliers, which caused people to believe that things could be different:

Internet-enabled: Vendors had adopted the Internet protocols for communications, for the user interface, and for development.  This standardization would standardize the approaches and delivery mechanisms.

Data-driven: Modern data bases and standards would simplify how data were captured and presented and allowed rich, common reports.

User-driven: New protocols for developing and delivering requirements and collaborating (Agile methodology).

Everyone agreed to start with a simple out-of-the-box implementation and expand in ‘phase II.’

And, there were initial wins that demonstrated that success was possible.  Life was good for users, IT, and suppliers.

Then, things started to change …

Ever so quietly, issues have started to surface, e.g. …

•  Suppliers found that the internet access approach was not as open as users expected; the differences between browsers were such that the supplier had to dictate which browsers (and versions) were compatible.
• Insurers found that the data standards and schema didn’t meet their needs completely, and exceptions were required, especially for integration with other production systems.
• The Agile methodology is powerful, but not perfect (see the recent post Is Agile Outdated?).
• Out-of-the-box is a good idea, until it doesn’t provide sufficient functionality for bringing at least one product live.  Changing requirements and regulations are the nature of the business in this market.

Like deja vu all over again …

Few of these issues are technology related and could easily describe previous periods.  In the early 1990s, a number of first generation policy administration systems were coming due for review and suppliers were lining up with offerings that included:

• ‘Smart’ client-server architectures to replace ‘dumb’ terminals.
• Relational databases to replace flat files, offering greater flexibility in analysis and reporting.
• Project Management methodologies to control scope and effort in bringing the system to production.

As with the current environment, success in initial implementations were harder to realize as additional customers were brought on-stream.

So, how do we handle this?

We think there are a number of issues that can be addressed, if we understand one basic recipe: Core systems modernization/replacement requires:

• 25% technology skills,
• 35% business expertise, and
• 40% leadership.

And we believe that the biggest element for the leaders is to keep the enterprise focused on implementing the organizational priorities in a manner aligned with the organization’s culture. Technology needs to support these priorities.

Suppliers are bringing the most current technology to the table.  It is up to the customer and end user to make intelligent selections and actively direct implementation to meet the individual organization’s needs.

It is far too easy to assume that if the technology worked with another organization, this success can be replicated exactly in a new business environment.  There is significant value in having standards for what the systems functionality needs to be, but not how we deploy that functionality.

What do you think?

We would welcome your comments and your experiences.