アプリケーションポートフォリオ管理

ITアプリケーションポートフォリオ管理（APM ）は、1990年代半ば以降、中規模から大規模の情報技術（IT）組織で登場した手法です。 ^{[1]アプリケーションポートフォリオ管理では、}財務ポートフォリオ管理 の教訓を活用して、アプリケーションの保守と運用のコストと比較して、各アプリケーションの財務上の利点を正当化し、測定しようとします。

アプリケーションポートフォリオに関する最も古い言及は、おそらく1974年のCyrus GibsonとRichard NolanによるHBRの記事「EDP成長の4つの段階の管理」です。^[2]

Gibson 氏と Nolan 氏は、企業の IT に対する理解と IT の有効活用は予測可能な段階で「成長」し、各段階における企業の進捗状況は、全体的な IT 支出の分析の文脈内でアプリケーション ポートフォリオ、ユーザー認識、IT 管理プラクティス、および IT リソースを観察することによって測定できると仮定しました。

Nolan, Norton & Co. は、DuPont、Deere、Union Carbide、IBM、Merrill Lynch などの企業での研究を通じて、これらの概念を実際に使用する先駆者となりました。これらの「ステージ評価」では、各アプリケーションが各ビジネス機能またはプロセスをサポートまたは「カバー」する度合い、アプリケーションへの支出、機能品質、および技術品質を測定しました。これらの測定により、ビジネスへの IT の適用、長所と短所、および改善へのロードマップの包括的なビューが得られました。

APM は、2000 年を迎えた際にアプリケーション障害が発生するという脅威 (この脅威は 2000 年問題または Y2K として知られるようになりました) に組織が対処し始めた 1980 年代後半から 1990 年代にかけて広く採用されました。^[3] この間、世界中の何万もの IT 組織が、各アプリケーションに関する情報を含む包括的なアプリケーション リストを作成しました。

多くの組織では、このリストを作成する価値は、Y2Kリスクへの対応コストを懸念するビジネス リーダーによって疑問視されました。一部の組織では、ポートフォリオ管理の概念が、アプリケーション障害のリスク管理を超えた作業を実行する利点として、情報技術予算を担当するビジネス パーソンに提示されました。

アプリケーション ポートフォリオ管理ソリューションには、一般に「トップ ダウン」アプローチと「ボトム アップ」アプローチと呼ばれる 2 つの主なカテゴリがあります。^[4]組織で最初に必要なのは、どのようなアプリケーションが存在するか、およびその主な特性 (柔軟性、保守性、所有者など) を理解することです。これは通常、「インベントリ」と呼ばれます。APM のもう 1 つのアプローチは、アプリケーションのソース コードとその関連コンポーネントを解析してリポジトリ データベースに格納することにより、ポートフォリオ内のアプリケーションを詳細に理解することです (つまり、「ボトム アップ」)。現在 APM ツールとして販売されているアプリケーション マイニング ツールは、このアプローチをサポートしています。

「トップダウン」アプローチをサポートするツールは数百種類あります。これは驚くことではありません。タスクの大部分は適切な情報を収集することであり、情報の実際の保守と保存は比較的簡単に実装できるからです。そのため、多くの組織は市販のツールを使用せず、Microsoft Excel を使用して在庫データを保存しています。ただし、在庫が複雑になると、Excel の保守が面倒になります。Excel ベースのソリューションでは、データの自動更新が十分にサポートされていません。最後に、このような在庫ソリューションは、「ボトムアップ」の理解ニーズとはまったく異なります。

Forrester Researchによると、「企業はIT運用予算のうち、3分の2以上を継続的な運用と保守に費やしている。」^[5]

組織には、同じ機能を実行する複数のシステムが存在するのが一般的です。このような重複には、部門別コンピューティングの以前の隆盛、1970 年代と 1980 年代のアプリケーション サイロ、企業の合併と買収の急増、新しいツールを導入する試みの失敗など、さまざまな理由が考えられます。重複の有無にかかわらず、各アプリケーションは個別に保守され、定期的にアップグレードされるため、冗長性によって複雑さとコストが増加します。

既存のITアプリケーションの管理に大部分の費用が費やされているため、現在のアプリケーションインベントリとリソース消費の透明性は、アプリケーションポートフォリオ管理の主な目標です。^{[6] [7]}これにより、企業は次のことが可能になります。1) 部分的にまたは完全に冗長なアプリケーションを特定して削除する、2) 安定性、品質、保守性の観点からアプリケーションの状態を定量化する、3) アプリケーションのビジネス価値/影響と各アプリケーションのビジネスに対する相対的な重要性を定量化する、4) ビジネスの優先順位の観点からアプリケーションの状態と重要性に応じてリソースを割り当てる。

透明性は、戦略的計画の取り組みにも役立ち、ビジネスと IT の対立を緩和します。ビジネス リーダーが、アプリケーションが主要なビジネス機能をどのようにサポートしているか、および停止や品質の低下の影響を理解すると、過剰なコストについて IT を非難する会話はなくなり、貴重なリソースを企業の優先事項をサポートするために最も効果的に使う方法へと向かいます。

APM実践者は、投資ポートフォリオ管理のアイデアを取り入れて、企業や組織で使用されている各アプリケーションに関する情報を収集します。これには、アプリケーションの構築と保守にかかるコスト、生み出されるビジネス価値、アプリケーションの品質、予想される寿命などが含まれます。^[8] この情報を使用して、ポートフォリオマネージャーは、所有コストと提供されるビジネス価値に関連して、ITインフラストラクチャのパフォーマンスに関する詳細なレポートを提供できます。

アプリケーションポートフォリオ管理において、アプリケーションの定義は重要な要素です。多くのサービスプロバイダーは、これらの定義から生じる結果がしばしば論争を呼ぶため、組織が独自の定義を作成するのを支援しています。^[9]

• アプリケーション ソフトウェア— 実行可能なソフトウェア コンポーネント、または密接に結合された実行可能なソフトウェア コンポーネントのセット (1 つ以上) で、一緒に展開され、特定のビジネス目的の情報の作成、更新、管理、計算、または表示に必要な一連の手順の一部またはすべてを実行します。カウントされるためには、各コンポーネントが別のアプリケーションのメンバーであってはなりません。
• ソフトウェア コンポーネント— 単一の展開コンテナーに含まれ、それ以上分割できない実行可能なコンピューター命令セット。例としては、ダイナミック リンク ライブラリ、 ASP Web ページ、コマンド ライン " EXE " アプリケーションなどがあります。ZIPファイルには、ソフトウェア コンポーネントをさらに分割することが簡単なため (ZIP アーカイブを解凍することによって)、複数のソフトウェア コンポーネントが含まれることがあります。

ソフトウェア アプリケーションとソフトウェア コンポーネントは、IT ポートフォリオ管理の目的でアプリケーション ソフトウェアのクラスの特定のインスタンスを説明するために使用される技術用語です。IT管理またはエンタープライズ アーキテクチャを実践していない人向けの定義については、 アプリケーション ソフトウェアを参照してください。

ソフトウェア アプリケーション ポートフォリオ管理では、組織にインストールされているアプリケーションのカタログを作成するために、アプリケーションをかなり詳細かつ具体的に定義する必要があります。

アプリケーション ポートフォリオ管理のコンテキストでは、アプリケーションの定義に次の要件があります。

• ビジネス チームのメンバーにとって、説明、理解、適用が簡単である必要があります。
• IT グループの開発、運用、プロジェクト管理にとって意味のあるものでなければなりません。
• これは、ポートフォリオ全体のコストを出力する複雑な関数への入力として役立つ必要があります。言い換えると、IT ポートフォリオ全体のコストにつながる要因は多数あります。アプリケーションの数もその要因の 1 つです。したがって、アプリケーションの定義は、その計算に役立つ必要があります。
• これは、ポートフォリオの最適化と簡素化の目標に関してプロジェクトを評価しようとしているエンタープライズ アーキテクチャ チームのメンバーにとって役立つはずです。
• アプリケーションの境界を明確に定義する必要があります。そうしないと、測定可能な「ポートフォリオの簡素化」アクティビティに取り組んでいる人が、既存の 2 つのアプリケーションの境界を単純に再定義して、それらを 1 つのアプリケーションと呼ぶことができなくなります。

多くの組織では、 IT ポートフォリオ管理とガバナンスの実践の文脈内でアプリケーションの定義を再検討することになります。そのため、この定義は作業の開始点として考慮する必要があります。

アプリケーションの定義を明確に伝えるのは難しい場合があります。IT 組織では、チーム間、さらには 1 つの IT チーム内でも定義に微妙な違いがある場合があります。例を挙げて定義を説明すると役立ちます。以下のセクションでは、アプリケーションであるもの、アプリケーションではないもの、および 2 つ以上のアプリケーションを構成するものの例をいくつか示します。

この定義によれば、アプリケーションは次のようになります。

• 3 つの Web サービス (InvoiceCreate、InvoiceSearch、InvoiceDetailGet) を提供するWebサービスエンドポイント
• 請求書を作成するためのユーザー インターフェイスを提供し、InvoiceCreateサービスを呼び出すサービス指向ビジネス アプリケーション (SOBA)。(サービス自体は別のアプリケーションであることに注意してください)。
• エンタープライズアプリケーション ストアに公開され、従業員が所有または操作するポータブル デバイスに展開され、データやサービスへの認証されたアクセスを可能にするモバイル アプリケーション。
• リッチ クライアント、サーバー ベースの中間層、およびデータベースで構成され、すべてが密接に結合されたレガシー システムです(たとえば、1 つの変更によって別の変更がトリガーされる可能性が非常に高くなります)。
• データベースからデータを取得し、それをパブリック URL 上のサブサイトとしてHTML形式で公開する Web サイト公開システム。
• レイアウトや計算のために情報を照会するMicrosoft Excelブックにデータを提供するデータベース。これは、データベースが既に別のアプリケーション (レガシー システムなど) に含まれていない限り、データベース自体がアプリケーションであるという点で興味深いものです。
• ビジネス価値をもたらす、一貫性のある再利用可能なマクロのセットを含むExcelスプレッドシート。スプレッドシート自体は、アプリケーションの展開コンテナー ( TARファイルやCABファイルなど) を構成します。
• 相互に連携して動作し、Web アプリケーションのエクスペリエンスとロジックを提供するASPまたはPHP Web ページのセット。結合が緩い場合、サブサイトがこの定義では個別のアプリケーションとして分類される可能性は十分にあります。
• マシン間の通信 (人間とのやり取りではない) のために確立された Web サービス エンドポイントですが、ビジネス プロセスにおける 1 つ以上の有用なステップを表すものとして合理的に理解できます。

以下はアプリケーションではありません:

• HTML ウェブサイト。
• データを含んでいるが、そのデータを使用してビジネス価値を提供する一連の手順の一部ではないデータベース。
• 構造的に、価値を提供する一連のステップの一部となることができない Web サービス。たとえば、共有スキーマを破る受信データを必要とする Web サービスなどです。
• 2 つのデータベースをそれぞれ呼び出してその内容を比較し、データの異常が検出された場合に監視エイリアスに電子メールを送信するスタンドアロン バッチ スクリプト。この場合、バッチ スクリプトは 2 つのデータベースの少なくとも 1 つと密接に結合されている可能性が非常に高いため、最も密接に結合されているデータベースを含むアプリケーション境界に含める必要があります。

次のような多くの用途があります。

• 再利用可能なサービスのセットと、それらのサービスを活用するユーザー インターフェイスから構成される複合SOAアプリケーション。ここには少なくとも 2 つのアプリケーション (ユーザー インターフェイスと 1 つ以上のサービス コンポーネント) があります。各サービスはアプリケーションとしてカウントされません。
• データベースに書き込んでデータを保存するレガシ クライアント サーバー アプリと、マクロを使用してデータベースからデータを読み取ってレポートを表示する Excel スプレッドシート。この例には 2 つのアプリがあります。データベースは、レガシ アプリとともに開発され、レガシ アプリとともに提供され、レガシ アプリと密接に結合されているため、明らかにレガシ アプリに属しています。これは、レガシ システムで Excel スプレッドシートと同じストアド プロシージャが使用されている場合でも当てはまります。

アプリケーションや情報システムを評価するために使用される、一般的な財務指標は数多くあり、さらにさまざまなタイプ (非財務的または複雑なタイプ) の指標も数多くあります。

投資収益率は、ビジネス分析で使用される最も一般的なパフォーマンス測定および評価指標の 1 つです。ROI 分析 (正しく適用された場合) は、既存の情報システムを評価し、ソフトウェアの取得やその他のプロジェクトについて情報に基づいた決定を下すための強力なツールです。ただし、ROI は、収益性または財務効率を評価するという特定の目的のために設計された指標です。情報ソリューションの全体的な経済状況を示す他の多くの財務指標の代わりに、ROI を信頼できる方法で使用することはできません。情報システムに関する意思決定の唯一の指標または主要な指標として ROI を使用する試みは、生産的ではありません。非常に限られた数のケース/プロジェクトでのみ適切である可能性があります。ROI は財務指標であり、情報システムの効率性や有効性に関する情報は提供しません。^[10]

営業利益（現金ベースで税金調整済み）から資本コストを差し引いて計算した残余財産に基づく、企業の財務実績の尺度。（「経済的利益」とも呼ばれます。）

計算式 = 税引後営業利益 (NOPAT) - (資本 * 資本コスト)

総所有コストは、定義された期間にアプリケーションにかかるコストを計算する方法です。TCO モデルでは、ハードウェア、ソフトウェア、および人件費のコストが捕捉され、さまざまなアプリケーション ライフ サイクル ステージにまとめられます。詳細な TCO モデルは、構築、実行/サポート、および間接コストの測定を試みることで、管理者がアプリケーションの実際のコストを把握するのに役立ちます。多くの大手コンサルティング会社は、完全な TCO モデルを構築するための戦略を定義しています。

TEI は、Forrester Research Inc. によって開発されました。Forrester は、TEI が、コスト (IT への影響)、メリット (ビジネスへの影響)、柔軟性 (投資によって生み出される将来の選択肢)、リスク (不確実性) という 4 つの側面から、技術投資の潜在的な影響を体系的に検討していると主張しています。

ITBVプログラムは、2002年にインテル社によって開発されました。^[11] このプログラムは、ビジネスバリューダイヤル（指標）と呼ばれるビジネス価値の財務測定セットを使用します。これは、ビジネスコンポーネントを含む多次元プログラムであり、実装が比較的簡単です。

AIE は、Hubbard Decision Research によって開発された意思決定分析方法です。AIE は、モンテ カルロ法の使用を含む意思決定理論とリスク分析のいくつかの方法に基づいて構築された「真に科学的で理論的に健全な最初の方法」であると主張しています。AIE は複雑なため、あまり使用されていません。