レガシー置換のパターン

達成したい成果を理解する

レガシーに取り組む際に達成したい成果に組織が合意することは非常に重要です。これは当然のことのように思えるかもしれませんが、あまりにも頻繁に、組織のさまざまな部門が望ましい成果についてまったく異なる見解を持っている可能性があります。ほとんどのレガシーモダナイゼーションイニシアチブには、以下に示す成果のいくつかが含まれていますが、旅を始める前に、どの成果が優先事項であるかを特定することが不可欠です。

問題をより小さな部分に分割する方法を決める

大まかに言えば、これには、現在のビジネスおよび技術アーキテクチャにおける適切な「境界」を見つけることが含まれます。重要なのは、現在のソリューションの要素が、さまざまなビジネスケイパビリティにどのように対応するかを検討する必要があるということです。レガシーシステムの場合、通常、これは1つの大規模な技術ソリューションがどのように複数のビジネスニーズを満たしているかを発見し、新しいソリューションを使用して個々のニーズを独立して実現できるかどうかを確認することを意味します。理想的には、これらは互いに依存関係を最小限に抑えて配信できる必要があります。

よくある異論は、これらの境界を見つけるのは難しすぎることです。最初は難しいことに同意しますが、私たちは、あまりにも頻繁に機能パリティとビッグバンリリースにつながる他の代替案よりも、より良いアプローチであることがわかりました。また、多くの組織が、技術やビジネスプロセスを単独で検討しているために、そのようなアプローチを却下していることも観察しました。技術の一部だけを変更したり、ビジネスプロセスを1つだけ個別に更新したりしても失敗する可能性がありますが、両方を考慮して実装できれば、「象を食べる」方法があります。

パーツを正常にデリバリーする

より迅速な変更の必要性、および大きな依存関係なしにビジネス要素を段階的に提供および独立して変更できる能力は、多くの場合、マイクロサービスベースのアーキテクチャと並行した「アジャイル」なデリバリーアプローチにつながります。継続的デリバリーは、これらの個別に展開可能なコンポーネントにとって必須になります。通常のソフトウェアデリバリー以外でこれを困難にしているのは、既存の大規模ソリューションからの切り替え、共存、そして最終的には要素の置き換えのための戦略を見つけることです。並行実行、イングレス時のフォーク、フローの迂回など、いくつかの成功した戦略が存在します。

† 現在はスタブのみ

これを継続的に行うための組織変更

もし立ち返って新しいビジネス要件を提供するプロセス全体を振り返ってみると、これが一部にすぎない技術的な問題であることがすぐにわかります。より新しいテクノロジーを使用してソリューションを構築する時間とコストを削減すれば、要件に合意し、変更を本番環境に移行することに関する問題が浮き彫りになります。

より優れた技術を最大限に活用するためには、組織構造とプロセスの変更が必要であり、コンウェイの法則によれば、これを促進する技術アーキテクチャも必要です。チームとそのコミュニケーションが既存のレガシーソリューションとプロセスを中心に組織化されている場合、新しいソリューションとそのアーキテクチャに合わせて、逆コンウェイ戦略を使用して再編成する必要があるかもしれません。

レガシーシステムは、特にeXtreme Programmingや継続的デリバリーに関連する最新のエンジニアリングプラクティスを採用する能力を制約し、制限する可能性があります。レガシーシステムを置き換える際には、変更が遅く、困難で、費用のかかるシステムに戻らないように、働き方を変えることが重要です。

レガシーは組織の文化とリーダーシップの産物でもあり、より広範な変化がなければ、以前と同じ結果になることが予想されます。「企業の抗体」が新しい動きを察知し、組織から排除しようとするため、多くのレガシーモダナイゼーションの取り組みが失敗しているのを私たちは観察してきました。

組織全体が変化を拒否する一例を挙げると、私たちは携帯電話用のソフトウェアを構築したいと考えていた非常に大規模な通信会社と協力しました。リーダーシップ層は皆、これは固定インフラストラクチャに焦点を当てた既存のプログラムよりも、はるかに高速なフィードバックサイクルとより頻繁な変更を意味することを理解していました。

リーダーシップ層はこれを理解していましたが、既存の作業慣行や、それらのプロセスを実行する中間管理職には変更が加えられませんでした。そのため、既存の変更管理プロセスが厳格に適用されました。結局、ソフトウェアチームはソフトウェアを作成するよりも、変更管理フォームへの記入や変更管理会議への参加に多くの時間を費やしていました。「企業の抗体」は、新しい働き方を拒否することに成功しました。

組織の変革は大きなテーマであり、すでに多くの文献が存在しますが、レガシーに関する主な課題は、時間に関連することが多いです。組織構造や主要なビジネスプロセスに加えて、デリバリーアプローチ全体を修正（またはアウトソーシングの犠牲者の場合は再構築）している間、レガシーのモダナイゼーションを遅らせる余裕のある組織はほとんどありません。組織変革というより広範なトピックは私たちの範囲を超えていますが、レガシーのコンテキストで新しい働き方を適用し、保護するためのいくつかの戦略を推奨します。レガシーだけを変更して他に何も行わない場合、数年後に再びレガシーを置き換えることになると予想するのは当然です。

† 現在はスタブのみ

組織変革には他にもさまざまな戦略とアプローチがありますが、私たちは、これらの2つがレガシーのモダナイゼーションを後回しにすることなく、ある程度早く開始できるため、強調しました。

成果を理解する

私たちのチームが直面した課題は、サポートが終了し、変更が難しく、非常にコストのかかる統合ミドルウェアを、ビジネスにとってサポート可能で柔軟な新しいソリューションに置き換える方法でした。既存のビジネス運営を中断したり、リスクにさらしたりすることなくです。問題のミドルウェアは、バックエンドシステムとストアフロント間の統合に使用されていました。これらのシステムは、毎日数千万ポンド相当の価値のある高価値のユニークな製品の販売を共同で担当していました。

この作業は、大規模なプログラムの中でも優先度の高い部分でした。ビジネスをサポートするバックエンドシステム全体が置き換えられており、ストアフロントも数年以内にモダナイゼーションプログラムの対象となる予定でした。

したがって、上記のステップ1に従って、チームが達成する必要のあるビジネス成果が定義されました。

1. ビジネスプロセスを改善する

どのように？この特定の統合ミドルウェアソリューションには、ビジネスの中核となるルールなど、製品をどのチャネルで販売するか、ストアフロント内で製品をいつどのように販売するかなど、重要なロジックが含まれていました。この既存のシステムは変更が非常に難しく、ビジネスのイノベーションを妨げており、ロジックの欠陥により、製品が販売されていない期間があるなどの問題が発生していました。

2. できるだけ早く古いシステムを廃止する

なぜ？既存の（そして増加している）ライセンスおよびサポートコストを削減するため。さらに、サポートが終了したミドルウェアおよびデータベース技術で重要な機能を運用することによってビジネスに発生するリスクを軽減するため。

問題の分割：最初の縫い目とリファクタリング

インセプション中、チームはレガシーシステムに関する深い知識を持つ人々とワークショップを開催し、現状と将来のソフトウェアアーキテクチャを共同で視覚化しました。これを行った結果、レガシーバックエンドと統合ミドルウェア間のメッセージングベースの統合という形で利用できる技術的な継ぎ目を発見しました。老朽化したJ2EEアプリケーションであるレガシーバックエンドは、「製品を公開する」メッセージを非常に古いバージョンのSwiftMQによって提供されるキューに配置しました。イベントインターセプションパターンはここで役立ち、コンテンツベースルーティングとして実装すると、レガシーバックエンドからのメッセージのルーティング方法を制御できるようになり、メッセージを新しいシステムにルーティングできるオプションが作成されます。

統合ミドルウェアは、ストアフロントからのメッセージ（例：製品の販売）も処理し、JDBCを使用してレガシーバックエンドの背後にあるマスターデータベースの状態を直接更新しました。SwiftMQを介した非同期メッセージングとJDBCデータベースの更新が、レガシーバックエンドと統合ミドルウェア間のインターフェイスを形成しました。

当時発見されませんでしたが、チームはレガシーミドルウェアの置き換えを可能にする戦略として、サブシステム規模で抽象化による分岐パターンを使用することができました。抽象化レイヤーは、キューとJDBCです。新しい実装がその抽象化レイヤーに準拠していることを確認することで、ビジネス運営に影響を与えることなく、「欠陥のあるサプライヤー」と交換することができました。

チームが最初に行ったことは、リファクタリングによってイベントルーターを追加することで、イベントインターセプションを実装することでした。

イベントルーター（1）は、3つの主な機能を念頭に置いて作成されました。

1. あるSwiftMQキューからメッセージをデキューし、別のSwiftMQキュー（2）にエンキューします。（2）この新しいキューからメッセージを消費できるように、一部の構成を簡単に変更することで、統合ミドルウェアを有効にしました。

全体として、リファクタリングによって目に見えるシステム動作は変更されませんでしたが、メッセージ処理パイプラインに挿入されたことで、イベントルーターは移行アーキテクチャの一部になりました。

2. イベントルーターのビジョンは、構成を通じて、メッセージを代替宛先にルーティングできるようにすることでした。これにより、新しい実装で公開メッセージを処理できるようになります。イベントインターセプション
3. イベントルーターは、古いSwiftMQテクノロジーからターゲットアーキテクチャ用に選択された新しいActiveMQテクノロジーへの橋渡しにもなります。

イベントルーターの実装は、当初予想していたほど簡単ではありませんでした。利用可能なドライバーやライブラリが不足していたため、SwiftMQとの統合は問題が多く、そのアプローチは何度も見直しを迫られました。しかし、チームは、このアプローチがもたらす可能性のある価値を理解し、作業を完了して本番環境にリリースしました。新しいコンポーネントを実環境で監視し、新しい継続的デリバリーパイプラインを利用して、その機能を段階的に強化する準備を整えました。

パーツを正常にデリバリーする：機能の構築、契約の維持

新しいストアフロントマネージャー（1）は、チームによって反復的に構築されました。この例に関連して、その構築には、レガシー模倣パターンを実装するマスターデータベースアダプター（2）が含まれていました。これは、抽象化レイヤーの一部として、ストアフロントから受信した販売情報でマスターデータベースを更新するために必要でした。イベントルーターはメッセージを変換しないため、レガシーイベントアダプター（3）（メッセージトランスレーター）が作成され、レガシーの世界を新しい世界にさらさず、新しいアーキテクチャの原則に沿ってメッセージを新しい形式に変換しました。また、新しいストアフロントマネージャー（1）とレガシーストアフロントの間には、新しい実装を、ストアフロントが置き換えられる際に将来発生する変更から隔離するために、レガシーストアフロントアダプター（4）も実装されました。

新しいストアフロントマネージャーが使用するレガシーストアフロント（5）に新しいAPIが導入されました。さらに、新しいAPIで公開された製品のコールバックを新しいストアフロントマネージャーのアダプター（4）に送信できるようにする機能が追加されました。重要なことに、これにより、レガシー実装と新しい実装を並行して実行できるようになりました。

パーツを正常にデリバリーする（続き）：ライブサービスへの移行 - 2つ目の縫い目を使用

すべての要素が揃ったことで、ビジネス側は新しいソリューションをテストすることができましたが、リスク管理された方法でどのように本番サービスに展開するかが課題でした。

これを実現するために、彼らは別の継ぎ目、今回は製品による分割パターンを利用しました。イベントルーターは、製品タイプと一意の製品IDによる設定可能なルーティング（6）を追加するように強化されました。チームは、個々の製品のIDによる公開、管理、および販売をテストし、その後、ルーターを徐々に多くの製品タイプで構成し、事実上、新しいソリューションによって処理される製品の割合を増やしていきました。

すべての製品が新しいシステムによって処理されるようになったとき、レガシーインテグレーションミドルウェアは廃止され、ライセンス、サポート、データセンターホスティング費用で大幅なコスト削減を実現しました。

これを継続的に行うための組織変更

私たちのチームはすでに組織内の別の部門でクライアントと協力しており、別のレガシーシステムをすでに正常に置き換えていました。

組織全体のエンジニアリングレベルでは、継続的デリバリーと質の高いサポートプラクティスが確立された標準となっており、マイクロサービススタイルのアーキテクチャにより、クラウドベースのプラットフォームへのコンテナ化されたサービスの定期的かつ独立したデプロイが可能になりました。

新しいプログラムのチームは、新しいステークホルダーと協力して、ビジネスの他の部分を同じ「アジャイルとCD」の旅に導く必要があり、初期のリスク管理されたリリースによって信頼を得ることができました。時間が経つにつれて、CDを含む新しいエンジニアリングおよび品質プラクティスが、歴史的に高いレベルの官僚主義とガバナンスをもたらしていた同じリスクをどのように軽減しているかを実証することができました。そのため、頻度の低い、より大規模なリリースの代わりに、より小さく、より頻繁で、信頼性の高いデプロイと、ビジネス側が変更を受け入れる準備ができたときに変更を切り替えるリリースも実現しました。

終わりに

もちろん、上記の単純化されたストーリーよりもはるかに複雑な統合要件がありました。新しい実装を本番環境でテストした直後に、アーケオロジーの必要性が現れた例がありました。多くのビジネスに不可欠な管理情報レポートが一致しませんでした。製品が「紛失」していたのです。

徹底的な調査の結果、チームは、（長期的なビジネストランザクションの状態を保存するために）インテグレーションミドルウェアで使用されていたデータベースが、組織のデータウェアハウスに複製されていることを発見しました。多数のバッチジョブ、ストアドプロシージャ、およびビューを介して、このデータはビジネスに不可欠なKPIレポート内で使用できるようになりました。

これらのレポートが壊れないようにするために、追加のレガシー模倣が必要でした。チームは、ストアフロントからの販売メッセージにワイヤータップを使用し、JDBCを使用して、データウェアハウス内の適切なテーブルにデータを注入しました。これらの追加の模倣も移行アーキテクチャの一部となり、可能になったら削除される予定でした。

抽象化による分岐、および上記のパターンとプラクティスの使用というアプローチは、リスクを軽減することを目的としていました。

イベントインターセプション（技術的な継ぎ目）、レガシー模倣、および移行アーキテクチャを使用することで、クライアントは問題を分割することができました。次に、製品（ビジネスの継ぎ目）、この場合は製品タイプで分割することにより、より広範な展開をきめ細かく制御し、リスクをさらに管理することができました。全体として、このアプローチにより、ビジネス側は、無理のないペースでシステム置換を進めることができました。

このアプローチによりリスクを管理することができましたが、それにはコストがかかりました。したがって、検討すべき問題は、「ビジネスはこのリスク軽減にどのような価値を置くか？」ということです。これを明確にし、定量化することで、チームはそれに対する投資を追跡することができます。イベントルーターとレガシー模倣は、リスクを管理することを目的とした移行アーキテクチャへの投資の一部でした。それらの役割は、リスクを管理できるようにするオプションを作成することでした。このような作業は、「使い捨て」と見なされやすく、したがって可能な限り回避すべきコストと見なされる可能性があります。この「リスク軽減の価値」対「移行アーキテクチャのコスト」のトレードオフを明確かつ透明にしてください。