メインフレームアプリケーションのモダナイゼーションに関する包括的な視点と配置戦略

この記事は、”Taking a comprehensive perspective to mainframe application modernization with a disposition strategy” を翻訳したものです。

はじめに

メインフレームのお客様は、モダナイゼーションの選択肢が無数にあります。現在、多くの組織は、人材不足や、高額なコストとその上昇、レガシー環境ではビジネスアジリティに制限が掛かることで、モダナイゼーションが急務となっています。また、お客様自身も、モダナイゼーションの複数のパターン、ツール、戦略を自ずと模索しています。

配置戦略 (disposition strategy) には、メインフレームの複雑なモノリシックアプリケーションや大規模なコードベースへの対処に役立つ指針が含まれます。お客様は、レガシーアプリケーションを管理しやすい部分に分解し、ターゲットとなる移行パターンを開発し、移行の順序付けを行い、メインフレームに残るワークロードとの連携機能を構築します。この作業は、アプリケーションが密結合な状態から完全に切り離されるまで繰り返されます。

配置戦略とは、メインフレームモダナイゼーションに対する複数のパターンを複合的に組み合わせるアプローチです。ビジネス目標と IT 目標の優先順位とワークロードの特性に基づいて、個々のワークロードに適した適切なパターンが選択されます。配置戦略は、メインフレームモダナイゼーションを個々のプロジェクトとばらばらの移行フェーズの集まりと見なすのではなく、全体を包括的に見る視点を持つことを推奨します。これには、メインフレームからクラウドネイティブに至る長い道のりの最初から最後までの全行程を定義したロードマップが含まれます。このアプローチは、移行を加速し、リスクを軽減し、お客様が許容できる期間内にビジネス目標と技術目標を達成できるよう支援するのに役立ちます。

指針として目指す北極星を定義する

メインフレーム資産は、地域、業界、顧客によってさまざまであり、まったく同じメインフレームアプリケーションは 2 つとありません。レガシーテクノロジー、ビジネス目標、将来の要件、リスクへの関心は、お客様によって非常に多様です。多くの大企業では、複数の事業部門がメインフレーム上で稼働するアプリケーションによってサポートされています。また、これらの事業部門には、メインフレーム処理に依存する多数のビジネスリーダー、アプリケーションオーナー、およびステークホルダーが組織全体に存在しています。このダイナミクスにより、組織がメインフレームの将来の状態に関する明確な戦略を欠いているというシナリオがしばしば生じます。モダナイゼーションの初期段階では、メインフレームのさまざまなステークホルダーが独自に活動し、それぞれ別個に戦略を導入または計画しているお客様をよく見かけます。その結果、モダナイゼーションへのアプローチがばらばらになります。このようなときのモダナイゼーションには、組織のモダナイゼーションの道しるべとなる北極星のようなビジョンが明確になっていない可能性があります。

メインフレームモダナイゼーションプログラム^(※1)を成功させるための第一歩は、北極星 (North Star: 目指すべき指針) を定義することです。この北極星は、経営幹部、そして多くの場合、組織の取締役会にも共有されます。お客様は、メインフレームを使い続けることで増大するリスク、コスト、競争上の不利益を認識しています。レガシーアプリケーションのモダナイゼーションを経営幹部が指示することで、より迅速かつ緊急に職務を遂行し、成果を上げているお客様を我々は目にして来ました。明確なミッションが無いため、一連のばらばらで戦術的なモダナイゼーションプログラムに参加することになったお客様も見て来ました。ばらばらなプログラムでは、メインフレームプラットフォームのワークロードの移行には成功しても、モダナイゼーションのメリットを最大限に引き出すには苦労するかもしれません。場合によっては、メインフレームに課せられた制約が原因で MIPS の使用量が増加することさえあります。このような状況を避けるため、お客様には主に 3 つの質問に答えて北極星を定義することをおすすめします。

なぜ私たちはモダナイゼーションを進めているのか?
私たちはどこに向かっているのか?
それはいつ実現するのか?

これらの質問に答えることで、メインフレーム移行プログラムを成功させるための基礎を確立し、組織が共有する共通のビジネス目標と技術目標を定義しやすくなります。

(※1) 訳注: ここでのプログラムは、共通の戦略的目標を持つ複数の関連プロジェクトを統合・管理することにより、単独プロジェクトの成功を目指す部分最適では無く、全体最適による価値を創出する手法としてのプログラムマネジメントの文脈で使われています。レガシーコードのプログラムを指すものではありません。

モダナイゼーションのビジネス基準: ビジネス要件と技術的現実のバランス

ビジネス目標は、組織内の部門によって大きく異なる場合があります。ビジネスユニットによっては、レガシーアプリケーションの機能を早急に変更しなければならない場合もあれば、確立されたプロセスやユーザーエクスペリエンスの変更に抵抗しているビジネスユニットもあります。大まかに言うと、ビジネスの優先事項は次の 2 つのカテゴリに分類されます。

カテゴリー 1: ビジネス機能は変わらないが、ビジネスの俊敏性にはテクノロジーのモダナイゼーションが不可欠

機能的な変化が望まれていない場合。このシナリオでは、レガシーアプリケーションがサポートする既存のビジネス機能に、ビジネスユーザーはとても満足しています。現行のビジネス機能やワークフローは変更する必要がなく、ビジネスユーザーは機能変更という考えに反対しています。これは、ユーザーが端末エミュレーターの黒画面を操作しているお客様にも当てはまる可能性があります。端末エミュレーターを長年使い続けているユーザーは、操作に熟練しているので作業効率が非常に高く、最新の UX に置き換えると生産性が低下する可能性があります。

お客様はメインフレームワークロードの大部分が一般にこのカテゴリに入ると想定する必要があります。メインフレームアプリケーションは何十年も組織で使われてきました。これらのアプリケーションは、個別のビジネスロジックが何年にもわたって使われてきたビジネスに適しているかもしれません。大企業と各業界で差別化されたビジネスのやり方に合わせてカスタマイズされている可能性があります。すべてのアプリケーションに機能的なトランスフォーメーションが必要なわけではありません。安定性と予測可能性が最優先されるシステムの場合は、以下の選択肢を考慮することが重要です。

リファクタリング (Refactor): レガシーアプリケーションを最新のプログラミング言語とリレーショナルデータベースに変換します。たとえば、AWS Transform for mainframe を使うと、お客様は AWS の専門的な AI エージェントを使用して COBOL アプリケーションを AWS 上の Java にリファクタリングできます。
リプラットフォーム (Replatform): 既存の機能を維持し、レガシーテクノロジースタックを維持しながら、よりモダンなインフラストラクチャに移行します。たとえば、AWS Mainframe Modernization には、クラウド内のメインフレーム互換ランタイムにリプラットフォームするためのオプションが用意されています。

これらのアプリケーションのモダナイゼーションでは、機能以外のモダナイゼーションのメリット (耐障害性、影響範囲の縮小、可用性、俊敏性) にフォーカスしてコミュニケーションします。

カテゴリー 2: 技術的な負債を取り除いたり、新しい機能を追加したり、モノリスを分解してプロダクトを調整したりするには、ビジネス機能の変更が必要

機能強化の要件がある場合。ビジネス部門がアプリケーションの機能を強化する必要があるのはこの場合です。一般に、お客様はメインフレームワークロードの一部だけがこのカテゴリに該当すると予想しています。このような状況では、企業はモダンな UI、リアルタイム機能、またはより高速なバッチ処理を望んでいる可能性があります。また、お客様は、モノリス化した現行アプリケーションをプロダクトに合わせたビジネス機能に分割したいという目標を持っているかもしれません。このアプローチにより、マイクロサービスアーキテクチャを構築し、疎結合化することによってアジリティとイノベーションを促進されます。

ニアリアルタイムの機能に対するエンドカスタマーの期待の高まりに直面するお客様が増えています。メインフレーム上のモノリス化したアプリケーションにこのような機能を導入するのは困難です。さらに、新しい市場や業界への進出、あるいは顧客基盤の拡大を目指すお客様にも会うことがあります。成長目標を積極的に掲げているお客様は、メインフレームアプリケーションを維持することが、成長や新規ビジネスの獲得を阻害していると気付くことがよくあります。

成長の可能性: モダナイズすることで、新しい収益源を開拓したり、事業拡大を支援したりできるアプリケーションはどれか?
カスタマーエクスペリエンスへの影響: 顧客とのやり取りや顧客満足度に直接影響するアプリケーションはどれか?
市場への対応力: 現在、市場の変化への対応能力を制限しているのはどのシステムか?
イノベーションの可能性: 最新の開発手法や最先端技術との連携から最も恩恵を受けるのはどのアプリケーションか?

一般的に、強化すべき機能要件が明確に示されているビジネスユニットは、より優先されるはずです。新機能、ユーザーエクスペリエンスの向上、連携機能など、個々のニーズが具体的な目標を提示し、それによってモダナイゼーションの取り組みが推進され、目に見える価値が示されます。

Reimagine パターンとは、メインフレームアプリケーションのアーキテクチャを最新のテクノロジースタックに合わせて設計し直し、コードを書き直すことと定義されています。このモダナイゼーションの目標は、アプリケーションに機能的な変更を導入することです。ビジネスが新しい機能を必要とする場合、reimagine パターンが望ましいアプローチです。

モダナイゼーションのための技術的基準

メインフレームモダナイゼーションの配置戦略には、組織レベルとアプリケーションレベルの両方で評価された技術的基準も組み込む必要があります。

組織レベルでの技術的考慮事項の評価: データセンターから出て行くための戦略や緊急性が高い移行期限

データセンターの撤退を迫られている組織は、移行の期限が迫っているため、スピードとリスクの軽減を優先する必要があります。コードを変更せずにメインフレームのワークロードをパートナーが管理するデータセンターに移動することを意味するリホスト (rehost) パターンは、実践的な第一歩となる可能性があります。多くの場合、リホストアプローチは、他の移行パターンのように長いサイクルを通ることなく、数ヶ月で完了できます。リホストは事業継続につながります。また、将来のモダナイゼーションの基礎を築き、組織がより高度なパターンを徐々に適用するのにも役立ちます。これらのパターンは、時間とリソースの制約の中で、リファクタリングや reimagine などのモダナイゼーションのニーズに対応できます。

ニッチなメインフレーム技術: プログラミング言語、トランザクションモニター、データベース

既存のメインフレームアプリケーションで使用されている特定のプログラミング言語、トランザクションモニター、データベーステクノロジーは、モダナイゼーションの取り組みの実現可能性と複雑さに大きな影響を与えることがあります。これは、メインフレームモダナイゼーションの配置戦略を検討する際に、重要な技術的考慮事項です。

Natural/Adabas、IDMS などの特定のメインフレームテクノロジーは、リプラットフォームやリファクタリングなどの一部のモダナイゼーションパターンでは直接サポートされていなかったり、完全にはサポートされていない場合があります。これらのレガシーメインフレームテクノロジーの可用性と保守性のスキルも、考慮点の 1 つです。これにより、利用できるモダナイゼーションの選択肢が制限される可能性があり、実行可能な選択肢はリプレース (replace)^(※2) や reimagine などのパターンだけかもしれません。

組織は、使用されているメインフレームのテクノロジースタックと、それがさまざまなモダナイゼーションアプローチの実現可能性や複雑さにどの程度合致するかを注意深く評価する必要があります。この技術的評価は、適切な配置戦略を決定するうえで重要なインプットとなります。

(※2) 訳注: 本ブログ内のリプレース (replace) は、パッケージソフトウェア製品の購入や SaaS のサブスクリプション契約等を指すリパーチェス (repurchase) と同義で使われています

ベンダーによる更新のタイムライン

メインフレームモダナイゼーションの配置戦略を評価する際、ベンダーの更新スケジュールは重要な技術的検討事項になり得ます。組織には、ソフトウェアライセンス契約が異なるさまざまなメインフレームベンダーが存在することがよくあります。契約条件の評価にあたっては、更新時期が迫ることでリスクが高まります。この場合、中には、それらのベンダーのテクノロジーからできるだけ早く撤退することが最も価値ある結果になると判断するお客様もいます。このタイムラインの速さは、選択するモダナイゼーションアプローチにも影響します。

たとえば、ライセンス契約の終了期限が迫っている場合は、リプレースアプローチや reimagine アプローチよりも、リファクタリングパターンの方が適している場合があります。リファクタリングは、コア機能を維持しながらアプリケーションをモダナイズするのに役立ちます。多くの場合、全面的な書き直し (full rewrite) や再実装 (reimplementation) よりも短時間で完了できます。

ただし、すべてのリファクタリングソリューションがすべてのメインフレームテクノロジーをサポートしているわけではない点に注意することが重要です。使用中の特定のテクノロジーに適したリファクタリングソリューションの評価を完了する必要があります。場合によっては、明白なリファクタリングソリューションや実証済のリファクタリングソリューションがないこともあります。必要な期限までにベンダーのテクノロジーから撤退するには、reimagine またはリプレースのアプローチしか実行できない場合があります。

最良のモダナイゼーション戦略を決定する際には、全体的な技術評価の一環として、メインフレームベンダーの契約と更新スケジュールを評価することが重要です。これにより、選択したアプローチを、特定のベンダーのテクノロジーから撤退する緊急性に合わせることができます。

動員可能なメインフレームスキルセット

メインフレームのスキルセットに制約があるために企業が人材リスクに直面している場合、そのスキルへの依存度が低いメインフレームモダナイゼーションの選択肢を選ぶことが重要です。このような場合、メインフレームアプリケーションのリファクタリングや reimagine などの戦略が効果的なアプローチになり得ます。

逆に、組織内に有能なメインフレーム人材プールがある場合は、リプラットフォームアプローチがモダナイゼーションに適した戦略となり得ます。既存の専門知識を活用して、ワークロードをよりモダンなプラットフォームに移行することができます。

アプリケーション/ワークロードの技術的な複雑さと依存関係の評価

適切なパターンの選択は、ビジネス上の考慮事項と技術的要件の両方に基づいて行う必要があります。各ワークロードまたはアプリケーションの特定の特性を考慮する必要があります。

さまざまなアプリケーションやワークロードを徹底的に技術評価して、それぞれに最適なモダナイゼーションアプローチを決定することが重要です。この評価フェーズでは、以下の要素を考慮します。

移行元のテクノロジー: プログラミング言語と既存のソースコードの量を評価します。一部の言語とフレームワークは、他の言語とフレームワークよりも自動化されたトランスフォーメーションとモダナイゼーションに適しています。これは、特定のモダナイゼーションパターンの実現可能性と複雑さに影響する可能性があります。
データに関する考慮事項: メインフレームで使われているデータストア技術 (Db2、IMS/DB、VSAM など) を評価します。データ量、データ構造の複雑さ、データエンティティ間の関係を評価します。データの性質と複雑さが、適切なモダナイゼーションアプローチに影響する可能性があります。
結合度: さまざまなアプリケーションとワークロード間の結合レベルを特定します。たとえば、トランザクションコンテキストの伝播を含むアプリケーションは、密結合されている可能性があります。この場合、疎結合の場合やサービス境界が明確な場合よりも、モダナイゼーションの課題が大きくなります。モダナイゼーションの過程において、密結合された機能の相互依存関係に順次対処し、具体的に管理する必要があるためです。
連携の複雑さと依存関係: アプリケーションとワークロードの間のさまざまな連携ポイントを評価します。共有リソース、データ依存関係、全体的な連携の複雑さを特定します。これにより、既存の連携を維持できる適切なモダナイゼーションパターンを判断したり、リスクを抑えて移行を行ったりするのに役立ちます。
外部インターフェース: 選択したモダナイゼーションパターンによっては、外部インターフェースを介してメインフレームにアクセスするメインフレームの外部のクライアントアプリケーションの一部が変更されることがあります。選択したパターンが、すべての外部接続ポイント、API 操作、および外部システムとのデータ交換メカニズムに必要なインターフェースをサポートしていることを確認します。

この詳細な技術評価では、次のような要素を考慮する必要があります。

読み取り/書き込みモードで同じデータにアクセスするアプリケーションをグループ化し、それらのグループに同じ移行パターンを選択する
結合度が高いワークロードには同じ移行パターンを選択する
移行元のプログラミング言語がさまざまな移行パターンの実現可能性に与える影響を考慮する
外部インターフェースや連携への変更を可能な限り最小限に抑える移行パターンを選択する

アプリケーションとワークロードの分析は、全体的な配置戦略の重要なインプットです。ワークロード固有の技術的特徴と依存関係に基づいて、ワークロードに適したモダナイゼーションパターンとソリューションを追加できます。

移行戦略の策定

ビジネス成果駆動型プログラムの構築

モダナイゼーションを純粋に技術的な課題として扱うのではなく、次のようなプログラムを確立します。

組織の北極星から逆算して考える: 冒頭で述べたように、お客様はメインフレーム資産に関する組織的な戦略とアプローチを必要としています。成功するメインフレーム移行プロジェクトは、経営陣が設定した変動要素(予算や期間、体制等)の枠組みの中で実施されます。なぜモダナイゼーションを行っているのか、どこに向かっているのか、いつモダナイゼーションを実現するのか、といった点を見失わないようにします。
戦略的ビジネス目標との連動: モダナイゼーションは、俊敏性の向上、カスタマーエクスペリエンスの向上、新しい機能など、特定のビジネス成果をサポートするものでなければなりません。
ポートフォリオ全体を最初から検討する: モダナイゼーションが段階的なアプローチとして定義されている場合でも、新しいテクノロジーのサイロ化を避けるため、計画はアプリケーション全体を対象とする必要があります。
戦術的な成果と戦略的目標のバランスを取る: 包括的なモダナイゼーションに向けて取り組みながら、段階的な価値をもたらすプログラムを設計します。
成功の明確な指標を確立する: ビジネス面と技術面の両方で、進捗状況をどのように測定するか定義します。

経営幹部レベルで戦略が設定されていないと、個々のチームが異なるアプローチを採用したり、「様子を見る」という考えに陥ったりする可能性があります。これにより、モダナイゼーションが遅れ、複雑さが増す可能性があります。

「すべてを再構築」という落とし穴の回避

私たちの経験から、80:20 の原則はメインフレーム資産にも一般的に当てはまることがわかっています。メインフレームアプリケーションの約 80% は機能変更を必要とせず、約 20% のアプリケーションでは reimagine が必要です。

お客様には、大幅な脱メインフレームを含むモダナイゼーションのアプローチを検討することをお勧めします。Transamerica や Goldman Sachs などのお客様は、リファクタリングやリプラットフォームパターンを利用して、ミッションクリティカルなメインフレームワークロードを AWS に移行することに成功しています。アプリケーションごとに個別のアプローチを取るだけだと時間がかかり過ぎて、ビジネス上の必要性を満たせない場合があります。ビジネス目標と技術目標に基づいて、複数のモダナイゼーションパターンを組み込むことを検討します。

大規模なリファクタリング: AWS Transform for mainframe には、レガシーアプリケーションをモダンな Java フレームワークにモダナイズするのに役立つリファクタリング機能が備わっています。このパターンは、決定論的ツールによってもたらされる移行スケジュールの短縮の恩恵を受けながら、レガシーテクノロジーへの依存を減らしたい場合に使用できます。
リプラットフォーム: リプラットフォームでは、エミュレーションテクノロジーを使用して、メインフレームアプリケーションをそのまま移行します。これはしばしば「COBOL から COBOL への移行」と呼ばれます。この場合、リプラットフォームパターンにより、COBOL の人材不足の状況に対処し、脱メインフレームを加速させることができます。

大規模なモダナイゼーションアプローチと戦略的な reimagine を組み合わせることで、お客様はプラットフォームからの撤退に向けて前進しながら、技術的成果とビジネス上の成果を一致させる機会を得ることができます。複数のパターンを社内の戦略で検討しているお客様は、組織内のより多様な目標に取り組むことができます。これは、同じ期間内に運用コスト削減目標を達成しながら行われます。

まとめ: 今こそ行動の時です

今日、メインフレームアプリケーションのモダナイゼーションが強く求められています。人材不足、ソフトウェアコストの上昇、組織の非効率性といったよく挙げられる課題のほかに、新たな要因が浮かび上がってきました。それは、生成 AI がソフトウェア開発に与える影響の増大です。生成 AI コーディングアシスタントがモダンな言語の生産性に革命をもたらすにつれ、モダンテクノロジーとメインフレームテクノロジーの間の開発スピードと生産性のギャップはさらに悪化するでしょう。COBOL や Assembler、PL/I 言語のアプリケーションを使用する組織は、価値創出のスピードという点で競争上の不利な点に直面するケースが増えています。同業他社が運用する基幹システムは、開発スピードがますます速くなるモダンなテクノロジーで書かれた基幹システムを運用しているかも知れません。

メインフレームモダナイゼーションに「特効薬」はありません。成功するには、具体的な成果に基づいて IT 目標とビジネス目標を一致させる、ビジネス駆動型のマルチパターンアプローチが必要です。自動化を行い、段階的に反復することで、コスト削減以外の価値に集中できます。

配置戦略は、各アプリケーションポートフォリオの微妙な違いを認識した、このジャーニーの枠組みとなります。このアプローチでメインフレームアプリケーションをモダナイズすることで、組織は数十年にわたって構築された貴重なビジネスロジックを維持しながら、将来のイノベーション需要に備えることができます。

Amazon Web Services ブログ