Incorporate a tool into a legacy system

If you want to launch a claims status tool but are working with a legacy system, an encasement strategy may be useful to you. An encasement strategy is a de-risked way to launch a claims status tool without needing to rewrite your entire legacy system. Instead of waiting until your system is fully modernized, you can build your new claims status functionality alongside your legacy codebase. This software design pattern is often called encapsulation, encasement, or the strangler fig pattern.  

Encasement in practice

Following an encasement strategy, you can introduce an API layer between your legacy codebase and the new claims status frontend. You can think of the API layer as a bridge or translator between your legacy system and the new frontend service. You might also add a new data layer when you stand up your new API. A cloud-hosted data layer could sync data from your mainframe on a nightly basis. This implementation will allow your new claims status tool to launch status updates with higher availability and scalability, without having to refactor much at all about your legacy codebase.  

Following an encasement strategy supports the creation of loosely coupled software in a cost-effective, agile way, delivering value to claimants without waiting for a larger and potentially more costly migration. 

As you improve on your new service, you may find you can reduce reliance on your legacy system, gradually providing value along the way. Martin Fowler describes this strategy as an “alternative route to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled. A strangler fig can give value steadily and the frequent releases allow you to monitor its progress more carefully.”  

Nearly a decade after Martin Fowler wrote about the software pattern, 18F, a digital services agency within the General Services Administration of the federal government, highlighted the value of using Encasement when working with legacy government systems. State programs have already been finding success following an Encasement strategy to launch claim status trackers. California’s Claim Status Tracker Application is an example – you can preview the code here.

Key questions

In terms of practical next steps for getting started with an Encasement strategy, you can build upon what previous software development teams have learned along the way. Consider the following questions:  

• What data does your claim status service need?  
• What will your API layer look like? Would you like to introduce a new datastore alongside it?  
• What can you simplify?
  • For example, you may wish to start read-only so you have one-way data flow from your legacy system to the new service. Work with what is the most feasible within your system. One approach might be nightly extracts from the mainframe. A nightly delay between status updates is better than no visibility into status. As your system is modernized, your system can become more real-time.