4つの戦略、それぞれに実際にかかるコスト、そして特定のワークロードにどの戦略が必要かを見極める方法。意思決定の承認を担う方に向けて書かれています。
メインフレームのモダナイゼーションに関するアドバイスの多くは、移行するかしないかという1つの問いに集約されます。そのような捉え方が、多くのプログラムが停滞する理由です。大規模な組織が抱えるメインフレームのワークロードは1つではありません。何百ものワークロードが存在し、そのすべてを同じように扱うべきではないのです。有効な意思決定はワークロードごとに行うものであり、そこには4つの妥当な答えが存在します。
コードを変更せず、ワークロードをそのままエミュレーターやクラウドインスタンスに移行します。
アプリケーションコードをほぼそのまま維持しながら、データベース、トランザクションマネージャー、スケジューラーなどのランタイム層を入れ替えます。
ビジネスロジックを維持しつつ、コードをモダンな言語に書き換える。
ワークロードを意図的にメインフレームに残します。
各戦略を必要とするワークロードを見極めるための4つの質問があります。ポートフォリオ単位ではなく、アプリケーション単位で回答してください。
リファクタリングのパスは、ニュースの見出しになることが多いため、個別に扱う必要があります。繰り返し発生する失敗のパターンは、どの組織でも共通しています。
40年間の変更内容はコードの中にのみ存在し、他のどこにも記録されていません。したがって、すべての書き換え作業は、エンジニアリングである前に、まず考古学的な調査となります。この調査を省略したチームは、本番環境でルールの欠落に気づくことになります。
COBOLのパック10進演算とJavaの浮動小数点では、丸め処理の結果が同一にはなりません。1トランザクションあたり1セントの誤差が生じても例外は発生せず、マイグレーションの完了が宣言されたずっと後になって、四半期末の照合時に不一致として発覚するのです。
レガシーシステムを対象に作成されたテストスイートがパスしたとしても、それは「誰かがテストしようと考えたパス」において、新システムが旧システムの動作を再現していることを証明するにすぎません。実際のポートフォリオには、過去10年間、誰も意図的に実行していないパスが存在します。
銀行、保険、政府機関では、再構築されたシステムは監査上、新規システムとして扱われることがよくあります。そのコストは開始時のビジネスケースに組み込むべきであり、9か月目に発覚するようなものであってはなりません。
複数年にわたるプログラムは、依存する人材の退職時期と直接重なります。最も必要とされる時にはすでにその知識を活用できなくなっているため、プログラムの開始前に知識を抽出しておく必要があります。
上記のすべての戦略は、共通の制約を受けます。それは「システムが以前と同じ処理を行っていることを証明できるか」という点です。テストは入力空間をサンプリングするものです。一方、形式的検証は入力空間全体を論理的に推論し、すべての入力に対してモダナイズ後の処理がレガシーシステムと同じ出力を生成することを証明します。この証明が可能であれば、リファクタリングは不確実な賭けではなく、見通しの立つエンジニアリング作業となります。その結果、前述の「失敗した場合のコスト」に関する問いの答えも変わります。証明が不可能な場合は、保守的な姿勢をとるのが適切です。
私たちは、ソフトウェア考古学、そして証明、という順序で構築を行います。HyperDocsは、COBOL、PL/I、JCLのソースからドキュメントを再構築します。HyperTwinは、シニアエンジニアが退職する前に、その知識を記録します。Hopperは、z/OSの日常的な運用を実行します。HyperLoopは、行レベルで正確性を証明しながら、移行そのものを実行します。もし、後の2つよりも最初の2つが重要となるような初期段階にあるのなら、これが偽りのない順序です。
