増分の置換

ライブになった後に継続するために必要な方法で、レガシーの置換を作成します。

このページは スタブです。後ほどこの資料の改訂版で完全に拡大する予定です。ただし、これらのパターンの開発はまだ途中の段階にあるため、これらのアイデアをどのように枠組み、説明するのが最善かを学習し続けるにつれて、パターンは名前変更、分割、またはマージされる可能性があります。

レガシーの置換のビジネスケースには、ほとんどの場合、ビジネス要件のより安価で、より迅速で、より頻繁なリリースが含まれます。経験から、1つの「ビッグバン」リリースに向けて構築してから、リリース後により迅速で頻繁な更新に切り替えるのは現実的ではないことがわかります。本番環境への最初のリリースに1年かかった場合、次のリリースには少なくとも数か月はかかるはずです。

継続するために必要な方法で構築することをお勧めします。リリース頻度の向上、より安価なリリース、より迅速な変更が必要な場合は、これらの成果を確実に得る唯一の方法は、置換作業の開始時点からその方法で構築してデプロイすることです。

さらに、主要なシステムが置換されている間、非常に少数の企業だけが変更の凍結または（さらに）遅い変更の期間を余裕を持つことができます。競合他社は新しい機能の追加を停止しませんし、組織が数年間に及ぶレガシーの置換プログラムに着手したという理由だけで、規制当局も新しいルールを一時停止することはできません。多くの組織は、進歩しながらビジネスと技術の変化に対応できるレガシーのアプローチを必要としています。