継続を決意するビルド

ライブになった後に継続するために必要でな仕方で、レガシーを置き換えてください。

このページはスタブです。この資料の後のリビジョンで全面的な拡張を予定しています。ただし、これらのパターンはまだ開発途上段階にあるため、これらのアイデアをどのように枠組み付け、説明するのが最善かについて学び続けるにつれて、パターンが名前変更、分割、またはマージされる可能性があります。

レガシー置き換えのビジネスケースには、ビジネスの要件のリリースがより低コストで、より迅速に、より頻繁に含まれることがほとんどです。経験から、1つの「ビッグバン」リリースに向けて構築し、その後リリース後により迅速で頻繁なアップデートに切り替えることを期待することは現実的ではないことがわかります。実稼働環境への最初のリリースに1年かかった場合、次のリリースには少なくとも数か月かかると予想する必要があります。あまりにも一般的なこの失敗のシナリオは、ビジネスの利害関係者にフラストレーションを与え、投資に対する期待されるリターンを達成できなくなります。

この結果を回避するために、継続するために必要な方法で構築することをお勧めします。改善されたリリース頻度、より低コストのリリース、またはより迅速な変更が必要な場合、それらを実現するための唯一の方法は、置き換えの取り組みの最初からその方法で構築してデプロイすることです。

さらに、主要なシステムが置き換えられている間、変更の停止または変更の低速化の期間を許容できる企業はほとんどありません。競合他社は新機能の追加を停止せず、規制当局は組織が複数年のレガシー置き換えプログラムに着手したからといって新しい規則を停止できません。多くの組織は、実行中にビジネスとテクノロジーの変更に対応するレガシーへのアプローチを必要としています