 |
≫ |
|
|
|
|
|
日本HPでは2005年9月7日（水）、「レガシーマイグレーション米国先進事例説明会」と題して、HP NonStopサーバとLinuxオープンソースのハイブリッド・システムによる米国先進事例を中心にご紹介するセミナーを開催いたしました。 |
|
|
|
|
|
|
セッション1：HPのレガシーマイグレーションに対する取り組み |
|
|
|
| |
日本ヒューレット・パッカード株式会社
コンサルティング・インテグレーション統括本部
ESP本部ESPソリューション本部 マネージャー
上野
俊作 |
|
|
|
最初のセッションは、日本HPのコンサルティング・インテグレーション統括本部ESP本部ESPソリューション本部マネージャー 上野俊作による「HPのレガシーマイグレーションに対する取り組み」と題した講演です。
講演の冒頭、上野は「レガシーシステムはトランプで建てた塔のようなものが多い。かたちを少し変えるにも非常に神経を使う。ちょっとでも間違えるとたちまち崩れてしまう」と指摘し、さらに次のように説明します。「数千本、数万本といったアプリケーションを抱えているお客様が多い一方で、ドキュメントとソースが一致していない、当時の開発者が現場から離れてしまっているなどの問題がある」。加えて、レガシーシステムが扱うデータについても、「RDBではなく階層型DBに蓄えられている」点がシステム拡張の上でのネックになると説明しました。
こうした課題を解消する手段として、レガシーシステムからオープンシステムへ移行する「レガシーマイグレーション」が不可欠になります。しかし、COBOLで動作していたアプリケーションをC++やJavaで単純に作り直せば済むようなものではない、と上野は説明します。「短絡的にCOBOLを捨ててしまうという考え方は、実態とは合っていない。事実、2000年以降、COBOLアプリケーションは年間10%
ずつ増えているという統計もある」。さらには、「一見すると意味が分からないが、実は過去のシステム構築上で理由があってそうしている事実を見落としてしまい、大きな落とし穴に落ちてしまうケースがある」（上野）。つまり、レガシーシステムの作り直しには大きなリスクも伴うのが実情です。 |
|
レガシーマイグレーションにおけるこうしたリスクを避けるためには、次に挙げる3種類のアプローチの組み合わせが考えられます。ひとつは、レガシーを残存させたままオープンシステムにより周辺機能を強化する「サラウンド」方式。2つ目は、レガシー上のアプリケーションをオープンシステムで完全に作り直す「リプレース」方式。3つ目は、レガシー上のアプリケーションをそのままオープンシステム上へ移植する「リホスト」方式です。
従来のレガシーマイグレーションはおもに「サラウンド」と「リプレース」方式を中心に進められてきました。しかし、上述のようなリスクやコストを低減させるには、3番目のリホスト方式を組み合わせる方法も効果的であると上野は説明します。「最近はコスト削減がレガシーマイグレーションの大きな目的となっており、現在のコスト高のITインフラを低コストのものに置き換えられないかというニーズから、リホストのアプローチが注目されている」（上野）
|
|
| |
 |
|
| 図 1：レガシーマイグレーションの3つのアプローチ |
|
|
| |
実際に日本HPが手がけたマイグレーション事例でも、これらのアプローチを適材適所で導入する方法が採用されています。「ひとつのアプローチで統一して移行するよりも、基本のアプローチを決めた上で、いくつかの最適なアプローチを組み合わせて移行していくという方法が一般的だ」（上野）。ここで紹介された事例では、メインフレーム上のアプリケーションからHP
NonStopサーバへの移行を実施。運用保守コストは25% 低下し、プログラムのモジュール本数は1/4に減少するという優れた成果が報告されています。
|
|
| |
本ページに記載されている情報は2005年9月時点におけるものであり、変更されている可能性があります。予めご了承下さい。 |
|
|
|
印刷用画面へ
