ベンダーロックインを回避するためのチェックリスト？
ベンダーロックインを回避するために業界で承認された一連のルールはありますか？
つまり、マネージャーや他の意思決定者に示すことができる、理解しやすく検証しやすいものです。
客観的かつ測定可能な方法でベンダーロックインを検出および防止するのに役立つ、広く受け入れられているルールのセット、チェックリスト、または条件のセットはありますか？
プロジェクトの初期段階でベンダーロックインのリスクについてマネージャーに警告した人はいますか？
私はコンサルタントとしての仕事で、ベンダーロックインのリスクについてクライアントに頻繁に警告しています。これは、失敗したプロジェクトを回避するために呼び出されるという苦い経験によるものです。最初にこれについて考えなければ、おそらく長期的にはコストがかかります。
「標準チェックリスト」はありませんが、ここに私が探している主なものの良いチェックリストがあります：
- Open API：使用する（つまり依存関係を構築する）APIは、競合するベンダーが自由に実装できるという意味でopenですか？
- 標準への準拠-製品は関連する業界標準に準拠していますか？
- 互換性のある代替品の存在-最小限の変更で切り替えることができる別の互換性のある製品（商用またはオープンソース）は実際にありますか？
- オープンソース-ベンダーのコードはオープンソースですか（つまり、 OSI承認済みライセンス の下で）？
- プラットフォームの独立性-テクノロジスタックはさまざまなプラットフォーム間で移植可能ですか？
- 契約上の柔軟性-大きなペナルティなしに契約を早期に終了または縮小できますか？
- 独立したサービス提供-異なるベンダーからサービスを購入するための信頼できるオプションがあります（つまり、元のベンダーだけではありません）
- 能力とスキル-元のベンダーと提携する場合、社内または社外のいずれかで効果的に作業を続けるために必要な能力とスキルはありますか？別のベンダーと？
- 良い行動の記録-ベンダーは、彼らが得る可能性のあるロックインを悪用しないように信頼できることを示唆する良い実績を持っていますか？
- 要件の安定性-私たちの要件は明確に定義されており、同じままである可能性がありますか？ （もしそうなら、これらの要件を前もって契約でき、ベンダーのロックインはそれほど重要ではありません...）
これらの質問のほとんどまたはすべてに対する答えが「はい」である場合、ベンダーロックインを回避することは合理的に確実である可能性があります。そうでない場合は、注意が必要です。
これらは、ロックインを評価するときに使用するいくつかのガイドラインです。
ベンダーは業界標準のフォーマットを使用していますか？
外国語を話さなければならない大量のファイルやコードになってしまうと、切り替えが非常に難しくなります。 XMLやJSONなどの標準フォーマットがある場合はそうではありません。たとえば、ASP。Netはaspxを使用します。これは、htmlでも有効なXMLでもないマークアップです。これにより、これらのファイルの変換や解析が非常に困難になります。
ベンダーはシステムと統合するのに十分なポイントを提供していますか？
システムからデータを解放し、Webサービスなどの相互運用の形式を介して独自のシステムと十分に統合できますか？システムと統合したい場合、プレミアムでより多くのベンダー製品を追加する必要がありますか？
ソリューションを別のソリューションに変更するのはどれほど難しいですか？
ベンダーから離れるのがどれほど難しいかを確認するには、継続的な健全性チェックが必要です。ベンダーのものがあなたのインフラ全体に行き渡っているなら、あなたは疲れているはずです。
要するに、ベンダーと製品に関するレビューとフィードバックを探します。
技術的に言えば、ベンダーロックは、プロジェクトがベンダー（サードパーティ製品）と密結合している場合に発生します。
それを避ける方法は？代替案を用意し、各代替案について1つの質問を調査することで、別の代替案のソリューションを変更するのはどれほど難しいですか。
ベンダーが宣伝する製品の技術的詳細に加えて、このベンダーで他の顧客が成功/失敗した経緯を知ることは非常に重要です。達成するのが難しいように見えるかもしれません（ゴグル、レビューの読み取り、レビューが本物かどうかの識別など）。しかし、米国には BBB（Better Business Bureau） と呼ばれる信頼できる評価システムがあります。
この独立したBureauにおける米国を拠点とする企業の記録は非常に有用であり、95％は現実を反映しています。したがって、私もそれらを確認することを強くお勧めします。