While a lot of organizations are bringing in new technology to solve their legacy system problems, others aren’t willing to spend multiple millions without looking at alternatives. Many of these are finding “legacy modernization” brings much of the benefit without an eight-figure price tag.
Why Modernize?
Gartner’s recent survey; “Top 10 Technology Trends Impacting Life and P&C CIOs in 2014” clearly identifies Modernization as a top trend, and found three primary drivers for the need to Modernize:
- Service to customers and / or business partners
- The level of operational efficiency
- The time to market for new products and services
That said, Modernization as a Practice, is not a topic that is widely discussed in the P&C world. Most often, the route to core processing refreshment is through Policy, Claims and Billing replacement projects. However, such projects are fraught with risk, and quite often suffer cost overruns, or worse. There are very few companies that have ‘modernized’ their core processing systems.
As the tools and techniques of Modernization mature, perhaps it is time to look at the Practice of Modernization in the P&C Industry.
Be Flexible
A best-of-breed Modernization process should first and foremost be highly flexible. It is important to understand that one size of Modernization does not fit all customers – one size does not even fit all systems within one customer.
Best-of-breed Modernization Practices should break the work down into three steps:
- Assessment – what is the state of the current software, and what does it do?
- Strategy – how is the software going to be modernized?
- Transformation – the process of Modernization.
A flexible Modernization Assessment process uses the actual code base. By using the actual code base, there is assurance that what is being discovered is exactly what the system does, as opposed to what the out-of-date documentation (if there is any) suggests it does.
Be Successful
A successful Assessment process will typically consist of two steps:
- Discovery–where all the application attributes; source code, schemas, screens, scripts, or other resources are used to create graphical and tabular representations of the components.
- Elaboration– this is a deeper dive into the application and data structures,exposing program and data interdependencies and the underlying business rules.
After the Assessment, the next step is to develop the Strategy. Now that the company knows as much information as possible about the legacy application, the next question is: what is the best next step?
Select Options
There are really 5 strategic options, one or more of which will be used in a modernization project:
- Re-host / Re-platform – the application is moved from its current environment (typically mainframe) to a distributed client-server environment, and the host language remains the same.
- Retain / Wrap –Parts of the application are ‘wrapped’ to make the system web-enabled to improve the accessibility.
- Refactor / Reengineer –Parts of the system are redeveloped to take advantage of both the modern language and the ability to migrate the application to a distributed environment, improving flexibility and end usability.
- Rewrite – a new application is written from scratch using the information gained during the Elaboration phase to help architect and design the system.
- Replace – the legacy application is replaced with a commercial off-the-shelf application, using the work done in the Assessment phase to understand / design the appropriate configuration of the new system.
What’s Next?
This is the first of 2 posts looking at Modernization in the P&C Industry. In the next article, we will examine which systems P&C companies should consider for Modernization.
Editor’s Note: Peter Symons ([email protected]) is vice-president Insurance Services at Mariner Innovations, an innovative IT services company, as well as Canada’s leading supplier of Application Modernization Services. . Peter has been a long-time friend of Insurance-Canada.ca.
While I agree in principal with the approach above, I feel strongly that legacy modernization is a very risky proposition. Comments from insurers around the ability to staff support for legacy applications is growing and it’s not just a question of building Cobol or PL/1 skills – there are inherent methodologies of the ’70’s and 80’s that are much more complex. In addition, developers also have to learn the complex interfaces that have been built over time.
The evidence is twofold. OSFI is starting to request Financial Institutions to document roadmaps on replacement of legacy systems due to the inherent risk of running them and not being able to support new functionality. The second is demonstrated by the strong trend in the industry to replace core claims systems (mostly Property and Casualty), but also move to cloud solutions for faster deployments.
Hi Debbie,
Thanks for your comment, I completely agree with you that legacy languages and design patterns are a risk, and that’s exactly what Modernization is designed to address.
The three-phase approach allows the company to first discover, in detail, the inner workings of their legacy application, to really understand what it does and how it does it. Second, and armed with that knowledge, the company can then develop an appropriate Modernization Transformation strategy. Third, execute the Transformation Strategy, which can be any of the 5 options outlined in the article, ranging from a re-hosting, to a language update or outright replacement, cloud based or otherwise.
The whole intent of Modernization is to reduce risk by eliminating legacy languages, databases and design patterns, but to do it with a clear understanding of what you are replacing and after having considered all the options that are available.