Vendor Lock-In

This anti-pattern is often seen as the entire system is solely dependent on a vendor's solution. Hence, when changes arrives from the vendor side, be it good or bad, there is a tendency that the system will breaks due to the new changes.

Symptoms and Consequences

• Commercial product upgrades drive the application software maintenance cycle.
• Promised product features are delayed and never delivered, causing release issues.
• The product varies significantly from the advertised open system standards.
• If the update failed to applied into the system, a re-integration effort is required to make things working.

Causes

• Hard to comply to open system standards because there is no effective conformance process for the standard.
• Product is selected solely based on marketing and sales information and without technical inspection.
• No technical approach for isolating application software from the direct dependency upon the product.
• Application programming requires specific in-depth product knowledge.
• Complexity and generality of the product technology exceeds of the application needs.

Exception

The vendor lock-in is acceptable if a single vendor's code made up the majority of the code needed in an applications.

Refactor Recipes

• Review the vendor lock-in technology from risk and technical perspectives. Identify the gap to have possible isolation.
• Isolate vendor lock-in technologies from the system so that vendor's changes does not directly influence the product.
• Plan and change the release life-cycle, factoring in vendor's changes into the release and makes the integration painless.
• Maintain consistency with system integration between the product and 3rd-party vendor software.