Fix Integration Problems With Adapters

The Adapter Pattern is instrumental in the building of modular systems.

Many years ago, I came across an intractable integration problem that was solved using an Adapter. A company I was consulting to was in the process of replacing its legacy computer systems. All their operational systems were bespoke. Many of these were more than two decades old. The code was in bad shape. A decision had been made to rewrite and replace the system.

The engineering leadership team decided that as a first step, the heart of the systems architecture, a central application, would be supplanted with a new bespoke API. Once we had completed that step, we programmers would replace the old peripheral UI applications.

Until that time, the new core system would need to integrate and function with the old UI applications.

I found an interesting situation where the old core system exchanged incorrect values with one of the legacy GUI applications. However, the overall system worked as expected. What was going on? After some digging in the code, I found that the GUI application receiving the wrong data values corrected for the miscalculation!

What would happen is that the core system reversed the sign on financial transaction amounts. For example, when it would communicate -$10,000 to the UI program, the recipient application knew to flip the sign. Customer service representatives working with the GUI application would see the correct figure of +$10,000.

We understood that the replacement API would need to integrate with the old UI application before we could rewrite it. However, we didn’t want to build this sign-reversal problem into our new shiny core system. That felt wrong.

However, we had to do something. If the new core system communicated +$5,000, the GUI application would reverse the sign and display an incorrect -$5,000.

Besides, we were planning to replace the old GUI application. It struck me as wholly inappropriate that we should carry over a legacy conversion problem into our new, clean API.

There had to be a better way.

And there was—the Adapter Pattern to the rescue.

The replacement API provides the correct sign for transaction amounts. Yet, a temporary middleware adapter flips the sign on monetary amounts while integrated with the old GUI. This adapter reproduces the existing flaw.

For example, when the new core system communicates +$20,000, this integration adapter reverses the sign, and the amount received by the existing UI is -$20,000. This application would switch the credit/debit sign again and display +$20,000, the correct amount, on the screen.

Once we had written and deployed the new GUI, we removed the sign-reversing adapter as it was no longer required.

Here is a depiction of the steps we went through to build the new system.