Similar to the young, green behind the ears, hot-shot professional on the fast track to replace the seasoned veteran, a major drawback of the big bang implementation mindset is underestimation of the number of years of knowledge and process nuances that have been built into the incumbent system. For example, the exception to the rule that is typically specific to a jurisdiction and data combination is often not even considered during the new system implementation since the exception was identified and implemented long ago, most likely never documented, and forgotten over time. Multiply the one exception to the rule by years of exceptions and the legacy replacement project just got a lot more complicated.
The new system that was selected to provide the company the flexibility to compete in the new insurance world often doesn't even get out of the starting blocks. While the system may promise ultimate flexibility to quickly implement any rule, it typically lacks the real world education and the system equivalent to street smarts to know just what those rules should be. The years of knowledge, rules, and exceptions built into the existing legacy system need to somehow make the transition from the old to the new in order for the project to be successful.
Rather than the big bang, once and done approach, any core system replacement should be a controlled migration with a well thought out transfer of knowledge from the old to the new. And as insurers move more of their corporate knowledge and management to automated systems, the ability to preserve and share that knowledge between IT solutions becomes even more critical.
In essence, the term 'legacy applications' should be redefined to reflect these systems' important roles as knowledge goldmines to be carefully excavated rather than just old technology that needs replacement. A good way to approach the extraction of existing product and process knowledge is to capture the detail from the legacy source code and build rule and configuration repositories to be utilized by the new policy administration system.
Any new policy administration system worth considering should include a robust product configuration engine that isolates insurance product setup from the transaction processing engine. The details of these product configurations are contained within existing legacy systems as both data definitions and business rules. Exposing existing product configurations and rules to the new policy systems as data and/or services mitigates the overall project risk and allows the insurer to more effectively move product knowledge to a new platform, independent of the processing systems.
However, a caveat exists if the legacy processes are not SOA friendly which then requires either the creation of an SOA wrapper around the existing processes or migration of the processes to a more robust process engine. Regardless, the project risk is still significantly reduced as this approach allows the testing of business processes in isolation of the process consumers.
In any legacy replacement effort, business partner integration requires a close look and careful consideration in order to get it right. The majority of legacy systems have a large amount of business logic and rules configured to manage the integration of transactions between business partners such as agents, insurers and even the insured. These integration points are typically highly complex and manage issues related to data migration, conversion and electronic communications. The replacement of these interfaces is more often than not time consuming, costly and error prone. By integrating interfaces with existing legacy systems and processes, the insurer is able to complete the new system implementation in manageable increments, saving the migration of the actual legacy processes for a later date.
Unfortunately, in their desire for new technologies and the potential benefits they offer, insurers have often done themselves a disservice by not allowing their technology strategy to allow room for both the old and the new. While new products are best developed on new systems, there is still a lot of value and knowledge in the existing legacy systems and processes that have done a fine job of running the business for years.
In the best environment, it shouldn't be a question of 'old or new' but rather a smart combination of the two. Creating a plan for coexistence and a method to transfer the years of experience and knowledge embedded in the old systems will better serve insurers in the long run. It's more important to successfully reach the finish line even if the pace is slow and steady, than to move quickly only to fall short of the goal.
(Dan Sobotincic is executive vice president, head of global P&C division for Sapiens. He can be reached via e-mail at [email protected].)
Want to continue reading?
Become a Free PropertyCasualty360 Digital Reader
Your access to unlimited PropertyCasualty360 content isn’t changing.
Once you are an ALM digital member, you’ll receive:
- Breaking insurance news and analysis, on-site and via our newsletters and custom alerts
- Weekly Insurance Speak podcast featuring exclusive interviews with industry leaders
- Educational webcasts, white papers, and ebooks from industry thought leaders
- Critical converage of the employee benefits and financial advisory markets on our other ALM sites, BenefitsPRO and ThinkAdvisor
Already have an account? Sign In Now
© 2024 ALM Global, LLC, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to [email protected]. For more information visit Asset & Logo Licensing.
