レガシーの地層構造
前回の記事において、IBM iのプラットフォームとしての進化を紹介したが、その中で新しい言語記述様式、データベースフィールド記述様式などが実装された場合、そのリリース以降の新規開発は、新しい記述様式で行っている場合がある。年代ごとに違った様式のリソースが地層化している例も少なくない。
さらに、長年のユーザーごとのIBM i利用の歴史の中で、さまざまな担当者、外注先ベンダーの異なる開発手法、開発標準で組まれたアプリケーションが時代に沿って地層化している場合も多い。ここに過去のパッケージソフトウェアの導入も絡み、地層の複雑化と理解の難しさを生んでいる。モダナイゼーションを推進したい側の人間にとっては、隆起した地層のような大きな崖となっている。
レガシーのダブルロック
第1回の記事における「国産オフコンとの違い」において、IBM iの市場撤退は現時点においては無く、むしろ、国産汎用機やオフコンのリプレース先として選択されていることを紹介した。COBOLが利用できる点も大きな理由の一つである。
しかし、このリプレースにおいて以下のような手法を取った場合、レガシーのダブルロックという問題を抱えることとなる。
- 国産汎用機やオフコンの操作をそのままIBM iで再現するために、IBM iで国産機の独自コマンドなどを利用できる基盤ソフトウェアを導入する
- 国産汎用機やオフコンのプログラムにおける順次ファイルや索引ファイルなど、IBM iでは利用できない各種ファイルの操作をそのまま再現できる基盤ソフトウェアを導入して、プログラム内の変更を微少に留める。
既存アプリケーション資産を使いなれた国産汎用機やオフコンの開発手法や操作方法そのままで利用できるメリットがあるが、モダナイゼーションを行いたい側の視点から見ると、マイグレーションベンダーが開発したIBM iの基盤ソフトウェアやフレームワークの上に国産汎用機やオフコンのアプリケーションリソースが載っている状態となる。IBM iと元の国産機双方の理解が必要となり、大きな障壁となっている。
モダナイゼーションを阻む、乗り越えなくてはいけない条件をおわかりいただけただろうか？
次回は「IBM i（AS/400）のレガシーの近代化パターン」と題し、障壁を乗り越えて、未来へ進むためのモダナイゼーションの「新しい選択肢」を示したいと思う。
（第4回は11月中旬にて掲載予定）
- 阿野 幸裕（あの ゆきひろ）
- ジーアールソリューションズ
- モダナイゼーション事業部長
-
大学卒業後、トーメン情報システムズで、IBMメインフレーム、ミッドレンジコンピューター、UNIXなどのシステム開発を経験後、1995年よりSybaseやSASなどの外資系ソフトベンダーにてプリセールスエンジニアとして従事。
2020年4月から、その経験を生かし、ジーアールソリューションズに入社。以来、同社が独占販売権を持つカナダFresche solution社の製品を中核としたモダナイゼーション事業に参画している。
