フローの迂回

データソースのマッピング

クリティカルアグリゲーターを抽出して再実装する場合、まず、それがレガシー資産の残りの部分とどのようにリンクされているかを理解する必要があります。これは、集計に使用されるデータの最終的なソースを分析して理解することを意味します。ここで重要なのは、究極の上流システムに到達する必要があることを覚えておくことです。たとえば、メインフレームを売上情報の信頼できるソースとして扱う場合でも、データ自体は店舗のレジシステムから発信される場合があります。

アグリゲーターを上流および下流の依存関係とともに示す図を作成することが重要です。システムコンテキスト図などはこちらでうまく機能します。どのシステムからどのデータがどのくらいの頻度で流れているかを正確に理解する必要があります。レガシーソリューションがデータのボトルネックになることはよくあります。（新しい）ソースシステムからの追加の有用なデータは、レガシーでキャプチャまたは表現するのが難しすぎるため、破棄されることがよくあります。これを考慮して、どのアップストリームソースデータがどこで破棄されているかをキャプチャする必要もあります。

ユーザー要件

明らかに、"迂回"する予定の機能がエンドユーザーによってどのように使用されているかを理解する必要があります。クリティカルアグリゲーターの場合、レポートまたはメトリックごとに非常に多くのユーザーが混在していることがよくあります。これは、機能パリティが、実際には現在のユーザーのニーズを満たしていない「肥大化した」レポートのセットを再構築することにつながる可能性がある古典的な例です。簡素化された、より小さなレポートとダッシュボードのセットの方が良いソリューションかもしれません。

初期実装中に主要な数値が一致することを確認するために、並列実行が必要になる場合があります。これにより、ビジネスは期待どおりに機能することを確認できます。

出力の生成方法を把握する

理想的には、現在の出力がどのように生成されるかを把握したいと考えています。1つの手法は、シーケンス図を使用してレガシーシステムでのデータ受信と処理の順序を文書化するか、単にフローチャートを使用することです。ただし、既存の実装を完全に把握しようとすると、収穫逓減の法則が働くことがよくあります。重要な知識が失われていることに気付くことは珍しくありません。場合によっては、レガシーコードが物事の仕組みの唯一の「ドキュメント」である可能性があり、これを理解することは非常に困難または費用がかかる可能性があります。

ある著者は、主要な財務計算を実行するために、レガシーシステムからのエクスポートを非常に複雑なスプレッドシートと組み合わせて使用​​するクライアントと協力しました。組織の誰もこれがどのように機能するかを知りませんでしたが、幸いなことに、最近退職した従業員と連絡を取り合うことができました。残念ながら、彼らと話したところ、10年前に以前の従業員からスプレッドシートを継承したことが判明しましたが、悲しいことに、この人は数年前に亡くなりました。レガシーレポートと（2回「バージョン移行された」）Excelスプレッドシートのリバースエンジニアリングは、最初の原則に戻って計算が何をするかを新たに定義するよりも多くの作業でした。

置換エンドポイントで機能パリティを構築していない場合でも、主要な出力がレガシーと「一致」する必要があります。集計の例を使用すると、店舗の毎時の売上レポートを作成できるようになりましたが、ビジネスリーダーは依然として月末の合計を必要としており、これらは既存の数値と相関している必要があります。エンドユーザーと協力して、特定のテスト入力に対する予期される出力の実例を作成する必要があります。これは、後でどのシステム（古いシステムか新しいシステムか）が「正しい」かを特定するために不可欠です。

デリバリーとテスト

このパターンは、新しい機能をスライスで構築する反復的なアプローチに適していることがわかりました。クリティカルアグリゲーターの場合、これは各レポートを順番に配信し、本番環境のような環境に完全に導入することを意味します。その後、並列実行を使用して、残りのレポートを構築するときに配信されたレポートを監視し、ベータユーザーから早期フィードバックを得ることができます。

私たちの経験では、多くのレガシーレポートには未発見の問題とバグが含まれています。これは、新しい出力が既存の出力と一致することはめったにないことを意味します。レガシー実装を sepenuhnya理解していない場合、不一致の原因を理解することは非常に困難です。1つの軽減策は、自動テストを使用して既知のデータを挿入し、実装フェーズ全体で出力を検証することです。理想的には、新しい実装とレガシー実装の両方でこれを行うため、同じ既知の入力セットの出力を比較できます。ただし、実際には、レガシーテスト環境の可用性とデータ挿入の複雑さのため、推奨される最小限である新しいシステムに対してのみこれを行うことがよくあります。

レガシー集約で「システム外」の回避策が見つかることはよくあります。移行作業中にこれらを追跡しようとすることは明らかに重要です。最も一般的な例は、リーダーシップチームが必要とするレポートがレガシー実装から実際には利用できないため、誰かがレポートを手動で操作して実際に表示される出力を作成する場合です。これには多くの場合、数日かかります。誰もリーダーシップにレポートが実際に機能していないことを伝えたくないため、物事が実際にどのように機能しているかを認識していないことがよくあります。

本番稼働

新しいアグリゲーターの機能が正しいことに満足したら、ユーザーを新しいソリューションに誘導できます。これは段階的に行うことができます。これは、主要なユーザーコホートのレポートを実装すること、並列実行の期間、そして最後に新しいレポートのみを使用してそれらに切り替えることを意味する可能性があります。

監視とアラート

正しい自動監視とアラートを導入することは、フローの迂回、特に依存関係がまだレガシーシステムにある場合に不可欠です。更新が期待どおりに受信されていること、既知の適切な範囲内にあること、および最終結果が許容範囲内にあることを監視する必要があります。このチェックを手動で行うと、すぐに多くの作業になり、エラーや遅延の原因となる可能性があります。一般的に、過去の回避策を新しいソリューションに再導入したくないため、アップストリームシステムで見つかったデータの問題を修正することをお勧めします。追加の安全対策として、並列実行を一定期間そのままにしておき、調整ツールを選択的に使用して、古い実装と新しい実装が大きく乖離し始めた場合にアラートを生成できます。