ソフトウェアのモダナイゼーション:ソリューション、戦略、例。

ソフトウェアのモダナイゼーション:ソリューション、戦略、例。

  • ITOps・DevOps
6分で読めます 更新日 Nov 21, 2024

ポイント: ソフトウェアのモダナイゼーションは、書き換え、置き換え、再利用などの戦略を通じて、効率と敏捷性を向上させるために古いアプリケーションをアップグレードすることを含みます。これは、レガシーシステムによってもたらされるリスクを軽減しながら、ビジネスニーズに対処します。

  • モダナイゼーションはコストを削減し、応答性を向上させる可能性があります。
  • レガシーシステムは移行前に慎重に評価する必要があります。

デジタルトランスフォーメーションは、積極的であることが求められます。そして、ソフトウェアやアプリケーションのモダナイゼーションは、成功したデジタルトランスフォーメーションの重要な部分です。結局、レガシーソフトウェアアプリケーションや技術は、デジタルファーストのユーザー体験とビジネス運営を可能にする組織の能力を制限します。

この感情は、企業IT業界全体に当てはまります。800人のシニアIT意思決定者を対象に実施された調査によると、回答者の80%は、アプリケーションやITインフラをモダナイズしないことが、自社ビジネスの長期的な成長に悪影響を及ぼすと考えています。

レガシーからモダナイズされたインフラ技術に成功裏に移行した組織は、年間14%の収益増加を期待できるはずです。これらの組織は、技術進化の次の段階を活用する準備も整っています。フロンティア技術は、人工知能やブロックチェーンから遺伝子編集やナノテクノロジーに至るまで、2025年までに3.2兆ドルに達すると予想されています。最近の国連の研究報告によると、そうです。

この記事では、アプリケーションとソフトウェアのモダナイゼーションが何を意味するのかを見ていきます。機会とリスクを探り、次に実行可能なアプローチとベストプラクティスについて議論します。

さあ、始めましょう!

ソフトウェア開発におけるモダナイゼーションとは何ですか?

アプリケーションとソフトウェアのモダナイゼーションはその通りです—アプリやソフトウェアを現代化することです。

実際には、既存の伝統的なソフトウェア機能から最新のIT環境に適合するコンテキストに移行することです。最も明白な例は、メインフレームによって動かされる伝統的なオンプレミスデータセンターモデルから、マイクロサービスとコンテナに富んだクラウド環境への移行です。

クラウド vs メインフレーム

もちろん、すべての企業がすべてをクラウドに移行する必要があるわけではありません。

たとえば、メインフレームは多くの企業にとって重要な役割を果たし続けています。多くの業界の多くの企業がワークロードやデータストレージをクラウドに移行している一方で、すべてのワークロードやデータセットがクラウドに行く必要があるわけではありません。

今日、世界規模で数千の企業が、30年前または60年前にさかのぼる企業ソフトウェアを基にした重要なコアビジネスプロセスを持っています。ほとんどの企業は、重要なプロセスをメインフレーム上に保持し続けるでしょう。実際、1,000人以上のIT専門家とディレクターを対象にした2025メインフレーム調査報告は、以下のことを強調しています:

  • 回答者の90%がメインフレームを成長のための長期プラットフォームと見なしています
  • 超大規模ショップの67%がデータの50%以上をメインフレーム上に持っています

(メインフレームのモダナイゼーションについて読む。

ソフトウェアのモダナイゼーション戦略

ソフトウェアとアプリをモダナイズするかどうかを検討する際、3つのオプションから選ぶことができます:

  • 再作成。コーディングをより最近の開発言語に移行します。このオプションは、内在するコストと必要な時間枠の両方を過小評価する可能性が高く、しばしば終わりのない物語に変わります。
  • 置き換え。古いシステムを廃棄し、新しいものに置き換えます。このオプションは通常、既存のシステムの一部機能を模倣または反映する半分オフザシェルフのコンポーネントで新しいアプリケーションエコシステムを完全に構築する必要があるため、複雑さが増し、100%の機能を達成することが難しくなります。
  • 再利用。レガシーシステムをよりポータブルなものに変える方法を見つけ、リモートサイトやユーザーがアクセスできるようにします。該当する場合、このオプションでは変更をテストし、微調整する段階的アプローチが可能です。

モダナイゼーションプロジェクトの最適なルートを決定する前に、現在の状況と将来の目標について明確な理解を持つことが重要です。

ソフトウェアアプリケーションのモダナイゼーションへの道

ソフトウェアをモダナイズする利点

古いソフトウェアがビジネス運営を支えることは、リスクを増大させ、コストを増加させ、ビジネスの敏捷性を著しく低下させることを意味します。

それでは、アプリやソフトウェアをモダナイズすることを選択する多くの利点を見ていきましょう。

陳腐化の最小化

  • コントロールを失う。コアビジネスの一部が「古い学校」の<|vq_7801|>プログラミング言語で開発されたコードの一部に依存していることは、ビジネスにとって良くありません—今日、数十年も使用されているコードをサービスできる人が必要です。
  • サポートがない。クリティカルなビジネスプロセスが、もはや製造元によってサポートされていないハードウェアやオペレーティングシステム上で動作している場合、その製造元に頼ることができない場合、ビジネスマネージャーが望む立場ではありません。
  • 欠落しているコンポーネント。サポートインフラストラクチャがもはや存在しません。いくつかの古いソフトウェアは、バックアッププロセスとポリシーがバックアップハードウェアや特定のバックアップ製品またはソリューションに依存して開発されました。おそらく、そうしたバックアップ製品はすでに廃止されており、復元活動が不可能になる可能性があります。

コスト削減

  • より小さな問題を選択する。レガシーシステムがまだ存在する場合、それはおそらく企業のコアビジネスに重要な役割を果たしています。ほとんどの場合、置き換えには、投資の観点からも運用の観点からも重要なコストが伴います。(そのシステムがオフラインの場合に停止がもたらす損害を考慮してください。)それでも、何もしないことは短期的にはお金を節約できるかもしれませんが、今後の将来にわたって全く仕事ができなくなるリスクを増大させる可能性があります。特に、ハードウェアやオペレーティングシステムが製造元によってサポートされていない場合です。
  • OpEx vs CapEx。古いシステムが動作することは、バックアップテープ、ハードディスクドライブ、RAMメモリなどの廃止されたコンポーネントのストックに投資することを意味する可能性があります。また、ニッチな知識を活用する高コストの請負業者に依存する可能性もあります。

敏捷性の向上

  • 応答性。デジタルシステムにかかる負担が増すにつれて、顧客やビジネスクリティカルなプロセスを支えるために、いくつかのレガシーシステムがボトルネックを引き起こし、アプリケーションの応答性を遅らせる可能性があります。入力/出力の問題なのか、処理の問題なのかを検討することが重要です。
  • ビジネスサイクル。今日の市場で競争するには、予期しない需要に迅速に対応したり、新機能を迅速にリリースしたりする能力が必要です。一部のレガシーシステムや伝統的なシステムは、新しいコードを迅速かつ効率的に展開するために必要な柔軟性とスピードに対応できないかもしれません。

統合

  • ITは提供されるプラットフォーム(モバイルやソーシャルネットワーク)や、ITランドスケープコンポーネント—クラウド、ハイブリッド、オンプレミスデータセンターの複雑さにおいて成長してきています。アジャイルな「プラグイン」統合性は、ビジネス用語で競争上の優位性となり、レガシーシステムによってしばしば制約されています。

非整合性の最小化

  • 法律。場合によっては、法律や市場規制が既存のソフトウェアを移行する必要を示唆することがあります。GDPRや関連するプライバシー法は、必要なプライバシーを持つ新しいプラットフォームへの移行を強いる可能性があります。
  • 市場。競争は、ソフトウェアをモダナイズするもう一つの一般的な理由です。新興の競合他社は、通常、テクニカルデットや古いシステム、プロセスに縛られず、自然に敏捷性を持っています。競争が市場でより効果的なビジネスツールを持つことで前進する時が来たら、迅速に前進するか、消滅する時です。

モダナイゼーションのリスク

レガシーのモダナイゼーションは、数十年にわたるシステムを扱う際には簡単で論理的な決定に思えるかもしれませんが—モダナイズして生産性を向上させる。しかし、「壊れていないなら、修理しない方がいい。」ということわざは誰もが知っています。ガートナーの研究は、IBMメインフレームのようなレガシーシステムから移行することは、より多くのコストがかかり、品質へのリスクをもたらす可能性があると警告しています。

すべての企業プロセスに影響を与えるモダナイゼーション努力に飛び込む前に、慎重に進むことが重要です。ガートナーは、モダナイゼーションプロジェクトを検討している組織に対し、次のステップから始めることをお勧めします:

  • 認識や偏見ではなく、ビジネスニーズと能力に焦点を合わせる。「脆弱」や「レガシー」というフレーズ、またはガートナーが好む用語「伝統的」が、必要ない場合や有益でない場合にモダナイゼーションに偏った決定を下すかもしれません。
  • 既存のプラットフォームとプロセスを監査する。ビジネス要求とプラットフォームが提供するものとの間の不整合やギャップに焦点を合わせます。変更が必要であるという仮定ではなく、現在持っているもので始めます。
  • 所有コストを総合的に考慮する。移行のコストや複数年にわたる依存関係を含めます。ビジネスニーズと所有コストに焦点を合わせることで、組織はリスクを最小限に抑えながら、最もビジネス価値を推進するプロジェクトを正しく優先できるようになります。

このような移行のコストを考慮する際には、従来のシステムの現在のCapExと新しいシステムの期待されるOpExを超えて見る必要があります。ビジネスはまた、次のようなことを考慮する必要があります:

  • 変更注文のコスト
  • 移行中に複数のシステムを同時に運用するコスト
  • トレーニングコスト
  • 新しいセキュリティリスク

問題をビジネスの観点から見て、次のような問題に関連する質問をすることが重要です:

  • 競争能力
  • 現在の変更リクエストのバックログ
  • ビジネスワークフローの摩擦
  • 失敗が発生する場所

ガートナーが要約するように:

「目標は、従来のプラットフォームがビジネスを助けているのか、それとも目標を達成するのを妨げているのかを判断することです。」

ソフトウェアアプリのモダナイゼーション

アプリケーションモダナイゼーションのためのガートナーモデル

レガシーからモダンアプリケーションに移行する最初のステップは、ITモダナイゼーションイニシアチブのリスクとリターンの比率を特定、評価、緩和することです。レガシー技術には通常、2つの要素があります:

  • それらは重要な目的を果たすために使用されている
  • それらは通常、モダナイゼーションプロセスが急な障害に直面しているために存在する

この文脈において、調査会社ガートナーは、モダナイゼーションプロジェクトに伴うリスクを軽減しながらレガシーアプリケーションを評価するためのガイドラインを提示します。

レガシーソフトウェアのモダナイゼーション

成功したデジタルトランスフォーメーションプロジェクトは、ビジネスケースによって駆動されます。たとえば、レガシー技術は:

  • 組織がデジタルファーストのビジネスマーケットで競争することを妨げる
  • 現代の技術インフラストラクチャを使用することで簡単に緩和できる不当なセキュリティリスクを露呈する

新しい技術や運用モデルの中で機会とリスク回避を見つけることが重要です。したがって、モダナイゼーションを検討する際は、次の重要な推進要因を考慮してください:

  • ビジネスフィット。組織のビジョン、市場のニーズ、現在のIT環境で提供される競争力との整合性を考慮します。アプリケーションモダナイゼーションが目標にどのようにフィットするかを確認してください。
  • ビジネス価値。新技術に投資することで、短期的および長期的にどのような付加価値を提供していますか?
  • ビジネスの敏捷性。ソフトウェアの時代において、ビジネスの敏捷性は既存の技術を評価するための重要な推進要因であるべきです。ビジネスの敏捷性を受け入れることは挑戦的かもしれませんが、ますますビジネスにとって不可欠です。
  • コスト。デジタルトランスフォーメーションおよびアプリケーションモダナイゼーションイニシアチブのOpEx、CapEx、および総所有コスト(TCO)を考慮します。
  • 複雑さ。新しい技術への移行は、コストを増加させることになり得ます。
  • リスク。新しい技術投資に伴うリスクと機会を比較します。これらのリスクには、技術的な課題、コスト、文化的変化の問題、エンドユーザーの新技術への受け入れなどのソフト要因が含まれます。

ソフトウェアモダナイゼーションソリューションの評価

レガシー技術をモダナイゼーションやデジタルトランスフォーメーションの候補として特定したら、革新を最大化し、未来を見据えたプロセスに従うことが重要です。以下のステップを使用してください:

  1. カプセル化。レガシーアプリケーションの機能とデータをキャプチャし、カプセル化されたサービスを外部API接続として提供します。
  2. 再ホスティング。アプリケーションを現在のメインフレームデータセンターサーバーからクラウドインフラストラクチャに移行します。
  3. 再プラットフォーム化。ソフトウェアコードを新しいオペレーティングプラットフォームに移行します。これには、コードレベル(インターフェースと機能)とソフトウェアアーキテクチャでの変更が必要です。
  4. リファクタリング。既存のコードを最適化して、新しいプラットフォームとクラウドインフラストラクチャでの機能を向上させます。
  5. 再アーキテクチャ。新機能や機能を導入するためにソフトウェアアーキテクチャを徹底的に変更します。
  6. 再構築。プロジェクトをゼロから再スタートし、機能や特長を再現します。
  7. 置き換え。レガシー技術を排除し、代替ソリューションに投資します。

BMCの製品ラインを探索し、モダナイゼーションの旅をサポートしてください

ガートナーのTIMEフレームワーク

さあ、さまざまな候補のレガシー技術に関する情報を特定し収集したら、優先順位を付ける時です。

ガートナーは、組織が明確な変更戦略を策定し、より大きな組織の視点からオプションを観察するのに役立つ「Tolerate-Invest-Migrate-Eliminate(TIME)フレームワーク」を提供しています:

  • 許容する。再エンジニアリングします。
  • 投資する。革新し、進化します。
  • 移行する。モダナイズします。
  • 排除する。置き換え、統合します。
アプリケーション時間分析

このシンプルな2x2マトリックスを使用することで、組織は既存の技術と新しい技術がビジネスフィット、機能、アーキテクチャ、採用の面でどのように機能するかを評価できます。

  • ビジネス価値は、ビジネス目標を達成するための技術の重要性を示します。
  • 品質は、技術の技術的な整合性を指し、高品質はレガシー技術の変更の容易さを示します。

ソフトウェアのモダナイゼーションの一般的なアプローチ

もちろん、モダナイゼーションに関して取ることができる他のアプローチもあります。実際、いくつかのアプローチや方法論が開発されています:

  • アーキテクチャ駆動のモダナイゼーション(ADM)は、モダナイゼーションの複雑さを軽減するためにサポートインフラストラクチャを利用します。仮想化はその一例です。
  • SABAフレームワークは、組織的および技術的な影響を考慮して計画を立てることを含みます。これは、企業にとって深刻な頭痛を最小限に抑えるためのベストプラクティスです。
  • リバースエンジニアリングモデルは、高コストで非常に長いプロジェクトを表し、技術の進歩によって損なわれる可能性があります。
  • Visaggioの意思決定モデル(VDM)は、ケースごとに技術的および経済的な視点を組み合わせて、適切なソフトウェア更新プロセスに到達することを目的とした意思決定モデルです。
  • ソフトウェアの書き換えおよび置き換え時間に関する経済モデル(SRRT)。上記のVDMモデルと類似しています。
  • DevOpsの貢献。DevOpsの焦点は、新しいソフトウェアリリースを迅速に展開し、目標の運用IT環境に完全に準拠する際のバグやエラーの発生を最小限に抑えることです。これ自体がレガシーモダナイゼーションプロセスを加速させる主要な要因となります。

アプリ/ソフトウェアのモダナイゼーションに関するベストプラクティス

処方されたアプローチに従うかDIYを行うかにかかわらず、これらのベストプラクティスはすべてのモダナイゼーション努力において真実です。

  • すべてのITシステムと固有のソフトウェアアプリケーションを特定し、マッピングし、企業のランドスケープ内での役割、相互作用(アプリ間および人間のユーザーへの)、サポートプラットフォーム、リソース、および現在の基準内での老朽化状態を考慮してください。
  • ITのニーズだけでなく、ビジネスのニーズを考慮する。ビジネスとITの両方を見る必要があります。企業がITを「迷惑なもの」と考える場合、経営陣の明確な支持を得るのが難しくなります—これは、あらゆる大規模なモダナイゼーション努力に必要です。
  • 二重の視点で進める。一方では、既存のITシステムやソフトウェアアプリケーションの年齢と技術的な状態を現在の基準と比較します。もう一方では、これらをビジネスのロードマップと整合させます。
  • プロセス知識をクロスチェックする。しばしば、主要ユーザーはプロセスがどのように機能するかを知っており、プロセスに関与するさまざまなステップを理解している可能性があります。しかし、彼らが知らないかもしれないことを思い出してください:システムの背後にあるロジック、またはそれが他のビジネスプロセスにどのように影響するか、または影響しないか。

重要なポイントは、ソフトウェアやアプリケーションのモダナイゼーションは、今日のほとんどのビジネスにとって必要な活動であるということです。これは、すべてのビジネスプロセスやツールが新しいクラウドファーストのオプションに置き換えられることを意味するものではありません。むしろ、この集中的な努力から最も利益を得る実践を選択することを意味します。

関連する読み物

これらの投稿は私自身の意見であり、BMCの立場、戦略、または意見を必ずしも反映するものではありません。

ITOps・DevOpsの関連記事

The Briefを購読する

このオファーに登録することで、あなたはBMCのプライバシーポリシーを読み、同意したことを確認します。

ありがとう

あなたはThe Briefに登録されました
The Briefはメインフレームとエンタープライズオーケストレーション—BMC AMIとControl-M—および、両者に関するアナリストの研究、顧客の展開、イベントをカバーしています。