In practice, there are at least three better alternatives. The easiest is to resign yourself to using the proprietary API. At least this interface has been thought out and refined over the years by the product vendor…generally better that what you can expect out of a system integrator operating on constrained project budgets and schedules in an area that is not their core competency. If the day comes where you need to change products, only then do you write the isolation layer…but now it translates from the legacy product API to the new product API. This way you only incur the cost when you have to, and you’ll still spend less time and money because you have two well-defined interfaces to bridge.
This topic comes up periodically, usually just before or after introducing a new major commercial off-the-shelf (COTS) product into a solution. Forward-thinking managers or software architects become concerned about avoiding “vendor lock-in” that could result in higher license costs, increased dependence on obsolete products, or an expensive software migration in the future. Unfortunately, this is a case where the cure can be worse than the problem.
The knee-jerk response is to write an “isolation layer” that in theory reduces the dependency on vendor-specific application programming interfaces (APIs). But this merely aggravates the problem: now you are dependent not only on the product (because you inevitably can’t hide the vendor-specific functionality) and you are also dependent on a raft of custom software that comprises the isolation layer. This custom isolation layer ultimately has the same the characteristics you sought to avoid in the vendor API in regard to future cost and support concerns. Meanwhile, you doubled your cost and schedule by effectively undertaking a standards-definition effort within the scope of your development project.
An even better approach is to use the natural utility classes in your application to serve as the isolation layer. You have to write this code anyway, and if written correctly you can isolate the impact to a relatively small set of code. The third and perhaps best approach is to leverage a standards-based API. This buys you real isolation, and with a little luck it is something that the vendor or a third-party has already implemented. The downside is that you may sacrifice some proprietary functionality when using the standards-based API, but you can always extend this approach with one of the other two alternatives if really needed.
Ultimately, a good solution depends on both the right approach and a faithful implementation of the approach. But beware of integrators selling vendor independence through isolation layers…they are likely just moving the dependency, not eliminating it.
Posted in Blog Posts.