ベンダーのロックインを避けるためのチェックリスト？

ベンダーのロックインを回避するための一連の業界承認のルールはありますか？

つまり、マネージャーや他の意思決定者に見せることができ、理解しやすく、検証しやすいものです。

• 客観的で測定可能な方法でベンダーのロックインを検出および防止するのに役立つ、広く受け入れられているルールのセット、チェックリストまたは条件のセットはありますか？

• プロジェクトの初期段階でベンダーがロックインするリスクについてマネージャーに警告しましたか？

コンサルタントとしての仕事では、ベンダーロックインのリスクについてクライアントに頻繁に警告します。これは、失敗したプロジェクトを回避するために呼び出されたという苦い経験からです。最初にこれについて考えなければ、おそらく長期的にはコストがかかります。

「標準チェックリスト」はありませんが、ここに私が探している主なものの良いチェックリストがあります：

• オープンAPI：競合ベンダーが自由に実装できるという意味で、使用する（つまり依存関係を構築する）APIはオープンですか？
• 標準への準拠 -製品は関連する業界標準に準拠していますか？
• 互換性のある代替の存在 -実際に、最小限の変更で切り替えることができる別の互換性のある製品（商用またはオープンソース）がありますか？
• オープンソース -ベンダーのコードはオープンソースですか（つまり、OSI承認済みライセンスの下にありますか）？
• プラットフォームの独立性 -テクノロジースタックは異なるプラットフォーム間で移植可能ですか？
• 契約の柔軟性 -重大なペナルティなしで契約を早期に終了または縮小できますか？
• 独立したサービスの提供 -さまざまなベンダー（つまり、元のベンダーだけでなく）からサービスを購入するための信頼できるオプションはありますか
• 能力とスキル -元のベンダーと会社を分ける場合、社内または別のベンダーと効果的に作業を続けるために必要な能力とスキルはありますか？
• 良い行動の記録 -ベンダーは、彼らが得る可能性のあるロックインを悪用しないことを信頼できることを示唆する良い実績を持っていますか？
• 要件の安定性 - 要件は明確に定義されており、同じままである可​​能性がありますか？（もしそうなら、これらの要件について事前に契約することができ、ベンダーのロックインはそれほど重要ではありません...）

これらの質問のほとんどまたはすべてに対する答えが「はい」の場合、ベンダーのロックインを回避することを合理的に確信できます。そうでない場合は、注意する必要があります。

これらは、ロックインを評価するときに使用するいくつかのガイドラインです。

ベンダーは業界標準形式を使用していますか？

外国語を話さなければならないファイルやコードが大量にある場合、切り替えは非常に困難です。XMLやJSONなどの標準形式がある場合はそうではありません。たとえば、ASP .Netはaspxを使用します。これは、htmlでもマークアップでもないマークアップです。これにより、これらのファイルの変換または解析が非常に困難になります。

ベンダーは、システムと統合するのに十分なポイントを提供していますか？

システムからデータを解放し、Webサービスなどの何らかの相互運用を介して独自のシステムと十分に統合できますか？システムと統合したい場合、より多くのベンダー製品を追加する必要がありますか？

別のソリューションに変更するのはどれくらい難しいですか？

ベンダーから遠ざかるのがどれほど難しいかを知るためには、継続的な健全性チェックが必要です。ベンダーのものがインフラストラクチャ全体に浸透している場合、疲れるはずです。

要するに、ベンダーと製品に関するレビューとフィードバックを探します。

技術的に言えば、ベンダーロックは、プロジェクトがベンダー（サードパーティ製品）と密結合している場合に発生します。

それを避ける方法は？代替案を作成し、各代替案について1つの質問を調査することにより、別の解決策を変更するのはどれくらい難しいですか？

ベンダーが推進している製品の技術的な詳細に加えて、他の顧客がこのベンダーで経験した成功/失敗の軌跡を知ることは非常に重要です。達成するのは難しいかもしれません（ゴーグル、レビューを読んだり、レビューが本物であるかどうかを確認するなど）。ただし、米国にはBBB（Better business Bureau）と呼ばれる信頼できる評価システムがあります。

この独立したビューローの米国に拠点を置く企業の記録は非常に有用であり、95％が現実を反映しています。したがって、私も彼らに確認することを強くアドバイスします。