レガシーアプリケーションとは何ですか?

ITの世界では、よく耳にする 「レガシーシステム」 この用語は、組織で何年も使用され続けているため、もはや最先端でも最新でもないシステムを指します。

レガシーシステムはソフトウェアやハードウェア、ファイル形式やプログラミング言語である可能性があります。これを考慮すると、 a 「レガシーアプリケーション」 時代遅れの、または時代遅れになりつつあるアプリケーションです。 レガシーアプリ バグが多く、更新が難しい場合は、時間が経つにつれて問題が発生する可能性があります。

レガシー アプリを使い続けると、アプリが最新のオペレーティング システムとの互換性を失った場合に組織が大惨事に見舞われるリスクがあり、セキュリティの脆弱性につながる可能性もあります。

このブログ記事では、レガシー アプリケーションを最新化する手順と、この最新化プロセスに含まれる内容について説明します。

レガシーシステムとアプリケーションが懸念されるのはなぜですか?

レガシー システムには、ミッション クリティカルでありながら時代遅れのビジネス プロセスとテクノロジが含まれます。PC が企業で主流になり始めたとき、メインフレーム ソフトウェアは「レガシー アプリケーション」と呼ばれるようになりました。

「レガシーアプリケーション 「新しい子供たちが遊びたくないもの」とITサービスプロバイダーの最高開発責任者、ゲイリー・ベイニー氏は言う。 高度サーバー管理グループ (ASMGi) 「これは、最終的には持続可能性、保守性、そしてアプリケーション開発プロセスにどれだけの技術的熱意が存在するかを定義するため、最良の技術的定義です。」

レガシー システムは本来の目的に限定されており、より現代的なテクノロジーと統合するのは通常、容易ではなく、コスト効率も良くありません。

「ビジネスとテクノロジー開発の間には共生関係があります」と Baney 氏は言います。「レガシー アプリケーションの最大の欠点は、共生関係が失われていることです。」

レガシーソフトウェアを廃止する必要があるのはなぜですか?

「コードがどの言語で書かれているか、ソフトウェアパッケージがどれくらい古いかよりも、それを維持、サポート、保守できるかどうかの方が重要です」と、CTOのピーター・アンダーソン氏は言う。 コンピュータシステムセンター （CCSI）「メーカーの寿命と、私たちがどの程度のリスクを負う覚悟があるかが重要になります。」

8 年に製造された 1969 ビット コンピュータを今日の現場で実行することを想像してください。プログラマーを見つけることは、システムを実行するために必要な真空管を製造できる技術者を見つけることと同じくらい困難です。 建設当時、交換用ボードの価格は 400 ドルでした。現在では 70,000 ドル以上かかります。

「技術に関する決定を下す人々は、その決定によって直接影響を受けることはありません」とアンダーソン氏は言う。「彼らは、総所有コストではなく、自己負担コストの観点から物事を見ています。一方、私は真空管を製造してすべてをテストするのにどれだけの費用がかかるかを考えています。古いシステムを維持することは、新しいシステムを購入するよりもコストがかかる可能性があります。」

コストが常に障壁となるわけではない

古いシステムを維持するためのコストは変更が必要であることを示している可能性がありますが、新しいソリューションに必要以上に費用がかかってしまう可能性もあります。

Baney の顧客の 500,000 社は、18 年前のエンタープライズ リソース管理 (ERP) システムを完全に置き換えるために、10 か月かけて XNUMX 万ドルを費やす用意がありました。レガシーの近代化にもっと戦略的なアプローチを取れば、同じ機能を XNUMX 分の XNUMX 未満のコストで提供し、XNUMX 分の XNUMX 未満の時間で完了できます。

「クライアントは 8 種類の新しい機能を追加したいと考えていました。私たちが本当にやらなければならなかったのは、ハンドヘルド デバイスを既存の ERP データベースに結び付けるだけでした」と Baney 氏は言います。

レガシー システムの機能を拡張することにより、クライアントの近代化プロジェクトには次のものが含まれていました。

• データベースと本番サーバーのアップグレード
• 旧システムの処理能力を向上させるために、より高速なストレージを追加する
• 新しいモバイルフロントエンド

「彼らはまだレガシーアプリを運用しており、85,000ドルで必要なものをすべて手に入れました」と彼は言う。

近代化の時期を決めるのは誰ですか?

レガシー アプリケーションの置き換えに関する不適切な決定は、テクノロジの決定がビジネス要件と一致していない場合に発生します。選択するものとその適用方法は、特定の業界で競合他社をリードするか、遅れをとるかの違いを意味する場合があります。

CSCI の CTO として、アンダーソン氏は CFO と CEO に提案を行う責任を負っています。その前に、彼はシステム運用責任者およびシステム開発責任者と定期的に会議を開いています。彼らは共同で、ハードウェアが時代遅れになっているかどうか、現在の開発者ベースがコードにアクセスしたりコードを変更したりできるかどうかを判断し、その提案を行います。

「ハードウェアが見つからなかったり、開発の専門知識がなくなったりする状況に陥ると、必要以上にリスクを負っているという不安を感じます」とアンダーソン氏は言う。「私の CEO は、経済要因が中小企業に影響を及ぼしているときにリスクを負うことを好みません。」

非常に洗練された組織は、ビジネス部門と IT 部門のプロフェッショナル間のコミュニケーションの改善に積極的に取り組んでいますが、課題は残っています。多くの技術者は、ビジネス部門が自分たちを十分尊重していないと考え、ビジネス部門に時間を割きません。また、技術者が十分に耳を傾けていないと考え、技術者を尊重しないビジネス部門もあります。「企業文化が繁栄し、永続的に競争力を維持するには、ビジネス部門とテクノロジー グループの間に強力なパートナーシップ意識が必要です」と、ASMGi の Baney 氏は言います。

レガシー近代化プロセスの管理

ノーム・リングゴールド、元ITオペレーションおよびインフラストラクチャ責任者 スタンフォード リニア アクセラレーター センター (SLAC) は、中規模から大規模の企業で一般的になりつつある、形式化された IT インフラストラクチャ ライブラリ (ITIL) アプリケーション ライフサイクル (ALC) 方式で、レガシー アプリケーションの移行を管理します。その考え方は、管理機関がビジネス価値提案に基づいて「情報に基づいた」IT ビジネス上の決定を下すべきであるというものです。

新しいビジネス ソリューションを開発するにはコストがかかります。既存のアプリケーションが引き続きビジネス要件に対応し、完全なプラットフォーム、ライセンス、サービス、およびサポート モデルが継続的な価値提案を提供するのであれば、なぜ変更する必要があるのでしょうか。

「通常、価値に基づくビジネス ドライバーやテクノロジの緊急事態によって必要でない限り、アプリケーション ソリューションの変更を提案することはありません」と Ringgold 氏は言います。「多くの場合、アプリケーションのライフサイクルは、合併や買収などの何らかの重要なイベントによって決まります。」

例えば、 オラクル 取得 サン·マイクロシステムズ Sun Solaris プラットフォームの廃止を宣言したことで、世界的なアプリケーションの変更を必要とする技術的な緊急事態が発生しました。また、サードパーティ ソリューションの機会も生まれました。

リングゴールド氏が当時勤務していた米国郵政公社には、Solaris アプリケーションを実行するサーバーが 2,000 台ありました。サンによる買収のような出来事は顧客が完全に予測できるものではありませんが、そのリスクやその他のリスクを管理して、影響を最小限に抑えることは可能です。

ROIの決定

状況や天文学的な維持費などによって変更が必要であることが示唆された場合、Ringgold は、より良い ROI を別の方法で達成できるかどうかを事前に調査します。

ROI の向上が見込まれる場合は、次の内容を含む提案を審査委員会に提出します。

• 現在のビジネスプロセスをより詳細に調査するためのコスト
• 特定の時点でアプリケーションがどのように動作しているか
• ハードウェア、ソフトウェア、仮想マシン、アプリケーション、エンドユーザーのトレーニング、使用コストなどの交換オプション

彼は、ビジネスに基づいた決定を下すために、複数のベンダーからの 3 つのソリューションを提示する場合があります。「企業は、プラットフォーム、アプリケーション、ベンダー ソリューション、および総メンテナンス コストを選択するのに十分な情報を持っている必要があります」と Ringgold 氏は言います。

「SDLC はまだ必要ですが、より洗練された方法で対処する必要があります。」今日の IT リーダーのアプリケーション管理戦略スタイルには、情報に通じたガバナンス エンティティ (主要なビジネスとテクノロジーの代表者を含む) が、すべての主要なテクノロジーの決定に関与することが含まれます。「パートナーシップにより、価値の高いソリューションの提供と、価値の低いレガシー ソリューションのタイムリーな置き換えが保証されます」と Ringgold 氏は言います。

レガシーアプリケーションを最新化する4つのステップ

レガシーの移行には、多くの場合、人とテクノロジーが関わるいくつかの摩擦点があります。大規模な組織では正式なガバナンス機関を持つことが不可欠ですが、小規模な組織では、そのような形式主義が俊敏性に悪影響を及ぼすことを懸念しています。

小規模な企業は、ガバナンス組織を設けるという考えに抵抗するかもしれない。「20 人で十分であれば、3 人もの人員は必要ないことを彼らに思い出させます」とリングゴールド氏は言う。

アプリケーションの変更を管理しようとして企業が倒産する可能性もあります。「それに備える最善の方法は、ソフトウェア開発ライフサイクル、アプリケーションライフサイクル管理、そして変化に対応できるガバナンス組織を導入することです。 アジャイルな変化「ビジネス要件に結びついています。」

テクノロジーに関しては、ベイニー氏は見落としを避けるための4段階のアプローチを提案している。

1. 書類が完全であることを確認する

ソフトウェアやシステムが適切に文書化されていない場合、または文書が最新の状態に保たれていない場合、問題が発生します。理想的には、文書化によって、コード ベース、アーキテクチャ、統合、および API の実際の状態を確認できるようにする必要があります。

2. アプリケーションの安定性を判断する

Baney はエラー ログをチェックして、欠陥がどこにあるのか、またそれらのエラーが企業内でどのような波及効果をもたらしているのかを判断します。サービス レベルが低下している可能性があり、その根本原因は特定のアプリケーションにある可能性があります。

3. 統合ポイントを理解する

これにより、どのアプリケーションが他のアプリケーションを監視して通信しているか、また何か変更があった場合にどのインターフェースを再構築する必要があるかを判断するのに役立ちます。

「『ここを書き直す必要がありますが、あなたに影響するような波及効果は作りたくないのです』と伝える会議を数回開く必要があります」と Baney 氏は言います。「インターフェースと API を徹底的に研究し、よく理解する必要があります。」

4. アプリケーションのワークフローを理解することを目標に、ビジネスユニットと話し合う

現在のワークフローは、マネージャーの個人的な好みによるもの、またはビジネス プロセスの効率性を向上させるために特別に設計されたものである可能性があります。ビジネス ワークフローを詳しく説明します。正しい方法で作業を行っているか、改善の余地があるかどうかを確認します。

「改善の余地があれば、それを ROI に結び付けてください」と Baney 氏は言います。「請求担当者の請求処理時間を 20 分から 11 分に短縮できれば、顧客体験に影響を与えたことになります。効率、顧客満足度、正確性はすべて ROI につながります。」

変化は避けられない

レガシー近代化プロセスをどのように管理するかによって、競争力を維持できるか、それとも競争に遅れをとるかが決まります。

組織の規模に関係なく、どのような変更が必要で、いつ変更する必要があるかを判断するプロセスが必要です。会社の利益を最優先に考え、リスクを最小限に抑えるという 2 つの目標を持つ意思決定者のグループを設立します。

オペレーティング システムのサポート終了日など、予測できる変更もありますが、予測できない変更もあります。賢明な組織は、変更管理を優先し、計画されたイベントと計画外のイベントを、不必要なリスクとコストを最小限に抑える方法で管理します。