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 Action
There 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.
