説明
TOGAF 標準によれば、ADM プロセスをガバナンスする必要性は、アーキテクチャの開発と実装の活動が、一貫性があり、首尾一貫し、準拠した方法で行われるようにすることです1。ガバナンスは、方法が正しく効果的に適用されていること、およびアーキテクチャの成果物と成果物が品質と標準の基準を満たしていることを検証する手段を提供します1。ガバナンスにより、ADM プロセス中に発生する可能性のあるリスク、問題、変更、依存関係の管理も可能になります1。
ADM プロセスを管理する利点は次のとおりです2:
*ビジネス戦略および目標とアーキテクチャの整合性の向上
*ステークホルダーの関与とコミュニケーションの強化
*アーキテクチャ資産とリソースの再利用と統合の向上
*アーキテクチャ作業の複雑さと重複の軽減
*変化するニーズや要件に対するアーキテクチャの俊敏性と適応性の向上
*アーキテクチャの成果と出力のコンプライアンスと監査可能性の向上参考文献: 1: アーキテクチャガバナンス 2: アーキテクチャガバナンスの利点

アーキテクチャ ランドスケープは、アーキテクチャ リポジトリ内の情報クラスであり、現在組織内で使用されている構成要素 (ベースライン アーキテクチャ) と将来計画されている構成要素 (ターゲット アーキテクチャ) のアーキテクチャ ビューを示します。アーキテクチャ ランドスケープには通常、企業内で使用されているアプリケーションのリスト、それらの関係と依存関係、およびその他の関連するアーキテクチャ情報が含まれます。アーキテクチャ ランドスケープは、既存のアプリケーションの再利用、統合、または廃止の機会、および現在のアーキテクチャまたは将来のアーキテクチャのギャップや重複を特定するのに役立ちます。
参照: : TOGAF 標準、バージョン 9.2、パート IV: アーキテクチャ コンテンツ フレームワーク、第 34 章: アーキテクチャ ランドスケープ : TOGAF 標準、バージョン 9.2、パート VI: アーキテクチャ機能フレームワーク、第 47 章: アーキテクチャ リポジトリ

表の目的は、次の ADM フェーズの出力であるターゲット アーキテクチャとアーキテクチャ ビジョンの開発に関連しています。
フェーズ A: アーキテクチャ ビジョン。提案されたエンタープライズ アーキテクチャの結果として提供される機能とビジネス価値の高レベルの目標ビジョンを開発します。3 フェーズ B: ビジネス アーキテクチャ。ビジネス目標を達成するために企業がどのように運営される必要があるかを説明するターゲット ビジネス アーキテクチャを開発します。
フェーズ C: 情報システム アーキテクチャ。アーキテクチャ作業ステートメントと利害関係者の懸念に対処する方法で、ビジネス アーキテクチャとアーキテクチャ ビジョンを実現するターゲット データ アーキテクチャとターゲット アプリケーション アーキテクチャを開発します。
フェーズ D: テクノロジー アーキテクチャ。アーキテクチャ作業ステートメントと利害関係者の懸念に対処しながら、論理的および物理的なアプリケーションとデータ コンポーネントを有効にするターゲット テクノロジー アーキテクチャを開発します。
したがって、正しい組み合わせは、以下に示すように 1C-2B-3A-4C です。

TOGAF 標準バージョン 9.2 によれば、アーキテクチャ契約とは、アーキテクチャの成果物、品質、目的適合性に関する開発パートナーとスポンサー間の共同契約です1。アーキテクチャ作業の範囲、責任、ガバナンスを定義し、アーキテクチャがビジネスの目標や目的と整合し、準拠していることを保証します1。
このシナリオでは、リード エンタープライズ アーキテクトが、アーキテクチャ契約のドラフトを確認し、各拠点でのバッテリー パック製造用の新しいプロセスの展開の一貫性と品質に関するチーフ エンジニアの懸念に対処するための最善のアプローチを推奨するように依頼しています。
最適な答えは C です。これは、TOGAF 標準バージョン 9.22 で説明されているアーキテクチャ契約の定義と使用に関するガイドラインとベスト プラクティスに従っているためです。これにより、契約がプロジェクト目標、有効性メトリック、受け入れ基準、およびリスク管理の重要な側面をカバーし、サードパーティの請負業者に対して法的に強制可能であることが保証されます。また、実装プロセスの重要なポイントでのコンプライアンス レビューのスケジュールと、アーキテクチャ契約からの逸脱を処理するメカニズム (アーキテクチャ ボードの関与と、プロセスをローカルのニーズに合わせてカスタマイズできるようにするための免除の付与の可能性を含む) が推奨されます。
他の選択肢は、次のいずれかの理由で正しくありません。23:
A . 内部チームから要求された変更については、アーキテクチャ ボードと実装組織の間で覚書を締結することを推奨します。サードパーティの請負業者に発行される契約については、完全に強制力のある法的契約にすることを推奨します。アーキテクチャ ボードがアーキテクチャ契約からのすべての逸脱を確認し、実装組織がプロセスをカスタマイズしてローカルのニーズを満たすことを許可する免除を与えるかどうかを検討することを推奨します。: このオプションでは、契約をレビューして、プロジェクト目標、有効性メトリック、受け入れ基準、およびリスク管理に対応していることを確認する必要性には対処していません。また、実装プロセスの重要なポイントでコンプライアンス レビューのスケジュールを設定することも推奨していません。さらに、内部チームには覚書で十分であると示唆していますが、法的拘束力や強制力がない可能性があります。
B . 内部チームによって実施される変更については、アーキテクチャ委員会と実装組織の間で覚書を結ぶことを推奨します。請負業者に契約書を発行する場合は、完全に法的に強制力のある契約にすることを推奨します。アーキテクチャ契約からの逸脱が見つかった場合は、実装組織がプロセスをカスタマイズしてローカルのニーズを満たすことができるように、アーキテクチャ委員会が免除を与えることを推奨します。: このオプションにはオプション A と同じ問題があり、アーキテクチャ委員会が常にあらゆる逸脱に対して免除を与える必要があることも意味しますが、場合によってはそれが適切または望ましくない可能性があります。
D . アーキテクチャ契約を使用して、複数の拠点にわたるアーキテクチャ ガバナンス プロセスを管理することをお勧めします。各拠点で完成した各バッテリー パックのパフォーマンスを評価し、必要に応じて変更要件を作成するための監視ツールの導入を推奨します。契約からの逸脱が検出された場合、アーキテクチャ ボードは、ローカルのニーズを満たすようにアーキテクチャ契約を変更することを許可する必要があります。このような場合、新しいアーキテクチャ作業要求を発行する必要があります。: このオプションでは、契約をレビューして、プロジェクトの目的、有効性メトリック、受け入れ基準、およびリスク管理に対応していることを確認する必要性が考慮されていません。また、実装プロセスの重要なポイントでコンプライアンス レビューのスケジュールを設定することも推奨されていません。さらに、アーキテクチャ ボードは、あらゆる逸脱に対してアーキテクチャ契約の変更を常に許可する必要があることを示唆していますが、これは適切ではないか、望ましくない場合があります。また、逸脱ごとに新しいアーキテクチャ作業要求を発行する必要があることも示唆していますが、これは不要または実行可能ではない可能性があります。
参照：
1: TOGAF 標準、バージョン 9.2、第 3 章: 定義と用語、セクション 3.1: 用語と定義
2: TOGAF 標準、バージョン 9.2、第 43 章: アーキテクチャ契約
3: TOGAF 標準、バージョン 9.2、第 44 章: アーキテクチャ ガバナンス

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