近代化すべきレガシーアプリケーションを判定する--そのための4つのステップ

文:Justin James(TechRepublic) 翻訳校正:村上雅章・野崎裕子
2010-03-31 07:00:00
  • このエントリーをはてなブックマークに追加

 本記事では、Micro Focusの上級ソリューションエンジニアであるCraig Marble氏が開発者に対して推奨している、近代化すべきレガシーアプリケーションの判定方法と、そのプロセスにおける優先順位付けの方法を紹介する。

 レガシーシステムを今後、どのようにしていくべきかというトピックはこのブログでも何度か採り上げており、他の開発者との会話においてもよく登場する。

 「レガシー」の定義は人によって異なる。例えば、40年前に開発されたCOBOLアプリケーションを意味する場合もあれば、10年前に作成されたASPのウェブページを意味する場合もある。しかし、共通している点もある。それは、こういったシステムがほとんどの企業において未だに現役として使用されているという点と、「手を入れる価値のあるアプリケーションはどれか?」という疑問が定期的に出てくるという点である。

 筆者は最近、古くからレガシーアプリケーションにかかわっており、Micro Focusで上級ソリューションエンジニアを務めているCraig Marble氏とともに、近代化すべきレガシーアプリケーションの判定方法と、そのプロセスの優先順位付けの方法について話をする機会があった。

 ここで言う近代化とは、アプリケーションに対して以下のような措置を講じることである。

  • SOA戦略に組み込めるように改修する(既存のSOA戦略がある場合)。
  • クラウド(パブリッククラウドあるいはプライベートクラウド)アプリケーションとして実行できるようにする。
  • 一部の機能をWebサービスとして公開する。
  • CUIプログラムを、Webベースのフロントエンドを使ってGUI化する。
  • 総所有コスト(TCO)を削減できるような、まったく異なったプラットフォーム上で実行できるようにする。

 最終的な目標は、コストを削減し(これには取り組み自体のROI、すなわち投資収益率も重要となる)、ITのアジリティを向上させることである。Marble氏によると、たいていの場合はコードを全面的に書き直したり、一部のコードを置き換えるよりも近代化を行うことが望ましい選択肢となり、アプリケーションの規模が大きくなればなるほど、その傾向は強くなるという。筆者も同意見である。アプリケーションの規模が非常に小さいケースは別にして、包括的かつ徹底的な分析工程や、十分なテスト工程を経ることなくコードの全面書き換えや、一部コードの置き換えを行った場合、異なったアルゴリズムで実装してしまったり、互換性のない機能を作り上げてしまう可能性が高まるのである。

  • 新着記事
  • 特集
  • ブログ
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]