 |
|
|
| 前のページ 1 2 3
|
|
| 運用管理という落とし穴
|
Rehost型マイグレーションではハードウェア費用の削減効果とアプリケーションの移行費用にばかりに目がいき、移行後の運用管理に対する準備と検討が後回しにされがちである。
基本的にメインフレームは構成が比較的単純で環境変化も少ないため、従来から蓄積されてきた運用に関する手順・ルールなどの変更もあまりない。それに対して、オープン系は環境変化が多いため、運用に関する手順やルールなども頻繁に変更される。よって運用管理手順の標準化、運用管理システムを活用した自動化の対応が必要になる。
セキュリティ管理についてはメインフレームではユーザが限定されがちであり、ユーザ層相応のセキュリティレベルで対応可能なことが多い。それに対して、オープン系ではユーザ拡張が容易（Web環境では不特定多数）な反面、強固なセキュリティ対策が必要であり、システム・運用両面でのセキュリティ管理が必要となる。
障害管理についていうと、メインフレームでは機器の信頼性が高く、障害発生時のベンダーの専門家によるフォロー体制が充実しているが、オープン系では機器の信頼性がメインフレームに比べて相対的に低い。
また障害の一次切り分けが比較的困難なケースがあり、システム各レイヤで発生した情報を適切に伝達するためのメッセージ・ログ・エラーなど各機構の標準化などを整備しておかないと、障害時間の増加や運用保守コストの増大を招きかねない。
ハードウェア費用は削減できても、その他費用が増大してTCO削減が達成できないということにならないよう、運用管理面の検討を企画当初から行っておく必要がある。
|
| Rehost型マイグレーションプロジェクトの実際
|
Rehost型マイグレーションが同規模のシステムをゼロからスクラッチで構築するのに比べて、短工期で低コストであることは事実である（すべてを作るのではなく、必要部分のみを改造するだけなので当然である）。
現行アプリケーションを変換ツールにインプットすれば、アウトプットとして移行後のアプリケーションが吐き出されてくるのも一応事実である。しかし変換ツールは設計される必要があり、アウトプットとしてでてくる移行後のアプリケーションも検証される必要がある。
ビジネスロジックには変更がないといっても、周辺システムとのインターフェースについては現行保証のための改造は必要となる。リスク分散のため、移行対象が大規模な場合は分割構造に従ったサブシステム単位での移行を検討するが、移行対象サブシステムと既存サブシステム間の連携機構やデータステージング環境を設計・構築する必要がある。
データ移行については個別属性ごとに移行方式を検討して、それに基づくデータ移行ツールを作成する必要もある。移行後の基盤やミドルウェアの構成および運用管理の設計、それらを維持運用していく技術者の習熟も計画的に進めていかねばならない。
すなわち、Rehost型マイグレーションといえども、プロジェクトの考え方や開発プロセスは原則的には新規構築と同じであり、基本計画や基本設計から確実に実行するべきプロジェクトなのである。
|
前のページ 1 2 3
|
|
|
|
|
著者プロフィール
新日鉄ソリューションズ株式会社 荒木 義史
入社以来、製鉄所生産管理システムに対して、企画〜設計〜開発〜保守のソフトウェアライフサイクル全般に渡る業務に従事。現在は鉄鋼システムでの知見をもとにレガシーシステムを中心としたコンサルティング業務を担当。
|
|
|
|
|
|
