準備フェーズは、アーキテクチャ開発手法（ADM）サイクルの準備フェーズであり、アーキテクチャ作業のコンテキストと方向性を設定します。このフェーズの目的の1つは、アーキテクチャ能力（組織がエンタープライズアーキテクチャを効果的かつ効率的に実行できる能力）をサポートするためのツールを選択し、実装することです。ツールには、アーキテクチャ開発およびガバナンスプロセスを支援するソフトウェアアプリケーション、手法、技術、標準、フレームワークが含まれます。ツールの選択と実装は、組織の要件と制約、およびアーキテクチャ原則とアーキテクチャビジョン3との整合性に基づいて行う必要があります。参考文献：3：TOGAF標準バージョン9.2、パートII：アーキテクチャ開発手法（ADM）、第6章：準備フェーズ：TOGAF標準バージョン9.2、パートVI：アーキテクチャ能力フレームワーク、第45章：エンタープライズアーキテクチャ能力の確立と維持：TOGAF標準バージョン9.2、パートVI：アーキテクチャ能力フレームワーク、第46章：アーキテクチャ開発のためのツール

「影響」セクションでは、原則を遵守することによる組織、プロセス、情報システム、そしてテクノロジーへの影響について説明します23。また、原則の適用によって生じる可能性のある変化、コスト、そしてリスクについても説明します23。「影響」セクションは、原則の利点と結果を利害関係者に伝え、アーキテクチャの実装とガバナンスを導くのに役立ちます23。
アーキテクチャ原則の TOGAF テンプレートの他のセクションは次のとおりです。
*名称: このセクションでは、原則の本質と目的を表す、簡潔で覚えやすい名称を記載します23。具体的な技術やソリューションに言及する名称は含めないでください23。
*ステートメント：このセクションでは、原則が課す基本的な規則または制約を簡潔かつ正式に定義します23。ステートメントは明確で、曖昧さがなく、検証可能である必要があります23。
*根拠：このセクションでは、原則の重要性と、それがビジネス目標と推進要因23をどのようにサポートするかを説明する根拠と正当性を示します。また、根拠では、原則を、その原則が詳述する上位レベルのエンタープライズ原則またはIT原則23と関連付ける必要があります。

これは、次の TOGAF アーキテクチャ リポジトリ モデルと一致しています。
* (アーキテクチャ要件リポジトリ) には、アーキテクチャ作業を推進する要件が含まれています。
* B (ソリューション リポジトリ) には、アーキテクチャをサポートするビルディング ブロックまたはソリューションが格納されます。
* C (アーキテクチャ ランドスケープ) は、企業全体の現在のアーキテクチャ状態、移行状態、およびターゲット アーキテクチャ状態を表すアーキテクチャ アセットを表します。

アーキテクチャ・プロジェクトの計画期間、深さ、幅、そしてEAリポジトリの内容は、通常、戦略、ポートフォリオ、セグメント、そしてエンドツーエンドのターゲット・アーキテクチャによって構成されます。「セグメント」とは組織の一部を指し、通常はセグメント・アーキテクチャで扱われます。一方、「エンドツーエンドのターゲット・アーキテクチャ」は、組織全体にわたる計画されたアーキテクチャの全体像を包含します。

TOGAF 標準によれば、説明に一致する成果物は次のとおりです。
1 アーキテクチャ原則：これらは、永続的でめったに変更されないことを意図した一般的な規則とガイドラインであり、組織がその使命を果たすための方法を示し、サポートします1。これらは、企業内の様々な要素間の合意レベルを反映し、将来のITに関する意思決定の基礎となります1。
2 アーキテクチャ契約：開発パートナーとスポンサーの間で、アーキテクチャの成果物、品質、および目的適合性について締結される共同契約です2。合意された仕様と標準に従ってアーキテクチャが実装および管理されることを保証するために使用されます2。
3 アーキテクチャ作業依頼書：これは、アーキテクチャ開発サイクル3の開始を促すために、スポンサー組織からアーキテクチャ組織に送信される文書です。アーキテクチャプロジェクト3のスコープ、スケジュール、予算、成果物、および関係者を定義します。
4 アーキテクチャ要件仕様：これは、実装プロジェクトがアーキテクチャ4に準拠するために何を行う必要があるかを概説した定量的な記述の集合です。各アーキテクチャドメインの要件と、それらの間の関係性および依存関係を定義します4。
1: アーキテクチャの原則 2: アーキテクチャ契約 3: アーキテクチャ作業の依頼 4: アーキテクチャ要件仕様