EvolveWare Blog

The Hidden Risks of Modernizing Legacy Systems with COTS Products

by

Is Your Government Agency Considering Moving Legacy Systems to Commercial-Off-the-Shelf Products? Read This First. 

According to Gartner’s 2024 CIO and Technology Executive Survey, 75% of Government CIOs and executives are increasing funding for application modernization projects this year. There are a whole host of reasons behind this surge: the desire to harness new AI technologies, the desire to provide citizens with enhanced digital experiences, the challenge of recruiting talent with legacy knowledge, and the pressing need to address cyber security vulnerabilities. For instance, the White House recently issued a report recommending developers reduce dependency on programming languages like C and C++ due to memory safety vulnerabilities that increase the risk of cyberattacks. While Government IT leadership clearly recognizes the urgency around assessing and moving off legacy technologies, planning for and implementing these projects can be quite the undertaking. In recent years, many of these government agencies have turned to third party software vendors and commercial-off-the-shelf products (COTS Products) as a way to speed up the modernization process and remove the need to internally maintain certain code components such as code that goes into creating a user interface. Some examples of these vendors include Gainwell Technologies who provide a modern state government Medicaid system, Curam Software, and Oracle’s suite of software solutions.

But deciding to move to these third-party products hasn’t always resulted in the faster and easier solution that agencies had hoped for. Many of them have faced project delays, budget overruns, and/or project failures in trying to move existing systems to these platforms. 

So what gives? Is the strategy of moving to a third party or COTS product not tenable? The short answer is no. State agencies can indeed benefit from moving to these third-party vendors  IF they do the work upfront to understand their unique system needs and use that information to validate that a viable COTS product exists. 

Case Study: Lessons Learned from Department of Veterans Affairs EHR Modernization Project

The Department of Veterans Affairs (VA) has been working on a modernized version of their electronic health records (EHR) system since 2018, after 3 previous attempts. The original system dubbed VistA, or the Veterans Health Information Systems and Technology Architecture, was developed by the agency 40 years ago and has grown to support approximately 100MM or more veteran medical encounters in a year. While the system is generally applauded by its users, it was becoming expensive to maintain due to the legacy programming language it was written in (Mumps) and made it hard for the agency to share data with relevant organizations such as the Department of Defense and community providers. So the agency signed a contract to move to a platform created by Cerner (now Oracle Cerner) for what was to be a 10 year modernization project. Almost 6 years into the project, there have been multiple delays and the original budget of $10B has already ballooned to $16B with the project roll-out halted until at least this summer. 

One key reason called out for why the project has not gone according to plan is the difference in what the Oracle Cerner system is designed for versus what makes VA patients unique and therefore what the VA system requires. For example, the Oracle Cerner system is designed around billing which is not a priority for VA hospital providers. In addition, the VA requires management of referrals and care outside of their services. All these differences need to be reflected in the policies and logic that the system executes. That is where the number one lesson for planning and managing these projects comes from: an agency must start by understanding their source application both from a technical level as well as from a policy or “business rule” level.

Understand the policies running in your current system and develop requirements for your future system

Business rules extraction is the process of understanding and inventorying the organizational policies that are implemented through the execution of consolidated business logic. See examples and more about the difference between business logic and business rules here. These rules can then be analyzed and audited by an organization in order to: 

  • Determine which rules or policies are still relevant for a future system 
  • Retire any rules or policies that are no longer relevant 
  • Identify which rules may need to be added for a future system. 

This process is critical for many types of modernization efforts including those where a third-party product replacement is being considered for a current application or system. The process can either be used to determine which third party platform is the best fit to replace a legacy system (if one exists), or if a third-party tool has already been chosen, it can be used to determine which policies are not currently but need to be implemented in that tool. 

A State’s Medicaid system case study

EvolveWare was recently involved in a project where a State was looking to move its Medicaid system to a modern third-party equivalent. In order to determine if that third-party product contained the appropriate functionality, the software vendor recruited us to use our Intellisys platform as an automation tool to speed up and de-risk the extraction of the business rules or policies from the source system and compare to the policies being implemented out of the box in the new product. Any functionality that was missing was deemed a policy that needed to be imported into the new, modern platform. For about 1.3MM lines of code, the rules extraction initiative was completed in 6 months, and the client was provided with all the information needed to evaluate if any critical policies still required implementation in their new platform.

While it may seem time-consuming to go through this process when trying to save time by moving to a COTS product, taking this step upfront will actually reduce time and wasted budgets on the backend. And most importantly, having the inventory and analysis of the policies contained in your current system will give you the peace of mind of knowing that no critical functionality is missing, particularly when citizens’ lives and well-being are affected by these systems.

To learn more about how the Intellisys platform can help you evaluate if moving to a COTS product is the right move, contact us.

 

You May Also Like…

Why Should CFOs Care about Legacy System Modernization?
Why Should CFOs Care about Legacy System Modernization?

CFOs are facing increased pressures with shifting priorities and inflationary worries. Application modernization can be a solution to deliver long-term savings. With current volatile inflationary conditions, finance leaders are facing increasing pressure to find...

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *