レガシーマイグレーション

この記事のURLhttp://japan.internet.com/public/technology/20050209/5.html

システムのライフサイクル全般は開発環境、実行環境、さらに運用環境に大別できるが、実行環境のオープンプラットフォーム化であるレガシーマイグレーションはミッションクリティカルなトランザクション処理システムの再構築がポイントとなる。トランザクション処理システムは、通常ストレートコンバージョンで対応できない。

レガシーマイグレーションにおける、オープン COBOL 化によるオープン系プラットフォームに変更する方法の問題として、ホストメインフレーム時代に問題なく処理できていたトランザクション処理が、オープン系プラットフォームに変更すると業務に支障をきたすほど高負荷になる場合を挙げることができる。

大規模トランザクション処理システム構築実績のないシステムインテグレーター（SIer）は、構築途中で CPU 追加、クライアントマシン高性能化等の要請をするが、客の同意が得られず、プロジェクトは暗礁に乗り上げるケースが多々ある。

この原因のひとつとして、Web ベースや EAI などの流行のキーワードにとらわれすぎていて核となる TP モニタを見逃していることがある。

一般的にオープン化は、システム効率をハードウェアに依存しているためトランザクションが集中した場合、資源がなくなり業務が停止する可能性を持っている。

処理ロジックをクライアントから切り離すことができる TP モニタを導入すれば、ネットワークを流れるデータ量を制御することができ、複数ユーザが同時に要求を送ってきても資源を使いきる状況が起こらないように制御できる。

さらに、TP モニタでトランザクションを分散処理すれば、仮にサーバに障害やスローダウンが起こっても、他のサーバに処理を割り振ることで、業務を止める心配はない。

TP モニタの使用によって、オープン環境でもメインフレームクラスに匹敵する可用性が実現可能である。

TP モニタは、レガシーマイグレーションの成否を左右する重要な要素であるがオープンソースとしての製品はまだないため製品提供者のサポート力も製品選択の要素になる。 単なるオープン COBOL 化によるオープン系プラットフォームに変更する方法でも、確かにメインフレームにかかっていた膨大なコストを削減できるが、コスト削減にとらわれすぎて、近視眼的なビジョンでマイグレーションを進めるのは、かえってリスクが大きくなる。

今後のシステム構築の考え方のひとつとしてサービス指向アーキテクチャ（SOA）がある。

これは、普遍的な業務ロジック部分を COBOL のままコンポーネント化して TP モニタで処理し、新しいロジックは Java で開発し、Web サービス上で業務ロジックと新しいロジックをワークフローで繋ぎ、新しいサービスを提供できる環境を整備する方法である。

プラットフォームや言語に捕われず、サービスという視点で柔軟にシステムを追加・変更できるIT基盤を構築する SOA は、これまで開発してきたシステム資産やこれから開発するシステム資産を、“サービス”という単位の業務要素で切出し、それをビジネスプロセス上で再利用することで高い生産性を実現する。これによって、新しいサービスが迅速かつ低コストで提供できるため、企業の競争力を強化することが可能となる。

既存資産を新たな形で再利用し、競争力を高めることが、レガシーマイグレーションの目標である。

湯川 高繁

日本ユニシス株式会社
官公庁事業部
官公ビジネス統括部
官公ビジネス二部

提供:日本ユニシス