MFA (メインフレーム移行)プログラム

メインフレームの移行戦略

• メインフレーム上で新規アプリケーションの開発は行わない。
• オープン上での新規アプリケーション構築やオープン系ストレージの増設をしていくアプローチ。
• 既存のメインフレームと新規のオープン系システムを統合していくアプローチ。
• リスクは少ない。

• メインフレームの処理能力が限界に達している。
• メインフレームを新たに増設したり、強化するのは困難。
• 標準アプリケーションで稼動しているアプリケーションをオープンシステムに切り出す。
• 同じパッケージを用いることにとってリスクを低減。

• メインフレーム環境をオープン系に移行したい。
• H/W や M/W を変更することによって、TCO を削減したい。
• ホスト上のアプリケーションをオープン上に「マイグレーション」するアプローチ。
• 既存資産の積極利用により、開発期間やリスクを低減。

• EA などに代表される水平統合基盤を実現したい。
• 現状のアプリケーションはビジネスの変化に対応できなくなっている。(俊敏性がない)
• 既存のアプリケーションの全面的な刷新とインフラのオープン化。
• 変化適応性に最も優れたシステムとして生まれ変わる。

開発アプローチ

メインフレーム上の資産を移行する場合、サブシステムごとの単位でどのシステムがどのアプローチにむいているかをまず、最初に検討します。一番 RoIT が期待できる手法を選択、確認し、それに基づいて実際の計画を立てるのです。メインフレーム上の資産は膨大で、それぞれが単一な手法で移行すればいいというような単純なものではありません。HP ではこの観点から、それぞれのサブシステムでの移行アプローチをまず確認し、お客様に提案するのです。

移行目的の再確認

レガシーシステムの移行の目的を、ビジネス価値、コスト、技術的価値、あるいはその他の要因のどこにあるのかを調査し、目的を再度明確にします。

• TCOの削減
• 変化への適応

現行資産の分析

現状の資産分析を行います。すでに使われなくてなっているアプリケーションや、ビジネスへのインパクト、技術的難易度などを精査し、システムごとに移行先のアーキテクチャの選択や方法論を決定する元情報とします。

• 対象アプリケーションのビジネス価値
• 対象アプリケーションのコスト
• ビジネス環境の変化への適応性

移行アプローチの決定

サブシステム単位で、今後のサブシステムの拡張の可能性や、移行の価値を判断し、それぞれのマイグレーションのアプローチの決定します。ビジネスロジックの修正が必要であれば、プロセス全体を改善するというアプローチをとることも可能です。

• マイグレーションに用いるツール、パッケージ、ソフトウェアの決定 (アプローチによる)
• マイグレーションの方法論の決定
• アーキテクチャの選定