エンタープライズ コンティニュアムは、アーキテクチャ コンティニュアムとソリューション コンティニュアムという 2 つの補完的な概念で構成されています1。アーキテクチャ コンティニュアムは、特定の状況に適用および調整できるモデル、パターン、標準などの汎用的で再利用可能なアーキテクチャ ビルディング ブロックを記述および理解するための一貫した方法を提供します2。ソリューション コンティニュアムは、アーキテクチャ ビルディング ブロックを実現する製品、サービス、コンポーネントなどの特定の実装済みソリューション ビルディング ブロックを記述および理解するための一貫した方法を提供します3。エンタープライズ コンティニュアムにより、基盤アーキテクチャから組織固有のアーキテクチャに至るまで、さまざまなレベルの抽象化、範囲、詳細にわたって、アーキテクチャとソリューション アセットの再利用と統合が可能になります1。
エンタープライズ コンティニュアムは、次のアクティビティをサポートするエンタープライズ アーキテクチャを開発するときに使用されます1。
*ビジネスドライバー、目標、要件に基づいて、アーキテクチャリポジトリまたはその他のソースから関連するアーキテクチャとソリューションアセットを選択します。
*企業の特定のニーズと状況に合わせてアーキテクチャとソリューション資産を適応およびカスタマイズする
*ベースラインとターゲット状態の間に特定されたギャップと機会に基づいて、ターゲットアーキテクチャとアーキテクチャロードマップを定義および開発する
*アーキテクチャロードマップとソリューションビルディングブロックに基づいて、実装と移行計画を定義および開発します。
*アーキテクチャライフサイクル全体にわたってアーキテクチャとソリューション資産を統制および管理し、その品質、一貫性、コンプライアンスを確保する参考文献: 1: TOGAF標準、バージョン9.2 - Enterprise Continuum 2: TOGAF標準、バージョン
9.2 - アーキテクチャ コンティニュアム 3: TOGAF 標準、バージョン 9.2 - ソリューション コンティニュアム

1F: ベースラインからターゲットアーキテクチャへの秩序ある移行を実現する実装および移行戦略を定義する 2G: ソリューションの実装中に適切なガバナンス機能を実行する 3G: 実装プロジェクトによるターゲットアーキテクチャへの準拠を確保する 4H: 運用中のソリューションのパフォーマンスを継続的に監視および評価するための手順を確立する

統合ギャップ、ソリューション、依存関係マトリックスは、アーキテクチャの段階的な展開のための作業パッケージを作成するために使用できる手法です。作業パッケージとは、アーキテクチャの特定の部分を実装するために必要な一連のアクションまたはタスクです。作業パッケージは、ビジネス、IT、またはアーキテクチャ機能の再利用可能なコンポーネントである 1 つ以上のアーキテクチャ ビルディング ブロック (ABB) またはソリューション ビルディング ブロック (SBB) に関連付けることができます。また、作業パッケージは、ビジネス価値をもたらす全体的な機能の定義済み個別部分である 1 つ以上の機能増分に関連付けることもできます。機能増分は、ベースライン アーキテクチャからターゲット アーキテクチャへの移行を可能にするアーキテクチャの中間状態である 1 つ以上の移行アーキテクチャによって実現できます。123 この手法を使用して作業パッケージを作成する手順は次のとおりです。
ベースライン アーキテクチャとターゲット アーキテクチャ間のギャップごとに、提案されたソリューションを特定し、新規開発、購入したソリューション、または既存の製品に基づくものとして分類します。ギャップとは、アーキテクチャの現在の状態における相違点または欠陥であり、アーキテクチャの将来の状態で対処する必要があります。ソリューションとは、1 つ以上の ABB または SBB を実装してギャップを解決する方法です。
類似のソリューションをグループ化して、作業パッケージを定義します。類似のソリューションとは、機能、テクノロジー、ベンダー、場所などの共通の特性を持つソリューションのことです。
論理的依存関係、時間的依存関係、リソース依存関係など、作業パッケージ間の依存関係を識別します。
依存関係は、作業パッケージの順序や優先順位、およびその実装に影響を与える可能性のある制約やリスクを示します。
作業パッケージを機能増分のセットに再グループ化して、ターゲット アーキテクチャに移行します。
能力増分は、各作業パッケージに関連するビジネス価値、労力、リスク、および臨床試験のスケジュールと目的に基づいて定義する必要があります。能力増分は、アーキテクチャ ビジョンとアーキテクチャ プリンシプルと整合させる必要もあります。
作業パッケージと機能増分をアーキテクチャ定義増分テーブルに文書化します。このテーブルには、作業パッケージ、ABB、SBB、および機能増分間のマッピングが表示されます。また、このテーブルには、各作業パッケージと機能増分に関連する依存関係、前提、および問題も表示されます。
したがって、最適な答えは B です。これは、統合ギャップ、ソリューション、依存関係マトリックスを計画ツールとして使用して、要件を満たす段階的なロールアウトの作業パッケージを特定するアプローチを説明しているからです。
参考文献: 1: TOGAF 標準、バージョン 9.2、パート III: ADM ガイドラインとテクニック、第 30 章:
ギャップ分析 2: TOGAF 標準、バージョン 9.2、パート IV: アーキテクチャ コンテンツ フレームワーク、第 36 章:
ビルディング ブロック 3: TOGAF 標準、バージョン 9.2、パート III: ADM ガイドラインとテクニック、第 31 章:
アーキテクチャ変更管理 : TOGAF 標準、バージョン 9.2、パート II: アーキテクチャ開発手法 (ADM)、第 23 章: フェーズ E: 機会とソリューション : TOGAF 標準、バージョン 9.2、パート II: アーキテクチャ開発手法 (ADM)、第 21 章: フェーズ F: 移行計画 : TOGAF 標準、バージョン 9.2、パート II: アーキテクチャ開発手法 (ADM)、第 18 章: フェーズ A: アーキテクチャのビジョン : TOGAF 標準、バージョン 9.2、パート III: ADM ガイドラインとテクニック、第 23 章:
アーキテクチャの原則

* アーキテクチャ ボードは、戦略アーキテクチャとそのすべてのサブアーキテクチャのレビューと保守を担当するエグゼクティブ レベルのグループです1。アーキテクチャ ガバナンス戦略を成功させる上で重要な要素です2。
* アーキテクチャ ボードは通常、次の目標の一部またはすべてを達成する責任と説明責任を負います2。
* アーキテクチャに関するあらゆる意思決定の基礎を提供する
* サブアーキテクチャ間の一貫性
* 部品の再利用目標の設定
* エンタープライズアーキテクチャの柔軟性: 変化するビジネスニーズに対応し、新しいテクノロジーを活用する
* アーキテクチャコンプライアンスの実施
* 組織内のアーキテクチャ分野の成熟度の向上
* アーキテクチャベースの開発の規律が採用されていることを保証する
* 範囲外の決定に対する目に見えるエスカレーション機能のサポート
* したがって、正解はオプション D であり、これは TOGAF 標準バージョン 9.22 に記載されているアーキテクチャ ボードの目標の 1 つを捉えています。
* オプション A は不正解です。組織内のアーキテクチャ分野の成熟度レベルの評価を実施することは、アーキテクチャ ボードの直接の責任ではなく、アーキテクチャ能力フレームワーク 3 の一部です。
* オプション B は不正解です。アーキテクチャ プロジェクトへのリソースの割り当ては、アーキテクチャ ボードの直接の責任ではなく、アーキテクチャ ガバナンス フレームワーク4 の一部です。
* オプション C は不正解です。アーキテクチャ作業ステートメントの作成はアーキテクチャ ボードの直接の責任ではなく、アーキテクチャ開発方法 5 の一部です。参考文献:
* 1: アーキテクチャ委員会 - The Open Group3
* 2: TOGAF 標準、バージョン 9.2 - パート VI: アーキテクチャ ガバナンス フレームワーク - アーキテクチャ ボード
* 3: TOGAF 標準、バージョン 9.2 - パート VI: アーキテクチャ ガバナンス フレームワーク - アーキテクチャ機能フレームワーク
* 4: TOGAF 標準、バージョン 9.2 - パート VI: アーキテクチャ ガバナンス フレームワーク - アーキテクチャ ガバナンス フレームワーク
* 5: TOGAF 標準、バージョン 9.2 - パート II: アーキテクチャ開発方法 - フェーズ A: アーキテクチャビジョン

この図は、TOGAF フレームワークの主要概念であるエンタープライズ コンティニュアム、アーキテクチャ コンティニュアム、ソリューション コンティニュアムの関係を示しています。エンタープライズ コンティニュアムは、アーキテクチャ リポジトリのビューであり、一般的な基盤アーキテクチャを活用して、個々の組織の要件をサポートするために特化する方法を示しています。アーキテクチャ コンティニュアムは、モデル、パターン、説明などのアーキテクチャ成果物の構造化された分類を指定します。これらの成果物は、さまざまなドメインや抽象化レベルにわたって再利用および適応できます。ソリューション コンティニュアムは、共通システム、業界ソリューション、組織固有のソリューションなど、ビジネスおよび IT 機能の進化のさまざまな段階をサポートする実装済みソリューションを識別します。また、この図は、アーキテクチャ コンテキストと要件が、ビジネス ドライバー、利害関係者、標準などの外部要因によってどのように影響を受け、それらが一般的なアーキテクチャとソリューションおよび特定のアーキテクチャとソリューションをどのように形作るかを示しています。また、この図は、展開されたソリューションが、アーキテクチャ開発サイクルの将来の反復でアーキテクチャ コンテキストの一部になる方法を示しています。参考:
* TOGAF 標準、第 10 版、パート II: アーキテクチャ開発方法、第 6 章: アーキテクチャ リポジトリ、セクション 6.2 エンタープライズ コンティニュアム。
* TOGAF 標準、第 10 版、パート IV: アーキテクチャ コンテンツ フレームワーク、第 35 章: エンタープライズ コンティニュアムとツール、セクション 35.1 概要。