ADM サイクルのフェーズ B は、ビジネス アーキテクチャ フェーズです。合意されたアーキテクチャ ビジョンをサポートするビジネス アーキテクチャの開発について説明します。このフェーズの目的は、ベースラインとターゲットのビジネス アーキテクチャを説明し、ベースラインとターゲットのギャップに基づいて候補となるアーキテクチャ ロードマップ コンポーネントを特定し、増分アプローチが必要かどうかを判断することです。参照: TOGAF 標準 | The Open Group Web サイト、セクション 3.2.2 フェーズ B: ビジネス アーキテクチャ。

この図は、エンタープライズ アーキテクチャを開発および管理するための手法である TOGAF ADM (アーキテクチャ開発手法) に基づいたアーキテクチャ開発サイクルを示しています1。
ADM は 9 つのフェーズで構成され、それぞれに特定の目的と出力があります。フェーズは次のとおりです。
予備フェーズ: アーキテクチャ フレームワーク、原則、ガバナンスの定義を含む、アーキテクチャ開発サイクルを準備して開始します。
フェーズ A: アーキテクチャ ビジョン: アーキテクチャ イニシアチブの範囲、ビジョン、および関係者を定義し、続行するための承認を取得します。
フェーズ B: ビジネス アーキテクチャ: ベースラインとターゲットのビジネス アーキテクチャを説明し、それらの間のギャップを特定します。
フェーズ C: 情報システム アーキテクチャ: ベースラインとターゲットのデータおよびアプリケーション アーキテクチャを説明し、それらの間のギャップを特定します。
フェーズ D: テクノロジー アーキテクチャ: ベースラインとターゲットのテクノロジー アーキテクチャを説明し、それらの間のギャップを特定します。
フェーズ E: 機会とソリューション: ターゲット アーキテクチャを実装するための機会とソリューションを特定して評価し、作業パッケージと移行アーキテクチャを定義します。
フェーズ F: 移行計画: 実装と移行計画を最終決定し、エンタープライズ ポートフォリオおよびプロジェクト管理との整合性を確保します。
フェーズ G: 実装ガバナンス: 実装プロジェクトに対するアーキテクチャの監視とガイダンスを提供し、アーキテクチャの変更要求を管理します。
フェーズ H: アーキテクチャ変更管理: ビジネスおよびテクノロジ環境の変化を監視し、アーキテクチャの影響とパフォーマンスを評価します。
これらのフェーズに加えて、図の項目 1 としてラベル付けされている要件管理と呼ばれる中心的なプロセスがあります。このプロセスは ADM サイクル全体で実行され、その目的は、アーキテクチャ開発全体にわたってアーキテクチャ要件を管理し、ビジネス要件と利害関係者の懸念事項2 と整合させることです。
したがって、項目 1 としてラベル付けされた ADM のフェーズに一致する説明は、C. アーキテクチャ要件を管理するプロセスを運用します。
参照：
1: TOGAF 標準、バージョン 9.2、第 5 章: アーキテクチャ開発手法 (ADM)
2: TOGAF 標準、バージョン 9.2、第 17 章: 要件管理

TOGAF の文脈では、利害関係者とは、アーキテクチャの結果に関心がある、またはそれに関連する懸念を持つ個人、チーム、または組織を指します。懸念とは、パフォーマンス、信頼性、セキュリティなどの考慮事項を含む、システムの機能、開発、または運用のあらゆる側面に関連する関心のことです1。参考:
* TOGAF 標準、バージョン 9.2 - 定義 - The Open Group

アーキテクトは、フェーズ B からフェーズ C までのギャップ分析結果を確認して統合する必要があります。これにより、提案されたターゲット アーキテクチャを実現するために必要な変革が特定されます。次に、エンタープライズ アーキテクトは、組織が変化を受け入れる準備ができているかどうかを評価し、特定されたリスクに対処して軽減するための全体的な方向性を決定する必要があります。次に、状態進化表を使用して移行アーキテクチャを計画する必要があります。
Explanation:
ビジネス変革準備評価は、組織が変革を受け入れる準備ができているかどうかを評価し、ビジネス変革を成功させる可能性を高めるために必要なアクションを特定するために使用できる手法です。この手法は、提案された再編のリスクと価値に関する主要な利害関係者の懸念に対処するのに役立ちます。この手法では、組織のビジョン、コミットメント、キャパシティ、能力、文化、コミュニケーションの側面を評価します。評価に基づいて、変革に関連するリスクを特定、分類、および軽減できます。この手法は、ギャップや作業パッケージを含む一連の変更と、実装および移行計画に組み込む改善アクションとの間の依存関係を特定するのにも役立ちます。この手法は、各変革に関連するビジネス価値、労力、およびリスクの決定もサポートします。これは、作業パッケージと移行アーキテクチャの優先順位付けと順序付けに使用できます1 参照: 1: TOGAF 標準、バージョン 9.2、パート III: ADM ガイドラインと手法、第 27 章: ビジネス変革準備評価

説明
TOGAF 標準によると、アーキテクチャ ビューとは、関連する一連の懸念事項の観点からシステムを表現するものです1。アーキテクチャ ビューポイントとは、特定の種類のアーキテクチャ ビューの規則の仕様です1。さまざまなアーキテクチャ ビューとアーキテクチャ ビューポイントを利害関係者に提示することで、アーキテクトは、最終的なターゲット アーキテクチャに影響を与える可能性のある隠れた課題、原則、要件を抽出できます。これは、利害関係者によってシステムに対する懸念事項や関心が異なる可能性があるためです。システムがさまざまな観点から利害関係者の懸念事項にどのように対処しているかを示すことで、アーキテクトは利害関係者からより多くのフィードバックと検証を引き出すことができます2。たとえば、ビジネス利害関係者は、システムのビジネス プロセス、機能、および機能に焦点を当てたビジネス アーキテクチャ ビューに関心がある可能性があります3。セキュリティ利害関係者は、機密性、整合性、可用性など、システムのセキュリティ面に対処するエンタープライズ セキュリティ ビューに関心がある可能性があります3。これらのビューをそれぞれの利害関係者に提示することで、アーキテクトはシステムが利害関係者の期待とニーズを満たしていることを確認できるほか、ターゲット アーキテクチャに影響を与える可能性のある潜在的な問題やギャップを特定できます。参考資料: 1: TOGAF 標準バージョン 9.2 - アーキテクチャ アーティファクト - The Open Group1; 2: エンタープライズ アーキテクチャにおける TOGAF ビューとビューポイントの理解2; 3: アーキテクチャ ビューの開発 - The Open Group4