レガシーアプリケーションのアプリケーションの書換えがコストのかかる間違いである理由とその回避方法

メインフレーム上のアプリケーションを最新化する必要があるのはなぜでしょうか？ レガシーアプリケーションを導入当時から何10年も使い続けると、殆どの場合、コストのかかる間違いになります。その理由と回避方法を見てみましょう。

長く暗くねじれた道

企業にとっては、アプリケーションとインフラのモダナイゼーションが競合との差別化につながります。また、データのプライバシー対策がグローバルに導入されているため、コンプライアンスに準拠するために最新化する必要があります。メインフレームでコアビジネスを実行している企業の90％は、その対応に苦労しています。

結果として、オープンでクラウド環境への移行の一環としてメインフレームのアプリケーションを書き直すという、多くの人が賢明で前向きな考え方を採用する誘惑があります。ただし、結局のところ、その道は長くて暗い曲がりくねった道であり、すべての旅費を使い果たし、行き止まりになる可能性があります。実際、Standish GroupとGartnerの両方のレポートによると、レガシーアプリケーションの書き換えの70％以上が成功していません。最も有名なものの1つは、オーストラリアのクイーンズランドヘルスで使用されている古い給与計算ソフトウェアの書き換えです。プロジェクトの費用は600万ドルで、導入時に失敗したため、従業員の支払いは混乱していました。これはクイーンズランド州政府に12億ドルの費用がかかると推定されています。

これらのプロジェクトがうまくいかないのはなぜですか？いくつかの理由があります。

アプリケーションロジック・コーディング・テスト

ビジネスアプリケーションを書き換えるには、誰かがビジネスプロセスに基づいて既存のアプリケーションロジックを適切に解釈し、それらを新しいコードベースで、多くの場合、手動で書き換える必要があります。データベースとデータの書換・移行も必要になります。ITチームがコーディングとロジックのハードルを乗り越えた場合、次の課題はハードウェアとオペレーティングシステムの違いです。複数のアプリケーションでこれを行う必要がある場合、書き換えと再コーディングのプロジェクト全体で何年もかかる可能性があります。その後、広範囲にわたる時間のかかるユーザーテストが行われます。大幅な遅延、データ損失、コスト超過、またはエラーが発生する可能性が高く、数百万行のコードの1つのエラーだけで障害が発生する可能性があります。

年齢とサポート

次に、メインフレーム上の一部のアプリケーションが20年以上使用されている可能性があるという事実があります。多くの場合、元の所有者、プログラマー、ベンダー、またはこれらのアプリの詳細は、長い間になくなっており、識別できません。これらの古いアプリケーションはメインフレームのパフォーマンスを低下させ、それらのサポートにはコストがかかる可能性があります。それらのスパゲッティアーキテクチャとカスタマイズのために、これらを書き直そうとすることはほとんど不可能です。それでも、それらはまだ必要なので破棄することはできません。メインフレームが4分の1世紀以上稼働している場合、この規模のオーバーホールはビジネスに大きな悪影響を与える可能性があります。

レガシーアプリの書き換えにかかる費用

従来のアプリの書き換えには、現代のビジネスの要求を満たすために必要な現代の言語、テクノロジー、コーディングのスキルを備えた追加のITリソースが必要になる可能性があります。数十から数百の複雑なCOBOL、アセンブラー、またはPL / Iアプリケーションを置き換える必要があります。それぞれのアプリケーションは、Java、Ruby、PHPなどの言語で記述されたアプリケーション、およびモバイル向けの新しいテクノロジーのホストとともに、20,000行のコード長になります。そして、それは単なるソースコードの部分です。再設計、データベース作業、未知の相互依存関係のオーバーレイにより、複雑さが増します。さまざまなグループが書き換えの作業に取り組んでいるため、プロジェクトのオーバーヘッドはすぐに制御不能になり、すべてが成功する保証はありません。

メインフレームの書き換えは、非常に多くのレベル（インフラストラクチャ、リソース、時間、労力、および支出）で費用がかかり、長期的なコストの削減は保証されていません。メインフレームの保守は、大企業では毎年数百万単位で実行できます。これは、再開発、再設計、翻訳、テストなどのコストを考慮に入れる前です。たとえば、10年前のケイパーズジョーンズによれば、1つのメインフレームのプログラムだけを書き換えるコストが約50万ドル（5.5千万円相当）にもなる可能性もあります。

成功が30％未満の事業に対して、どの企業が、このような大きな経済的リスクを負えるのでしょうか？

書き換えの高コストを回避する方法＝＞リホスティング

従来のメインフレームアプリをオープン環境にリホストすることで、書き換えのコスト効率が高くなり、成功率が大幅に向上します。リホストでは、アプリケーションは書き換えられていないため、ビジネスロジック、インターフェイス、または機能に変更はありません。

アプリはより安価でオープンなシステム環境に移行し、これらの古いアプリケーションをより新しくより優れたオプションに置き換えることができるため、メインフレームのパフォーマンスが向上します。それらを段階的に改善するためにコアITシステムを最新化すると、書き直しで新しく開始する場合と比較して、プロジェクト失敗のリスクがはるかに少なくなります。それだけでなく、プラットフォームを再構築したITリーダーは、オープンシステムまたはクラウドで実行されているレガシーアプリケーションを最適化および再構築する方が簡単だったと述べています。データの最新化とアプリケーションのオープンシステムへの移行がリホスティングによって行われると、書き直しをより複雑でリスクの少ないものにするでしょう。

成功率を高めるためには、、レガシーソースコードを取得し、ビジネスロジックを変更せずに新しい環境でプログラムを再コンパイルしてから、メインフレームデータを新しいデータベース環境に移行することです。セキュリティプロファイル、オンラインおよびバッチの構成と定義、データセットシステム管理プロファイルもオープン環境で再利用できます。

選択は明確

全面的で大規模な書き直しプロジェクトの予算、時間、およびリソースがあったとしても、成功率が高く、より優れた、より高速なオプションを選択すべきでしょう。そして、オープン環境に移行後にその予算を生産性や競争力を高めるITシステムに投資しましょう。

さらに詳しく知るために！

TmaxSoftのOpenFrameは、プロジェクトの成功率がほぼ100％のリホスティングプラットフォームです。確かな実績が証明しています。移行はリスクが低く、他のモダナイゼーション方式と比較しても短時間で移行が完了します。OpenFrameプロジェクトは6～12か月で完了することもできます。詳細については、日本ティーマックスソフト株式会社にお問い合わせください。