説明
アーキテクチャ要件リポジトリには、アーキテクチャ開発サイクルの出力であるすべての要件と、アーキテクチャ開発サイクルに入力される要件が保存されます1。アーキテクチャ要件リポジトリには、次のタイプの要件が含まれています1。
*利害関係者の要件: これらは、ビジネスの推進力、目標、目的から導き出される、利害関係者の高レベルの要件と期待です。これらは、アーキテクチャ ビジョン フェーズと要件管理フェーズで取得され、洗練されます。
*アーキテクチャ要件: これらは、利害関係者の要件を満たすためにアーキテクチャが実行または提供する必要があることを指定する詳細な要件です。これらは、ビジネス、情報システム、テクノロジー アーキテクチャの各フェーズで派生および洗練されます。
*実装および移行の要件: アーキテクチャを実現するために実装および移行プロジェクトが実行または提供しなければならないことを指定する詳細な要件です。これらは、機会とソリューションおよび移行計画のフェーズで導き出され、洗練されます。
アーキテクチャ要件リポジトリは、アーキテクチャのライフサイクル全体を通じてアーキテクチャ要件を管理し、そのトレーサビリティ、一貫性、およびコンプライアンスを確保するために使用されます1。アーキテクチャ委員会は、アーキテクチャ ガバナンス プロセスの一環として、アーキテクチャの要件だけでなく、アーキテクチャの成果物や成果物も検討および承認する機関です2。
参考資料: 1: アーキテクチャ要件リポジトリ 2: アーキテクチャ ボード

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

*フェーズ A: アーキテクチャ ビジョン
o 提案されたエンタープライズ アーキテクチャの結果として提供される機能とビジネス価値に関する高レベルの野心的なビジョンを策定する o アーキテクチャへの取り組みの範囲と境界を定義する o 主要な利害関係者とその懸念と期待を特定する o アーキテクチャ ビジョン ステートメントとアーキテクチャを定義する定義文書 o スポンサーおよび利害関係者から承認とコミットメントを得る
*フェーズ B: ビジネス アーキテクチャ
o ビジネス目標を達成するために企業がどのように運営する必要があるかを説明するターゲット ビジネス アーキテクチャを開発します。 o ベースライン ビジネス アーキテクチャを定義します (利用できない場合)。 o ベースラインとターゲット ビジネス アーキテクチャの間のギャップ分析を実行します。 o ビジネス アーキテクチャのロードマップ コンポーネントの候補を定義します。 o ビジネス全体にわたる影響を解決します。建築風景
*フェーズ C: 情報システム アーキテクチャ
o ビジネス アーキテクチャとアーキテクチャ ビジョンを実現するターゲット データ アーキテクチャを開発します。 o ビジネス アーキテクチャとアーキテクチャ ビジョンをサポートするターゲット アプリケーション アーキテクチャを開発します。 o ベースライン データとアプリケーション アーキテクチャを定義します (利用できない場合)。 o ベースライン データとターゲット データの間のギャップ分析を実行します。アプリケーション アーキテクチャ o 情報システム アーキテクチャのロードマップ コンポーネントの候補を定義 o アーキテクチャ ランドスケープ全体の影響を解決
*フェーズ D: テクノロジー アーキテクチャ
o 情報システム アーキテクチャとアーキテクチャ ビジョンを実現するターゲット テクノロジ アーキテクチャを開発します。 o ベースライン テクノロジ アーキテクチャを定義します (利用できない場合)。 o ベースライン テクノロジ アーキテクチャとターゲット テクノロジ アーキテクチャの間のギャップ分析を実行します。 o ベースライン テクノロジ アーキテクチャとターゲット テクノロジ アーキテクチャの間のギャップに基づいて、候補となるアーキテクチャ ロードマップ コンポーネントを特定します。 oアーキテクチャランドスケープ全体の影響を解決する したがって、目的とフェーズの正しい一致は次のようになります。
※1C：ビジネスアーキテクチャとアーキテクチャビジョンを実現するターゲットデータアーキテクチャの開発
*2B: ビジネス目標を達成するために企業がどのように運営する必要があるかを記述したターゲット ビジネス アーキテクチャを開発する
*3A: 提案されたエンタープライズ アーキテクチャの結果として提供される機能とビジネス価値について、高レベルの野心的なビジョンを策定する
*4D: ベースライン アーキテクチャとターゲット テクノロジ アーキテクチャ間のギャップに基づいて、候補となるアーキテクチャ ロードマップ コンポーネントを特定する 参考資料: 1: TOGAF アーキテクチャ開発手法

アーキテクチャ作業のリクエストはスポンサーから送信される成果物であり、アーキテクチャ開発サイクルの開始のきっかけになります。特定のアーキテクチャ プロジェクトの範囲、予算、スケジュール、成果物を定義します。アーキテクチャ作業ステートメントは、建築家によって作成される成果物であり、アーキテクチャ プロジェクトを完了するために必要なアプローチとリソースを定義します。これは、スポンサーと建築組織の間の契約合意の基礎となります。アーキテクチャ原則は、アーキテクトによって作成される成果物であり、アーキテクチャ作業の一般的なルールとガイドラインを定義します。これらは、組織のビジネス原則、ビジネス目標、ビジネス推進力を反映しています。アーキテクチャ要件仕様は、アーキテクトによって作成される成果物であり、アーキテクチャ作業を管理する要件を定義します。機能要件と非機能要件の両方、および制約と仮定をカバーします。

EA 能力は、エンタープライズ アーキテクチャを効果的かつ効率的に実行する組織の能力です。
これには、エンタープライズ アーキテクチャの開発と使用をサポートするための、適切な組織構造、役割、責任、スキル、プロセス、ツール、ガバナンス メカニズムの確立と維持が含まれます。EA 機能により、組織はビジネス戦略と IT 戦略を調整し、投資から価値を実現し、変化と複雑さを管理し、パフォーマンスと俊敏性を向上させることができます12 参考資料: 1: TOGAF 標準、バージョン 9.2、パート VI: アーキテクチャ機能フレームワーク、章44: はじめに 2: TOGAF 標準、バージョン 9.2、パート VI: アーキテクチャ機能フレームワーク、第 45 章: エンタープライズ アーキテクチャ機能の確立と維持