This episode covers the vendor lock-in anti-pattern. It is another one that we have seen before. However, it is slightly different when you apply it to software architecture. This situation is fascinating as we can fall into it thinking we are making the best decisions. However, comfort and ease are not always the best way to assess our solution.
Vendor Lock-in Defined
This anti-pattern occurs when we craft an architecture that hinges on a vendor or third-party product. Sometimes the vendor is an open-source tool or approach. While that is far better and can save us from being locked into their solution, it is still important to recognize. We will be better off when we are free to craft our solution to our problem than we are chained in some way to a general offering. In short, vendor lock-in occurs when we are bound to our solution, and someone else controls its growth and support.
The Anti-Pattern In ActionThere are many ways this can appear in your solution. However, the symptoms tend towards heavy reliance on third-party support or releases. When you are often referring back to a vendor to plan your approach and schedules, you are likely in the vendor lock-in situation. There are cases where this is acceptable. However, vendor fluctuations and business objectives can dramatically impact your solution and even cause it to fail. No solution or organization is too big to fail. Therefore, proceed with caution when you rely heavily on a vendor or vendors.
Avoiding The Anti-Pattern Vendors exist to assist us. They provide products and services that increase productivity and reduce costs. Thus, we do not need to avoid them altogether. We need to be strategic in our use of them. It is best to include contingency plans as well. Lock-in can be a minor issue if we have ways to quickly move off of or away from a vendor. Of course, having complete control of our solution, such as offered by open-source technologies is always the safest way to avoid reliance on outside parties.
