レガシーシステムが抱えるのは古いコードだけではない

成熟したシステムには、多くの場合、何年にもわたって交渉されたビジネス動作が含まれています。一部のルールはコードで明示されています。その他には、バッチのタイミング、データベースの規約、運用チェックリスト、サプライヤーの手順、経験豊富な人々の判断などがあります。これらの要素は、テクノロジーの観点からは偶然に見えるかもしれませんが、継続性にとって不可欠なままです。

現在のシステムが置き換えられるコンポーネントとしてのみ文書化されている場合、モダナイゼーションは失敗します。より便利なビューでは、ビューが有効にする機能、サポートする意思決定、所有する重要なデータ、フィードする下流の依存関係、ビューが提供するコントロール、および人々が管理する例外がマップされます。このビューにより、何が変更可能で、何が接続されたままでなければならないかが明らかになります。

置き換え候補より先に継続性台帳を作る

継続性記録には、安定したアイデンティティ、ビジネス定義、承認権限、タイミング義務、調整ルール、監査証拠、回復の期待、サービス境界など、すべての移行で保持する必要がある事実と動作が記載されています。各アイテムには所有者とそれをテストする方法が必要です。記録は、歴史上のあらゆる行動を再現するための言い訳にはなりません。これは、何を保持、変更、または廃止するかを意図的に決定するための基礎となります。

これにより、発見が変わります。チームは、ユーザーが必要とする機能だけを尋ねるのではなく、ルールが存在する理由、ルールが変更された場合にどのような結果が生じるのか、その結果を受け入れる権限があるのは誰なのかを尋ねます。廃止された動作は、その目的と依存関係が調査されていれば、自信を持って削除できます。重要な動作は、誤って失われるのではなく、再設計することができます。

目標と移行を一体で設計する

ターゲット アーキテクチャは、意図された将来の責任と境界を示します。それ自体では、組織が明日どのように運営できるかを示すものではありません。遷移アーキテクチャは、データ、インターフェイス、ユーザーが移動する間に実際の作業を実行する必要がある中間状態を記述します。これには、一時的な所有権、共存、調整、追加の制御、および明示的な終了基準が含まれます。

ターゲットに沿って移行を設計すると、ターゲットが到達可能かどうかがテストされます。重要な ID を移動したり、古いルールと新しいルールを一緒に実行したり、両方の資産にわたって結果を検証したりするための信頼できる方法がない場合、ターゲットには異なる境界が必要になる可能性があります。移行はそれ自体がアーキテクチャであり、文書化されていないプロジェクトの足場ではありません。

事業能力と検証証拠に沿って移行を分割する

技術レイヤーが移行の最も安全な単位であることはほとんどありません。最初にすべてのデータを移動し、次にすべてのサービスを移動し、次にすべてのチャネルを移動すると、完全なビジネス成果が得られない状態が長期間発生する可能性があります。機能スライスは、ルール、データ、インターフェイス、操作を介して意味のあるパスをたどります。狭いかもしれませんが、全体としては受け入れられます。

簡単さだけでなく、依存関係と結果によってスライスを選択します。初期の作業では、許容できない爆発範囲を回避しながら、最もリスクの高い想定をテストする必要があります。各スライスには、成功、調整、および回復の基準が必要です。完了とは、単にコードがデプロイされただけでなく、組織が新しいパスを運用して説明できることを意味します。

共存期間を運用モデルとして設計する

並列運用では、移行図では省略されがちな疑問が生じます。それぞれの事実に対してどのシステムが権威を持っていますか?両方とも変更を受け入れることができますか?アイデンティティはどのように相関しているのでしょうか?結果が異なった場合、誰が判断するのでしょうか?和解はどれくらい早く行わなければなりませんか?同等性が重要な場合、新しい動作が同等であることを証明する証拠は何ですか?

これらは運用上の決定です。所有者、運用手順書、監視、エスカレーションが必要です。二重書き込みまたはデータ複製はメカニズムの一部にすることができますが、どちらもビジネス権限を確立するものではありません。明確な信頼できる情報源の決定と制御された例外パスは、高度な同期テクノロジーよりも重要です。

復旧はデプロイだけでなく事業状態まで扱う

アプリケーションのバージョンをロールバックしても、アクティブだったときに受け入れられた注文、送信された通知、記録された決定、または変換されたデータが自動的に元に戻ることはありません。復旧計画では、不可逆的な影響、補償アクション、および以前の状態に戻ることが責任を負わなくなるポイントを特定する必要があります。

各遷移について、何を再試行、再生、調整、補償、または復元できるかを定義します。意思決定プロセスとメカニズムをテストします。リーダーは、誰が進行を一時停止できるのか、どのような証拠がその選択のきっかけとなるのか、問題を理解している間どのように業務を継続するのかを知っておく必要があります。

日程だけのロードマップではなく意思決定基準を使う

モダナイゼーション ロードマップには、ルール適用範囲の理解、承認された許容範囲内でのデータ調整、リカバリのテスト、サポート所有権の受け入れ、または重要な依存関係の削除など、状態間の移行に必要な証拠を示す必要があります。日付は重要ですが、しきい値のない日付は、リスクが変化する前に進捗状況を報告することを奨励します。

意思決定記録には、ターゲット、シーケンス、または一時的な侵害が選択された理由が保存されます。また、いつ仮定を見直すべきかについても述べています。これにより、ガバナンスがより軽量かつ有用になります。すべての詳細を同じフォーラムで通過させる必要はなく、結果として生じる不確実性に焦点を当てます。