As a user of custom off the shelf (COTS) products supporting core operations like claims, policy administration, and billing, in the insurance segment, you understand the intricacies of the existing platform and its ecosystem. Typically, latency of two or more versions warrant an upgrade. Benefits primarily include reduced total cost of ownership (TCO), but also new out of the box (OOTB) business features and capabilities, and adaptability to future versions.
An enterprise/technical architect juggles with versions of systems and applications, middleware, and databases, and their licenses, costs, and technological compatibilities. They must align with the future state vision for digital while supporting the current state. The COTS application upgrade on the radar could potentially impact architecture and strategy; development, testing, and production environments; and maybe build and deployment processes.
Business typically treats upgrades as an expense item but still wants all the new (in)tangible capabilities from the upgrade, such as speed and performance improvement, analytics, and monitoring, and better data to support decisions such as settling claims and policy renewals.
Here’s a look at a few questions regarding COTS product upgrades that can help soothe some anxiety regarding upgrades.
Start with the basics. Here are some questions to consider: How good is my OOTB conformance? Do I have any tactical and/or strategic architectural and technological requirements and/or constraints? How many versions are we latent by? What tools and accelerators does my SI vendor bring to the table? What are my current pain points? Do I have the right skills and resource mix, within my organization or with the SI vendor? What is my strategy with respect to adopting new features and capabilities?
‘One-size-fits-all’ doesn’t work: Upgrades are specific to organizations. The primary aim is to complete the upgrade quickly, minimize business disruption, and to expedite business benefit realization.
We believe, one would need to analyze the existing platform and all ecosystem relationships and dependencies such as Java and Oracle versions, internal/third-party interfaces, and enterprise security. There’s also the need to ensure all impacted stakeholders are aware of the upgrade and the risks to service fundamentals. You can never over-communicate when it comes to broad, operation-impacting changes.
What do we avoid? Learn from our err… experience.
Do not underestimate the complexity or the effort of the project. A lot of unknowns may accompany the upgraded framework and its compatibility with the existing platform. Take nothing for granted. Additionally, business users may get carried away with added features and capabilities and may want to change things - a little here, a little there, which can snowball into a major overall impact.
Do not underestimate the critical environmental issues like firewalls, middleware, especially with third party providers. The support processes, agreements, and SLAs need to be understood clearly otherwise, they could bite us big during implementation. On the other hand, when planning communication and organizational readiness, do not overestimate the technical capability of frontline staff – things that seem simple for IT folk can boggle a claims representative.
With the Dos and Don’ts established, plan: Starting with the decision to upgrade, planning continues through assessment and inception phases. Start with an overarching project plan, baseline during inception, and devolve into a detailed tactical plan.
Engage the right resources – upgrades warrant resources experienced in the product as well as business and technical landscape. Upgrades are typically monolithic, and do not lend themselves well to agile. However, organizational complexity may warrant agile, or even a hybrid option. Prioritize the delivery of the functionality so that business users and testers can view the upgraded application(s) early, expediting defect detection and prevention.
Testing – the beacon and the torchbearer: Testing constitutes a major risk and cost impact, from technical as well as business continuity and resilience perspectives. Testing framework improvements, especially in automation and early/incremental/continuous testing, accrue huge benefits, and should be leveraged. Automation in test scripting and execution saves time and helps plan for testing, especially on the numerous ecosystem interfaces. An upgrade must ensure integrity of all interface contracts. Dry runs ensure the actual implementation goes through smoothly – plan them as part of the testing regimen. Test data should mirror production data to the extent possible, to ensure that real problems can be identified and addressed during development and testing phases.
Clearly, upgrading COTS products is a significant decision for an organization. The reasons, and benefits, extend far beyond financials. An upgrade needs to be assessed, planned, and implemented with deliberate caution and as part of an overarching IT enterprise and platform strategy.