説明
内部および外部の標準と規制義務への準拠を保証することは、アーキテクチャ ガバナンスに含まれるアクティビティの 1 つです。アーキテクチャ ガバナンスは、エンタープライズ アーキテクチャおよびその他のアーキテクチャをエンタープライズ全体のレベルで管理および制御するための実践と方向性です。アーキテクチャがエンタープライズの戦略と目標と一致し、品質とパフォーマンスの要件を満たすように、プロセス、役割、責任、ポリシー、および標準を確立することが含まれます。
参考: TOGAF 標準 | The Open Group Web サイト、セクション 3.3.6 アーキテクチャ ガバナンス。

Web 検索結果によると、アーキテクチャ パーティショニングとは、主題、時間、成熟度、変動性などのさまざまな分類基準に基づいて、エンタープライズ アーキテクチャをより小さく管理しやすいセグメントまたはグループに分割する手法です。12 アーキテクチャ パーティショニングは、複雑さを軽減し、ガバナンスを改善し、再利用性を高め、整合性と俊敏性を高めることで、エンタープライズ アーキテクチャの開発と管理を簡素化するために使用されます。12 したがって、パーティションがエンタープライズ アーキテクチャの管理を簡素化するために使用されるという記述は正しいです。
その他の記述は、以下の理由で誤りです。
*パーティションはアーキテクチャ レベルと同じではありません。アーキテクチャ レベルは、戦略、セグメント、機能など、さまざまな観点からエンタープライズ アーキテクチャを説明する、異なる抽象化レイヤーです3。
パーティションは、特定の基準に基づいてレベル内またはレベル間で定義されるアーキテクチャのサブセットです1。
*パーティションは必ずしも組織の構造を反映するものではありません。組織の構造はアーキテクチャをパーティション分割するための 1 つの基準ですが、唯一の基準ではありません。ビジネス機能、製品、サービス、地理などの他の基準もアーキテクチャをパーティション分割するために使用できます12。
*パーティションは、アジャイル エンタープライズ アーキテクチャ チームに定義および割り当てられません。アジャイル エンタープライズ アーキテクチャは、反復的な開発、頻繁なフィードバック、適応型計画、継続的な配信など、アジャイルの原則とプラクティスをアーキテクチャ作業に適用するアプローチです4。パーティションは、アジャイル エンタープライズ アーキテクチャの特定の機能ではなく、TOGAF12 を含むあらゆるアーキテクチャ メソッドまたはフレームワークに適用できる一般的な手法です。
参照: 1: TOGAF 標準バージョン 9.2 - アーキテクチャ パーティショニング 2: TOGAF® 標準 - 概要 - アーキテクチャ パーティショニング 3: [TOGAF 標準バージョン 9.2 - アーキテクチャ ランドスケープ全体への ADM の適用] 4: TOGAF® 標準 - 概要 - 定義 - The Open Group

説明
表示されているチャートはガントチャートです。これはプロジェクト管理でプロジェクトスケジュールを示すためによく使用されます。エンタープライズアーキテクチャのフレームワークである TOGAF (The Open Group Architecture Framework) のコンテキストでは、このガントチャートはアーキテクチャ開発手法 (ADM) への順序付けられたアプローチを示しています。ADM は、アーキテクチャを開発するためのテスト済みの繰り返し可能なプロセスを提供する TOGAF のコアプロセスです。ADM は、プロセス全体、フェーズ間、フェーズ内で反復的であると説明されています。ADM の各反復では、各パラメーター (範囲、粒度、期間、およびアーキテクチャ資産) について新たな決定を行う必要があります。
ADM は、順番に実行する必要があるいくつかのフェーズで構成されています。
予備段階: 枠組みと原則
フェーズA: アーキテクチャビジョン
フェーズ B: ビジネスアーキテクチャ
フェーズ C: データおよびアプリケーション アーキテクチャを含む情報システム アーキテクチャ、フェーズ D: テクノロジ アーキテクチャ、フェーズ E: 機会とソリューション、フェーズ F: 移行計画、フェーズ G: 実装ガバナンス、フェーズ H: アーキテクチャ変更管理、要件管理。各フェーズは前のフェーズの出力に依存しており、要件管理フェーズはフェーズ全体にわたって実行されます。ガント チャートには、これらのフェーズが発生する依存関係と順序が明確に示されており、構造化されたアプローチに従ってエンタープライズ アーキテクチャが作成されていることが示されています。
参考文献:
TOGAF 標準バージョン 9.2、The Open Group の標準
TOGAFのドキュメントはhttps://publications.opengroup.org/standards/architectureで入手可能であり、
https://publications.opengroup.org/guides/architecture

説明
アーキテクチャ原則の TOGAF テンプレートによれば、根拠セクションでは、他の原則との関係、ビジネス上の利点、原則を遵守する意図について説明する必要があります。
根拠セクションでは、ビジネス用語を使用し、情報とテクノロジーの原則とビジネス運営を管理する原則の類似点を指摘する必要があります。また、根拠セクションでは、原則がビジネス目標と主要なアーキテクチャ ドライバーの達成をどのようにサポートするかについても説明する必要があります。参考資料:
アーキテクチャ原則テンプレート
TOGAF 標準、バージョン 9.2 - アーキテクチャの原則
オープングループ試験 OGEA-103 トピック 1 質問 4 ディスカッション

ターゲット アーキテクチャは、ビジネス目標と推進要因に対応し、利害関係者の要件と懸念事項を満たすアーキテクチャの将来の状態を説明したものです。ターゲット アーキテクチャは、エンタープライズ アーキテクチャの開発と管理をガイドする TOGAF 標準のコア プロセスであるアーキテクチャ開発手法 (ADM) を通じて開発されます。ターゲット アーキテクチャは通常、ビジネス、データ、アプリケーション、テクノロジの 4 つのドメインに分かれています。ターゲット アーキテクチャには、移行アーキテクチャ、機能増分、およびベースライン アーキテクチャからターゲット アーキテクチャへの移行を可能にする作業パッケージを定義する変更のロードマップも含まれます12 最適な答えは B です。これは、要求されたアーキテクチャ (情報システム アーキテクチャとテクノロジ アーキテクチャ) を実現するための作業を決定および編成するために取るべきアプローチを説明しているからです。
答えは次のステップをカバーしています。
ガイダンスと指示については、エンドツーエンドのターゲット アーキテクチャを参照してください。エンドツーエンドのターゲット アーキテクチャは、アーキテクチャ作業の全体的なビジョン、範囲、目的、およびビジネス戦略と目標との整合性を提供します。また、エンドツーエンドのターゲット アーキテクチャは、4 つのアーキテクチャ ドメインの高レベルの定義と原則、および主要なマイルストーンと成果物の概要を示す変更のロードマップも提供します。
プロジェクト、依存関係、および相乗効果を特定し、プロジェクトを開始する前に優先順位を付けます。プロジェクトは、アーキテクチャ作業パッケージを実装する作業単位です。アーキテクチャ作業パッケージは、アーキテクチャの特定の部分を実装するために必要な一連のアクションまたはタスクです。依存関係は、論理的依存関係、時間的依存関係、リソース依存関係など、プロジェクトの順序または優先順位に影響を与える関係と制約です。相乗効果は、コスト削減、効率性の向上、革新の機会など、プロジェクトの組み合わせまたは調整から生じる利点またはメリットです。優先順位付けは、プロジェクトをその重要性、緊急性、または価値に応じてランク付けし、それに応じてリソースとスケジュールを割り当てるプロセスです。
高レベルのアーキテクチャ記述を作成します。高レベルのアーキテクチャ記述は、ADM サイクルのアーキテクチャ開発フェーズ (B、C、および D) の出力であり、ビジネス、データ、アプリケーション、およびテクノロジ アーキテクチャを、ビジネス、IT、またはアーキテクチャ機能の再利用可能なコンポーネントであるアーキテクチャ ビルディング ブロック (ABB) とソリューション ビルディング ブロック (SBB) の観点から記述します。高レベルのアーキテクチャ記述には、1 人以上の利害関係者の視点から対象システムとその懸念を表すアーキテクチャ ビューも含まれます。
各プロジェクトについて、作業規模を見積もり、参照アーキテクチャと候補となるビルディング ブロックを特定します。
労力規模は、プロジェクトを完了するために必要な作業量、時間、またはリソースの量を測る尺度です。
作業量は、類推、専門家の判断、パラメトリック、ボトムアップなどのさまざまな手法を使用して見積もることができます。リファレンス アーキテクチャは、特定のドメインまたは業界に共通のフレームワークと語彙を提供する標準化されたアーキテクチャです。リファレンス アーキテクチャは、アーキテクチャ開発のベスト プラクティス、パターン、およびモデルのソースとして使用できます。候補ビルディング ブロックは、アーキテクチャを実装するために使用できる潜在的な ABB または SBB です。候補ビルディング ブロックは、モデル、パターン、原則、標準、ガイドラインなどのアーキテクチャ アセットのコレクションであるアーキテクチャ リポジトリから特定できます。
コストと価値を考慮してリソースのニーズを特定します。リソースのニーズとは、人的、財務的、物理的、または技術的リソースなど、プロジェクトの完了に必要なリソースの許容レベルと品質を定義する仕様と基準です。リソースのニーズは、プロジェクトの範囲、複雑さ、依存関係、およびリソースの可用性、機能、適合性を分析することで特定できます。コストと価値は、予算、投資収益率、利点、リスクなど、リソースの割り当てと利用に影響を与える要因です。
オプション、リスク、および制御を文書化して、実行可能性の分析と利害関係者とのトレードオフを可能にします。
オプションとは、さまざまなソリューション、テクノロジ、ベンダー、アプローチなど、プロジェクト目標を達成するための代替手段です。リスクとは、脅威や機会など、プロジェクト目標に対する不確実性の影響です。コントロールとは、ポリシー、手順、標準など、リスクを防止、削減、緩和するために講じられる対策またはアクションです。実行可能性分析とは、オプション、リスク、コントロールを評価および比較し、各オプションの実現可能性、適合性、望ましさを判断するプロセスです。トレードオフとは、利害関係者の複数の、しばしば相反する要件と懸念のバランスを取り、調整し、アーキテクチャ ビジョンとアーキテクチャ プリンシパルとの整合性を確保する決定結果です。
参照資料: 1: TOGAF 標準バージョン 9.2、パート II: アーキテクチャ開発手法 (ADM)、第 5 章: ADM の概要 2: TOGAF 標準バージョン 9.2、パート IV: アーキテクチャ コンテンツ フレームワーク、第 36 章: ビルディング ブロック : TOGAF 標準バージョン 9.2、パート II: アーキテクチャ開発手法 (ADM)、第 18 章: フェーズ A: アーキテクチャ ビジョン : TOGAF 標準バージョン 9.2、パート II: アーキテクチャ開発手法 (ADM)、第 19 章: フェーズ B: ビジネス アーキテクチャ : TOGAF 標準バージョン 9.2、パート II: アーキテクチャ開発手法 (ADM)、第 20 章: フェーズ C: 情報システム アーキテクチャ : TOGAF 標準バージョン 9.2、パート II: アーキテクチャ開発手法 (ADM)、第 21 章: フェーズ F: 移行計画 : TOGAF 標準バージョン 9.2、パート III: ADM ガイドラインとテクニック、第 23 章: アーキテクチャの原則 : TOGAF 標準、バージョン 9.2、パート III:
ADM ガイドラインとテクニック、第 30 章: トレードオフ分析 : TOGAF 標準、バージョン 9.2、パート VI: アーキテクチャ機能フレームワーク、第 46 章: アーキテクチャ開発ツール : TOGAF 標準、バージョン 9.2、パート VI: アーキテクチャ機能フレームワーク、第 47 章: アーキテクチャ ボード : TOGAF 標準、バージョン 9.2、パート VI: アーキテクチャ機能フレームワーク、第 48 章: アーキテクチャ コンプライアンス : TOGAF 標準、バージョン 9.2、パート VI: アーキテクチャ機能フレームワーク、第 49 章:
アーキテクチャ契約: TOGAF 標準、バージョン 9.2、パート VI: アーキテクチャ機能フレームワーク、第 50 章: アーキテクチャ ガバナンス: TOGAF 標準、バージョン 9.2、パート VI: アーキテクチャ機能フレームワーク、第 51 章: アーキテクチャ成熟度モデル: TOGAF 標準、バージョン 9.2、パート VI:
アーキテクチャ能力フレームワーク、第 52 章: アーキテクチャ スキル フレームワーク