成果物1は、アーキテクチャ原則に関するものです。TOGAFでは、アーキテクチャ原則は予備フェーズの一部として確立されます。このフェーズでは、企業はアーキテクチャ能力を準備し、フレームワークとガバナンスのアプローチを定義し、アーキテクチャ作業を導く基本ルールを設定します。これらの原則は永続的かつ安定的であることを意図しており、これは質問の文言と完全に一致します。
成果物2はアーキテクチャ契約を指します。TOGAFでは、アーキテクチャ契約とは、開発パートナーとスポンサーの間で、成果物、品質に関する期待値、およびアーキテクチャの目的適合性について交わされる正式な合意です。これらの契約は単一のフェーズに限定されるものではありません。アーキテクチャと実装組織間の合意を正式なものにする必要がある場合など、ADMのさまざまな段階で開始および精緻化することができます。実装ガバナンスと密接に関連していますが、その概念はより広範であり、ガバナンスのニーズに応じてADMライフサイクル全体にわたって現れる可能性があります。
他の選択肢は誤りです。なぜなら、アーキテクチャ原則はフェーズAの成果物ではなく、アーキテクチャ契約はフェーズEまたは要件管理に限定されるものではないからです。したがって、正解は、成果物1は予備フェーズの成果物であり、成果物2はADMの様々な段階で発生する可能性がある、というものです。

包括的かつ詳細な説明
TOGAFでは、アーキテクチャ原則を、アーキテクチャが満たすべき意図を定性的に記述したものと定義しています。明確性と一貫した適用を確保するため、TOGAFは各原則を文書化するための標準テンプレートを提供しています。このテンプレートは、以下の4つの部分から構成されています。
* 名称 - 原則を表す、明確で正確かつ覚えやすい名称。
* この原理は何と呼ばれているかという質問に答えます。
* 声明 - 原則の本質を伝える、簡潔で明確な一文。
* この原則は何を意味するのか、という疑問に答えます。
* 根拠 - その原則が重要な理由、それを採用することの利点、そしてそれが企業の目標をどのように支援するかを説明します。
* この原則を採用すべき理由は何ですか？という問いに答えます。
* 影響 - 原則を採用することによる結果、特にビジネスプロセス、テクノロジー、ガバナンス、リソースへの影響を強調します。
* 「これは私にどのような影響を与えるのか？」という疑問に答えます。
したがって、「これは自分にどのような影響を与えるのか？」という疑問に対する答えを見つけるのに最適なセクションは、「影響」です。
他の選択肢が間違っている理由
* A. 声明：原則の本質を定義するが、結果については触れない。
* B. 根拠：原則の論理と正当性を説明するが、その実際的な影響については説明しない。
* C. 名前: 原則の識別子またはタイトルのみを提供します。
参考文献
* The Open Group、TOGAF標準、バージョン9.2、パートIII：ADMガイドラインとテクニック - アーキテクチャ原則。
* The Open Group、TOGAF 9 認定学習ガイド - アーキテクチャ原則テンプレートの説明と各セクションの目的。

フェーズ E: 機会と解決策 - ステップ/成果物では、作業パッケージ、依存関係のグループ化、および価値/労力を反映したロードマップ/計画の策定を重視します。
「主要な作業パッケージを特定してグループ化する...依存関係を精緻化して検証する...アーキテクチャロードマップと実装および移行計画を作成する。」 www.opengroup.org 参照: The Open Group、TOGAF適合要件 - フェーズEの手順と出力。

アジャイル開発を検討する際、ポートフォリオをサポートするアーキテクチャは、企業に必要な製品を特定し、その境界を定義し、プロダクトオーナーに対する制約を概説します。このプロセスは、企業のバックログの定義に直接関係します。バックログとは、アジャイル手法において、ロードマップとその要件から導き出される、開発チームの作業の優先順位付けされたリストです。