アーキテクチャ原則は、組織がその使命の達成に向けて取り組む方法を知らせ、サポートする一般的なルールとガイドラインです。これらは企業のさまざまな要素間の合意レベルを反映し、将来の IT に関する意思決定の基礎となります。アーキテクチャ原則の目的の 1 つは、企業のアーキテクチャに影響を与える変更を評価および合意するためのフレームワークを提供することにより、戦略目標を追求するためにビジネスを管理する方法についての共通理解を確立することです3。 参考資料: 3: TOGAF 標準バージョン9.2、パート III: ADM ガイドラインとテクニック、第 23 章: アーキテクチャ原則: TOGAF 標準、バージョン 9.2、パート IV: アーキテクチャ コンテンツ フレームワーク、第 31 章: アーキテクチャ原則

アーキテクチャをスコープするために使用される 4 つの側面は、幅、深さ、期間、およびアーキテクチャ ドメインです1、p.11 8.
範囲とは、アーキテクチャがカバーする企業の範囲を指し、特定の事業単位から組織全体にまで及びます1、p. 8.
深さとは、アーキテクチャの詳細と完全性のレベルを指し、アーキテクチャの目的、範囲、関係者によって異なります1、p. 8.
期間とは、現在の状態、目標の状態、移行計画など、アーキテクチャの一時的な側面を指します1、p。8.
アーキテクチャ ドメインとは、アーキテクチャをビジネス、データ、アプリケーション、テクノロジの 4 つのドメインに分類することを指します1 (p. 2)。8.
これら 4 つの側面は、アーキテクチャの範囲と境界を定義し、関係者のニーズと期待を確実に満たすのに役立ちます。
参考文献:
1: オープン グループ (2018)。TOGAF® 規格、バージョン 9.2。1

説明
次の活動はリスク管理の一部です。
初期リスク評価
リスクの軽減と残留リスクの評価
リスクモニタリング
リスク管理は、企業の目標の達成に影響を与える可能性のあるリスクを特定、評価し、対応するプロセスです。リスク管理には、機会または脅威の実現から生じるプラスの結果とマイナスの結果のバランスをとることが含まれます。参考: TOGAF 規格 | Open Group Web サイト、セクション 3.3.3 リスク管理。

ビルディング ブロックは、アーキテクチャやソリューションを提供するために組み合わせることができる、ビジネス、IT、またはアーキテクチャ機能の再利用可能なコンポーネントです。ビルディング ブロックは、アーキテクチャ開発の段階に応じて、さまざまな詳細レベルで定義できます。ADM サイクルの初期段階 (A ～ D) では、アーキテクチャの概要を提供するために、ビルディング ブロックが論理的または物理的などの一般的な用語で定義されます。フェーズ E: 機会とソリューションでは、ビルディング ブロックが実装固有になります。これは、ビルディング ブロックが市場で入手可能な特定の製品、標準、テクノロジー、ベンダーにリンクされていることを意味します。このフェーズでは、構築ブロックを実現するプロジェクト、プログラム、ポートフォリオなどの提供手段も特定します12 参考資料: 1: TOGAF 標準、バージョン 9.2、パート II: アーキテクチャ開発手法 (ADM)、第 23 章: フェーズ E:機会と解決策 2: TOGAF 規格、バージョン 9.2、パート IV: アーキテクチャ コンテンツ フレームワーク、第 36 章: ビルディング ブロック

説明
質問にリストされている目標は、エンタープライズ アーキテクチャを開発および管理するための手法である TOGAF ADM (アーキテクチャ開発メソッド) のさまざまなフェーズの目標に対応しています1。
ADM は 9 つのフェーズで構成され、それぞれに特定の目的と出力があります。フェーズは次のとおりです:
準備フェーズ: アーキテクチャのフレームワーク、原則、ガバナンスの定義など、アーキテクチャ開発サイクルを準備して開始します。
フェーズ A: アーキテクチャ ビジョン: アーキテクチャ イニシアチブの範囲、ビジョン、関係者を定義し、続行するための承認を取得します。
フェーズ B: ビジネス アーキテクチャ: ベースラインとターゲットのビジネス アーキテクチャを説明し、それらの間のギャップを特定します。
フェーズ C: 情報システム アーキテクチャ: ベースラインとターゲットのデータとアプリケーション アーキテクチャを説明し、それらの間のギャップを特定します。
フェーズ D: テクノロジー アーキテクチャ: ベースラインとターゲットのテクノロジー アーキテクチャを説明し、それらの間のギャップを特定します。
フェーズ E: 機会と解決策: ターゲット アーキテクチャを実装するための機会と解決策を特定して評価し、作業パッケージと移行アーキテクチャを定義します。
フェーズ F: 移行計画: 導入および移行計画を最終決定し、企業のポートフォリオおよびプロジェクト管理との整合性を確保します。
フェーズ G: 実装ガバナンス: 実装プロジェクトに対してアーキテクチャの監視とガイダンスを提供し、アーキテクチャの変更要求を管理します。
フェーズ H: アーキテクチャ変更管理: ビジネスおよびテクノロジー環境の変化を監視し、アーキテクチャの影響とパフォーマンスを評価します。
上記の定義に基づいて、次のように各目標を対応するフェーズと対応付けることができます。
目標 1: ビジネス アーキテクチャとアーキテクチャ ビジョンを実現するターゲット データ アーキテクチャを開発します。この目的は、フェーズ C: 情報システム アーキテクチャで達成されます。このフェーズでは、データ アーキテクチャが情報システム アーキテクチャのサブセットとして定義されます2。
目標 2: ビジネス目標を達成するために企業がどのように運営する必要があるかを説明するターゲット ビジネス アーキテクチャを開発します。この目的は、フェーズ B: ビジネス アーキテクチャで達成されます。このフェーズでは、ビジネス アーキテクチャはエンタープライズ アーキテクチャのサブセットとして定義されます3。
目標 3: 提案されたエンタープライズ アーキテクチャの結果として提供される機能とビジネス価値についての高レベルの野心的なビジョンを策定します。この目標は、フェーズ A: アーキテクチャ ビジョンで達成されます。ここで、アーキテクチャ ビジョンは、ターゲット アーキテクチャとその利点の高レベルの説明として定義されます4。
目標 4: アーキテクチャ作業記述書と関係者の懸念に対処する方法で、ビジネス アーキテクチャとアーキテクチャ ビジョンを実現するターゲット アプリケーション アーキテクチャを開発します。この目的は、フェーズ C: 情報システム アーキテクチャで達成されます。このフェーズでは、アプリケーション アーキテクチャが情報システム アーキテクチャのサブセットとして定義されます2。
参考文献:
1: TOGAF 標準バージョン 9.2、第 5 章: アーキテクチャ開発手法 (ADM)
2: TOGAF 標準、バージョン 9.2、第 9 章: フェーズ C: 情報システム アーキテクチャ
3: TOGAF 規格、バージョン 9.2、第 8 章: フェーズ B: ビジネス アーキテクチャ
4: TOGAF 規格、バージョン 9.2、第 7 章: フェーズ A: アーキテクチャ ビジョン