レガシー近代化戦略を決定する方法

レガシー アプリケーションには、表面的には明らかでない相互依存関係が存在することがよくあります。最も古いプログラムから始めて、それより前のプログラムに手を加えるという方法で最新化することは絶対に避けてください。

代わりに、独自に機能し、変更されても他のプログラムがダウンしないプログラムから始めましょう。 企業の複雑性分析 コードを詳しく調べて依存関係を見つけることで役立ちます。ツールは高価ですが、大規模なレガシー ポートフォリオを持つ企業にとっては、その価値がある場合が多くあります。

レガシーシステムのアップグレードも、どちらか一方を選択するというものではありません。ガートナーは7つの異なる 近代化の種類最も基本的な方法は、データと関数をカプセル化して、API 経由でサービスとして利用できるようにすることです。これは、コードにまったく触れる必要のないプロセスです。

さらに複雑なオプションには次のものがあります:

• アプリケーションを変更せずにクラウド インフラストラクチャに再デプロイする (「リフト アンド シフト」)
• 新しいランタイムプラットフォーム（ソフトウェアコンテナなど）への移行
• 既存のコードを再構築して最適化する
• 交換または再構築

最も基本的なアプローチでも、企業はより優れたスケーラビリティを実現し、クラウド内の新しい機能にアクセスできるようになります。

レガシー近代化の候補 5 つ

レガシー システムをアップグレードするための万能な戦略はありません。ソフトウェアの種類に応じて、特定の考慮事項が適用されます。

以下は、更新をサポートするための推奨戦略とともに、最も一般的なモダナイゼーションの例を 5 つ示します。

1. 時代遅れのシステム

時代遅れのシステムとは、メインフレームや COBOL の時代に組織がゼロから構築したシステムです。これらは最新化するのが最も難しいアプリケーションであり、そうすることは良い考えではないかもしれません。

システムがうまく機能し、組織にとって負担にならない場合は、そのままにしておくのが最善であることが多いです。代わりに、より現代的なパッケージ化された代替手段を探している間に、API として公開するデータと機能を収集すると役立つ場合があります。

2. 市販サーバー上のアプリケーション

Linux、Windows、または Unix を実行する X86 ベースのハードウェアを仮想化すると、組織は必要に応じてリソースを拡張し、利用可能なハードウェアの使用を最適化できるようになります。

仮想化により、一般的なデータ センター環境におけるサーバーの使用率が 20% 未満から 70% 以上に向上します。

仮想化されたアプリケーションをクラウドに移行することもできます。すべての主要なパブリック クラウド プロバイダーは、最も人気のある仮想化プラットフォームをサポートしています。

代替案としては、Docker などのソフトウェア コンテナーにアプリケーションをカプセル化する方法があります。コンテナーは、アプリケーションと、システム ライブラリや設定などの依存コンポーネントを 1 つのパッケージにまとめます。これは共有でき、リポジトリに保存できます。

仮想化とコンテナの両方のシナリオでは、アプリケーションの機能が妨げられることはありませんが、環境と割り当てられたリソースの点で柔軟性が向上します。

3. ビジネスプロセス

ビジネス プロセスはソフトウェアではありませんが、ワークフローの自動化やドキュメント管理を伴うアプリケーションに組み込まれていることがよくあります。

以下の場合には負債となる可能性があります:

• プロセスは最適化されていなかった
• ビジネスは変化した
• テクノロジーによって改善が可能になった

ビジネス プロセス分析は、既存のプロセスを調べて新しい効率性を見つけるのに役立つ方法です。この作業を自動化するツールは多数あります。ユーザーはドラッグ アンド ドロップ ツールを使用してビジネス フローを視覚化したり、ビジネス フローの改善方法に関する自動アドバイスを受け取ったりできます。

ロボットプロセス自動化 RPA は、ハイパーオートメーションと呼ばれる急速に成長しているツールのカテゴリの一部です。これらのツールは、印刷された文書からデータを入力するなど、人間の日常的なタスクを自動化します。

ハイパーオートメーションの他の形式は次のとおりです。

• ローコードアプリケーション開発
• イベントブローカー
• ドキュメントキャプチャソフトウェア
• プロセスディスカバリー
• 予測的意思決定モデリング

これらはすべて、プロセスの合理化と自動化に役立ちます。

4. API統合

この統合により、アプリケーション サービスとデータが他のソフトウェアで使用できる形で公開されます。

たとえば、既存のアプリケーション内のクレジットカード承認プロセスをカプセル化して API として公開できます。API を使用して古いアプリケーションを改造するためのツールが多数用意されており、時間をかけて徐々に最新化することができます。これは、より最新のものを作成またはインストールしながら、古いソフトウェアの寿命を延ばす簡単な方法です。

5. エンタープライズ サービス バス (ESB)

ESB は、アプリケーション間のサービスの交換を調整します。これにより、アプリケーションは単純なルールに基づいてメッセージをサブスクライブでき、サービスを配布する標準的な方法を提供します。

ESB は長い間存在してきましたが、クラウド コンピューティングによってソフトウェアの構築方法が変わったため、その概念は新しくなりました。

最新のクラウド アプリケーションは、オンザフライで組み立てられる疎結合のソフトウェア機能で構成されています。ESB を使用すると、開発者は新しいサービスをプラグインすることで機能を強化および拡張できます。

たとえば、クラウド サービスを使用して新しいユーザー インターフェイスを構築し、API 経由で処理するために従来のバックエンド システムに接続できます。

パッケージアプリケーション

1990 年代には、クライアント サーバー ソフトウェアが大流行しました。しかし、現在では、クラウドを通じて提供されるサービスとしてのソフトウェア (SaaS) がその人気を上回っています。

レガシープラットフォームをベースにアプリケーションを構築するためにリソースを投入してきた場合、これは問題となります。特にLotus Notesなど、多くのプラットフォームが独自のファイルシステムとスクリプト言語を使用していたため、これは顕著です。

顧客関係管理などの統合がかなり進んでいる市場では、ほとんどの買収企業は顧客に古いアプリケーションへの移行パスを提供するために懸命に取り組んできました。

ただし、クライアント サーバー ソフトウェアから移行する前に、同等のクラウド ネイティブ アプリケーションの方が機能が優れているかどうかを確認してください。レガシー データが SQL 準拠のデータベースにある場合、データ移行は問題にならないはずです。

クライアント サーバー アプリケーションが大幅にカスタマイズされていたり、独自の開発ツールで構築されていたりしたらどうなるでしょうか。専門のインテグレーターの支援を求めるか、損失を覚悟してそれらの機能を最初から再構築するのが最善策です。

現在、主要なアプリケーションのほとんどがクラウドで利用できるようになっているため、API を使用して以前の変更を再コーディングし、コア アプリケーションから分離することで、この問題に対処できる可能性があります。企業は、基本パッケージの機能強化のメリットを享受しながら、カスタマイズを維持できます。

クラウドでのDevOps

アジャイル開発手法 DevOps は、クラウドでアプリケーションを構築するためのお気に入りのオプションです。これは、ウォーターフォール モデルなどの従来の方法に価値がないという意味ではありません。ただし、トップダウン構造と厳格なプロセスは、機能の急速な進化には適していません。

DevOps では以下を推奨します。

• 開発者とビジネスユーザーの緊密な連携
• 毎日のコードリリースによる迅速な反復
• 継続的なフィードバック
• サービスの広範な利用

開発者は独自のインフラストラクチャをプロビジョニングし、移植性のためにコンテナでソフトウェアを配信できます。

レガシー チェーンに縛られないでください。エンタープライズ アプリケーションの最新化オプションは急増しており、コストは低下しています。クラウド コンピューティング時代に対応することを目標にソフトウェア ポートフォリオを再検討するのに、今ほど良い時期はありません。