【目次へ戻る】
*** 酒井G長 添付ファイルより *************************************************************
レガシーマイグレーション(Legacy Migration)
1.レガシーマイグレーションとは
・メインフレーム或いはオフコンで構築されたシステムをWindowsやUNIXなどのオープン系
システムに移植すること。
Legacy(遺産、遺物)
Migration(移行、移送)
2.背景
メインフレームを使用したシステム(レガシーシステム)は、高い信頼性、実績があるが、その反面
以下の問題がある。
(1).保守、運用費用が高額で負担増。
・オープンシステム導入によるシステムの混在化により、維持費負担が増大
(2).システムの硬直化
・システム変更の繰り返しによるAP構造が複雑になり、修正や新規追加の影響範囲把握が困難。
(3).2007年問題
3.レガシーマイグレーションのタイプ
以上の様な問題を解消するために、マイグレーションが行われるが、その手法は以下の4種類に分類できる。
(1).リエンジニアリング(リビルド)
・ビジネスロジック(業務)のレベルからシステムを見直し、根本的にシステムを作り変えてしまう方法。
・代表格はERPパッケージ導入。
(2).リライト
・ビジネスロジック(業務)はそのまま維持し、PGMをJavaやC言語に、DBを別のものに書き換える方法。
(3).リホスト
・レガシーシステム上のPGM、DBをそのままオープン系システムに移植する方法。
・過去に実施した、紡織系システムがこれにあたる
(4).ラッピング
・レガシーシステム上のアプリケーションを外部システムからアクセスできるようにラッピングする方法。
・この場合にはメインフレームはそのまま維持することになる。
4.レガシーマイグレーションのタイプ毎の比較
|
方 式
|
ラッピング
|
リホスト
|
リライト
|
リエンジニアリ
ング |
|
移行(変更)対象部分 |
|
|
|
|
|
ビジネスロジック |
維持 |
維持 |
維持 |
変更 |
|
開発言語・プログラム構造 |
維持 |
維持 |
変更 |
変更 |
|
メインフレーム |
存続 |
廃棄 |
廃棄 |
廃棄 |
|
ハード、ソフト |
一部変更 |
変更 |
変更 |
変更 |
|
期待される効果 |
|
|
|
|
|
業務効率向上 |
× |
× |
× |
○ |
|
新業務要件対応における柔軟性 |
×
|
×
|
○
|
○
|
|
新技術対応における柔軟性 |
△
|
△
|
○
|
○
|
|
コスト削減 |
|
|
|
|
|
ホストの運用/維持費用 |
×
|
○
|
○
|
○
|
|
AP保守費用 |
× |
× |
○ |
○ |
|
業務量 |
× |
× |
× |
○ |
|
その他
|
逆にサーバー追加によるコスト増加 |
|
|
|
|
移行に必要となる期間、費用 |
|
|
|
|
|
期間・費用 |
小 |
小 |
中 |
大 |
住商リース レガシーマイグレーション検証
1.移植前環境
CPU:IBM9672−R15
OS :OS/390
DC :CICS/JES2
DB :Datacom
2.リホスト方式選択背景
(1). ・既存基幹システムは1994年4月IBMメインフレームで再構築
・途中、営業SFAなどフロント回りをオープン系で追加
・導入10年を機にシステムを見直し、既存システムが使えなくなっているかゼロから検証
・全面再構築が必要なほど陳腐化していない。
(2). リライト検討
・開発工数、周辺環境との相性。テストに莫大な時間と費用がかかり、どれだけの労力がかかるか
見えない部分があり、リスクが大きい。
(結果)
・初期コストを最小限に抑えながら、運用コストを削減するためにリホスト方式を選択。
3.移植後環境
CPU:SUN Fire V880(本番機)、V480(EDIサーバー)、V240(開発機)
OS :UNIX Solaris
DB:Oracle
移植ソフト:Sun Mainframe Transaction Processing(Sun MTP)
Sun Mainframe Batch Manager(Sun MBM)
・SunMTP・・・「CICS」のアプリケーションをSolarisオペレーティング環境においてほぼ無修正で動作させる
ソフトウェア
VSAMデータ、COBOL、PL/1言語で書かれたAPをを使い続けることが可能。
DB2、Oracleデータベースインタフェースも備えている。
・SunMBM・・・メインフレームのバッチ処理をSolarisオペレーティング環境上で再現するためのソフト
JCL翻訳機能を備えている。
4.設計・開発期間
・全面再構築と比べ、基本設計〜単体テストが省力化できる。また業務は変えないため、社員教育
がまったく不要となる。
・ただし、システム化計画、概要設計、IT基盤開発、総合テストは必要になる。
5.課題、問題点
・オープン系サーバー基盤に内在する課題(メインフレームに比べ性能、セキュリティで劣る)も移植
しまうことになるので、基盤環境についてもオープン系では十分な検討が必要。
・ビジネスロジックは変わらないので、あくまでも次期新システム再構築へのワンステップという認識
(住商リース)
(補)移行スケジュール
2004年1月 |
2004年4月 |
2004年7月 |
2005年2月 |
2005年5月 |
検証フェーズ |
移行フェーズ |
試験フェーズ |
本番フェーズ |
運用フェーズ |
・独自機能の検証 |
・資源移行の実施 |
・総合稼動試験 |
・本番移行 |
・運用開始 |
・移行資源の取捨選択・分析 |
・単体稼動試験 |
・運用実装 |
・フォローアップ |
|
・課題抽出 |
・運用設計 |
・本番移行計画 |
|
|