Wrap Legacy APIs
Last updated
Was this helpful?
Last updated
Was this helpful?
Your enterprise probably has legacy software assets that are extremely valuable and can be the basis for your initial project deliverable. If you don’t take care and start reusing straight away you will end up with lots of point to point connections…
Now, all the consumers are directly consuming your legacy asset with all the ill effects of tight coupling. You want to change or upgrade the legacy asset? it might break every consumer and force them to make changes to their code. Plus, you will expose your legacy error codes, naming conventions, behaviors to all your consumers.
Bad idea. So what do you do?Don’t reuse legacy software assets as-is;wrap them first!
Create a component that wraps the legacy asset – it now sits in be the legacy asset and the consuming code (which could be your app, an external process, a batch job, whatever…). This wrapper component needs to provide a contract that is in alignintment your enterprise’s data standards, should reuse your enteprise’s data types, use standard error codes, and most importantly should not expose legacy naming and/or implementation semantics.
Why this is important? Well, if you don’t have a wrapper that truly encapsulates the legacy functionality it will serve only as a pass-through layer adding no value. The wrapped asset now can be reused by multiple consumers and you have the flexibility to change the implementation. If you keep your interface constant, your consumers won’t need a code change and only need to regression test.
