Martin Fowler氏は先頃、"Patterns of Legacy Displacement"という一連の記事を公開した。レガシシステムのリプレースに関連した、著者らの集合的体験を要約したものだ。プロジェクトを3つのフェーズに分割し、それぞれについて列挙されたパターンに従うことで、成功の可能性は高くなる、と著者らは主張する。
記事には、レガシシステムを成功裏にリプレースするための、3つの重要なステップが説明されている — 望ましい結果を理解すること、問題をブレークダウンすること、段階的にデリバリすること、である。これらステップをサポートするものとして記事で取り上げているのが、設計とプロセスのマッピングパターンだ。最初の記事では組織構造に注目して、問題分割のための"Extract Product Lines"および"Feature Parity"の各パターンについて詳説している。
Ian Cartwright、Rob Horn、James Lewisの3氏が執筆したこの記事には、レガシシステムのリプレースはすべて、継続的デリバリを可能にし、ビジネスプロセスの望ましい現実に一致する、ビジネスプロセスないし組織構造の変化に向けた改善を含むべきだ、と述べられている。著者らは、"[自分たちの]見た限り、テクノロジはレガシ問題のせいぜい50パーセントを占めるに過ぎません。働き方や組織構造、リーダシップが、成功のためには同じくらい重要なのです"、と指摘する。"
組織の他の部分がこれまでどおりの仕事を続けながら"ビッグバン"リプレースを目指すのは、多くの場合において失敗のレシピであるということを、著者らは認識している。旧システムと新システムが時間とともに大きく乖離する一方で、組織内での仕事の方法は、レガシシステムの制約を回避すべく有機的に進化しておいくため、新たなシステムに移されたビジネスプロセスに同期しないことが少なくないのだ。"チームとそのコミュニケーションが既存のレガシソリューションやレガシシステムを中心に編成されている場合には、新たなソリューションとそのアーキテクチャに調和するように、逆コーンウェイ戦略(Inverse Conway Maneuver)を使ってそれらを再編成する必要があるかも知れません"、と著者らは述べている。
レガシシステムをリプレースする最初のステップは、望ましい結果について理解することだ、と記事は指摘する。"レガシに取り組む際には、達成したい結果に対する組織的合意が不可欠です。当然と思われるかも知れませんが、部署によって求める成果に対する見解が異なることが極めて多いのです。" レガシシステムのリプレースによる成果とされるのは、ビジネスプロセスの改善、サポートの終了したシステムの廃棄、新たなプレイヤによる市場の混乱の克服、といったものが一般的だ。新たなテクノロジの導入そのものを目標にするべきではない、と著者らは付け加える — そうではなく、現在および予想される将来のビジネスニーズをサポートすることが必要なのだ。
第2のステップは、問題を小さな部分に分解することだ。記事では、"同じ物理システムによって複数の論理的プロダクトを提供するために、多数のアプリケーションが開発されます。これは多くの場合、再利用の要求によるものです。(...) ここで大きな問題になるのは、それらのプロダクトが表面上は同じように見えても、詳細においては大きく異なっている場合です"、と述べられている。ここで"Extract Product Lines"パターンを使えば、レガシシステムシステムをスライスし、並行的な(再)開発とインクリメンタルなデリバリを可能にすることによって、このリスクを低減することができる。スライスの抽出は、システム内のプロダクトないしプロダクトラインと、それらのビジネス機能を検出することによって行う。次に、プロダクトから抽出したものをリスクによって優先順位付けした上で、2番目にリスクの高いもの、ビジネス面にも配慮しながら、問題発生時に重大な障害が発生するリスクのないものから着手する。
機能の同等性を求めることは、簡単に捉えられがちな目標であり、一部のユースケースを除けば推奨されるものではない、と著者らは記している。"機能の一致が真の要件であるならば、このパターンは、それを成功させるために何が必要かを示しています。簡単ではありませんし、安易に受け入れるべきでもありません。" ユーザの経緯、システムの入出力、インテグレーション、バッチプロセスに関して、徹底的なシステム調査を行うことが必要になる。さらに、このような調査は、多くの場合において、内部動作を発見するシステム考古学、実際に使用されている機能を見つける仕組み、廃止可能な機能を判断するための機能/価値マッピング、といったもので補完しなければならない場合が少なくない。当然ながら、新システムが旧システムと同じように動作することを保証するためのテストも実施しなければならない。結論として著者らは、このパターンは極めて高価であるため、すべての機能が十分に把握できているか、あるいは変更がユーザにそれほど影響しない場合に限って使用するべきだ、としている。
これまでの経験の中で、著者らは、この発見プロセスにおいてEvent Stormingが広範に役立つことを見出している。問題を理解するということは、"現行のシステムとアーキテクチャについて、最短の時間で可能な限り理解すること"だ、と著者らは主張する。"しかし実践は極めて難しく、過度に詳細な部分で行き詰ることが多いのです。" ビジネス機能を既存のアーキテクチャにマッピングして、そのアーキテクチャがどのように価値を創造しているかを最初のステップで理解するためには、Event StormingやWardley Mappingといったツールと、ユーザからのフィードバックが重要だ。
記事には、各ステップで使用可能な他のパターンの一覧が挙げられているが、詳細には触れていない。著者らはThoughtWorksのテクニカルディレクタで、今後も自分たちの作業方法をパターンとして公開する予定だという。