http://wiki.c2.com/?VendorLockIn
いくら立派な機能を持ったソフトウェアに見えても、足元が頼りないと、驚くほど脆く壊れてしまうことを象徴して、アンチパターン本では、ベンダーロックインのことを、日本語で砂上の楼閣と翻訳されています。
「固い岩の醜い家が安全に建っている：それにひきかえ、わが輝く宮殿の砂の上に建つを見よ！」
—— Edna St. Vincent Millay
特定ベンダーに依存して無警戒に豪華な機能を使ってしまうと、依存が依存を招き、もとあった依存を超えて、ソフトウェア全体がベンダーの呪縛から逃れられなくなってしまいます。こうしてベンダーロックインが起こると、開発の主従関係が逆転してしまいます。開発者は、仕様変更の権限を握っているベンダーの一挙手一投足にビクビクしながら、砂上の楼閣を保守しなければなりません。
ベンダーは自社の利益と大多数のユーザーの満足を目的とします。また、ほとんどのユーザーにとって不利益でなければ、ベンダー内の複数のプロダクトで足並みが揃わず、一貫性を失った状態になるときもあります。もし自分の開発したものがこの「大多数」からあぶれたらどうなるでしょう。主導権がベンダー側にあると、それは死の宣告となり、大規模なデッドエンドを迎える可能性もあります。
これは、心理的な問題や政治的な問題ではなく、アーキテクチャの問題である点が重要です。アーキテクチャによって、主導権をつねに開発者側で握れるのだから、みすみすその機会を逃すのは開発者の責任、設計の失敗です。ビジネスロジックに近い箇所ほど、ベンダー中立なレイヤーを通すようにしておき、代替手段に置き換え可能にしておくのです。ベンダー固有の機能に依存するコードは、この中立レイヤーのインターフェースを実装するかたちにして依存を逆転させ、開放閉鎖原則 (書き換えには閉鎖的に、拡張には開放的に) を尊重しましょう。ちなみに、この中立レイヤーの機能セットがアプリケーションのドメインモデルに依存するのは問題ありません。なぜなら、ドメインモデルの権限は完全にこちら側にあるのですから。
繰り返しになりますが、ベンダーロックインは、それを見過ごすアーキテクチャを作った開発者の責任です。ベンダーがいつ 梯子外し をするかわからないのは、すでに知っているので。例えて言えば、セキュリティホールを放置していた箇所をクラックされたとして、クラッカーが悪いんだから私は悪くない、なんて言い訳してたらエンジニアの恥ですよね。ベンダーロックイン対策もそれと同じです。