Wrapping up the posts on Legacy Migration Strategies, this article will focus on the Anti-Corruption Pattern.
The anti-corruption pattern describes some custom code to interface between a legacy application and a new target application. The reason why the pattern is called anti-corruption, is due to the corruptive nature of new development being forced to conform to a pre-defined legacy interface. Where this pattern helps is by allowing the new system to retain a new and more accurate perspective of the business while retaining the legacy system. In addition, if the new service is provided by another vendor where the business is not responsible nor able to update, then this service can act as a translator between the two world. However, this pattern is the proverbial double-edged sword. Without care, it can add complexity and instead increase dependence on the legacy system which makes future updates and replacement next to impossible.
How does the anti-corruption pattern differ from the strangler pattern? With the strangler pattern, the gateway acts as a go-between the new services and legacy application with the ultimate goal of the gateway and the underlying system being decommissioned eventually. To support this ultimate goal, the strangler pattern relies on the underlying data and communication with the legacy system to not require translation. However, if the data does need to be translated, then a new service will be required to provide this anti-corruption layer.
How would this be implemented while keeping an eye towards the future with regards to flexibility and performance? As with other custom software projects, this would depend on the system being interfaced, whether it would make more sense to leverage passing all communication to the application itself, or if it is possible to update the underlying data instead. In any case, a fair amount of reverse engineering may be required to determine how to interact with the underlying system whether it is a SaaS
offering or interacting with the underlying database.
It is possible the research for interacting with the legacy system could take
the majority of the time to develop the adapter. However, with this research
complete, and if the goal is towards retiring the system, then this can be used to remove the application while allowing for the underlying data to either persist, or replicated onto newer and more supported technology that would better enable a clean interface for the new services being brought online.
What this means is that both patterns can be used concurrently to strangle the legacy system, while providing a clean interface with a company’s new
infrastructure that can grow over time.