概要 DoDAFは、組織、統合、多国籍の境界を越えてアーキテクチャを理解、比較、統合するための共通項を保証するアーキテクチャ記述の開発と表現のための基礎的なフレームワークを提供します。データ要素の定義、ルール、関係、およびシステム、統合、または連合アーキテクチャの一貫した開発のためのベースライン製品セットを確立します。これらのアーキテクチャ記述には、システムファミリー（FoS）、システムオブシステムズ （SoS）、および非戦闘環境での相互運用と相互作用のためのネットワーク中心の機能が含まれる場合があります。[ 1 ]
DoD の各コンポーネントは、部門内のアーキテクチャの開発において、可能な限り DoDAF に準拠することが求められています。準拠することで、情報、アーキテクチャ成果物、モデル、およびビューポイントを共通の理解のもとで再利用できるようになります。米国国防総省の主要な兵器および情報技術システムの調達はすべて、DoDAF で規定されたビューを使用してエンタープライズ アーキテクチャ (EA) を開発および文書化する必要があります。DoDAF は明らかに軍事システムを対象としていますが、世界中の民間、公共、およびボランティア部門に幅広く適用可能であり、多数のシステムアーキテクチャ フレームワーク の 1 つです。[ 4 ] [ 5 ]
DoDAFの目的は、国防総省の6つのコアプロセスで使用できる概念とモデルを定義することです。[ 6 ] 統合能力統合開発（JCIDS） 計画、プログラム策定、予算編成、および実行（PPBE） 防衛獲得システム (DAS) システムエンジニアリング（SE） 作戦計画（OPLAN） 能力ポートフォリオ管理（CPM） さらに、DoDAF 2.0 の具体的な目標は次のとおりでした。[ 6 ] 目的に応じたアーキテクチャコンテンツに関するガイドラインを確立する ― 「目的に適合する」 厳密なデータモデルであるDoDAFメタモデル（DM2）を用いることで、アーキテクチャの有用性と有効性を向上させ、より精度の高い統合、分析、評価を可能にする。
歴史 1990年代以降のDoDAFの進化。DoDAF V2.0は2009年5月にリリースされた。[ 1 ] DoDAF 開発の最初のバージョンは、1990 年代にC4ISR アーキテクチャ フレームワークという名称で開発されました。同じ時期に、1986 年に開始された参照モデルTAFIM がさらに開発されました。1996 年 6 月 7 日にリリースされた最初の C4ISR アーキテクチャ フレームワーク v1.0 は、 クリンガー・コーエン法 の成立に対応して作成されました。これは、C4ISR 機能が相互運用可能で戦闘員のニーズを満たすことを保証するためのより良い手段とプロセスを定義および開発するために国防総省全体で取り組むべきであるという 1995 年の国防副長官の指示に対応しています。継続的な開発努力の結果、1997 年 12 月に第 2 バージョンである C4ISR アーキテクチャ フレームワーク v2.0 がリリースされました。[ 1 ]
2003 年 8 月に DoDAF v1.0 がリリースされ、C4ISR Framework v2.0 を再構築して、ガイダンス、製品の説明、補足情報を 2 巻とデスク ブックで提供しました。アーキテクチャの原則と実践の適用範囲を C4ISR コミュニティだけでなく、すべてのミッション エリアに拡大しました。この文書では、使用法、統合アーキテクチャ、国防総省および連邦政府のポリシー、アーキテクチャの価値、アーキテクチャの尺度、国防総省の意思決定支援プロセス、開発手法、分析手法、CADM v1.01 について取り上げ、アーキテクチャ 製品を構成するアーキテクチャ データ要素に重点を置くことで、リポジトリ ベースのアプローチに移行しました。[ 1 ] 任務ニーズ記述書 （MNS）は、任務上の欠陥を解消したり、運用能力を向上させたりするために、プログラムが満たすべき能力ニーズを、複数の解決策（DOTMLPF ）の組み合わせによって特定する 米国 国防総省の文書でした。この種の文書は、CJCSI 3170.01E以降、初期能力文書と呼ばれる能力ニーズの記述に置き換えられました。CJCSI 3170.01および6212.01は、CJCSI 5123.01シリーズに置き換えられました。
この用語は、CJCSI 3170.01B（2001年4月）、6212.01D（2005年4月）、および暫定防衛調達ガイドブック（2004年10月）において、基本的なステップとして導入されました。
2009年5月28日、DoDAF v2.0は国防総省によって承認されました。[ 7 ] [ 8 ] [ 9 ]
DoDAF に基づくその他の派生フレームワークには、NATO アーキテクチャ フレームワーク (NAF) や国防省アーキテクチャ フレームワーク などがあります。他の EA アプローチ、例えばThe Open Group Architecture Framework (TOGAF) と同様に、DoDAF は作業成果物を格納する共有リポジトリを中心に構成されています。リポジトリは、共通データベース スキーマであるCore Architecture Data Model 2.0 と DoD アーキテクチャ レジストリ システム (DARS) によって定義されます。DoDAF の重要な特徴は相互運用性であり、これは情報システム相互運用性レベル (LISI) と呼ばれる一連のレベルとして構成されています。開発中のシステムは、内部データのニーズを満たすだけでなく、システムが設定されている運用フレームワークのニーズも満たす必要があります。
能力と任務 任務／行動方針、スレッド、活動、アーキテクチャと関連付けられた能力重視の図については、図を参照してください。
アーキテクチャで説明される機能 国防総省は、システム／サービスの構築理由である能力の提供に重点を置く方向へと移行している。能力モデルは、能力の分類体系と能力の進化を説明する。能力スレッドは、特定の能力に関連付けられた具体的な活動、ルール、およびシステムに相当します。
メタモデルデータグループによって定義された能力の概念は、次のような質問に答えることを可能にする。
特定の機能、あるいは複数の機能は、全体的なミッション／ビジョンをどのように支えるのか？ 特定の能力、あるいは一連の能力によって、どのような成果が期待されるのか？ ある機能をサポートするために、どのようなサービスが必要ですか？ ある能力または一連の能力の機能的範囲と組織的範囲とは何ですか？ 現在、ポートフォリオの一部として管理している機能セットは何ですか？ [ 10 ]
任務または行動方針は、作戦構想 （CONOPS）によって記述され、能力別に構成される。
機能はスレッドによって記述されます。 スレッドは、直列または並列に実行されるアクティビティによって記述されます。 活動はミッション領域に分類されます。活動はアーキテクチャの運用を定義します。 アーキテクチャは、ミッション領域ごとに編成されます。アーキテクチャは、ミッションまたは行動方針に必要な機能を適切にリソース配分します。
バージョン1.5の閲覧数 DoDAF V1.5 ビュー間のリンク。[ 1 ] 国防総省C4ISRフレームワーク DoDAF V1.5では、グラフィック、表形式、またはテキスト形式を用いて、アーキテクチャ記述の広範な範囲と複雑さを視覚化、理解、および同化するためのメカニズムとして機能する一連の成果物（ビューモデル ）が定義されています。これらの成果物は、次の4つのビューに分類されます。
全画面表示（AV） 運用ビュー （OV）システムビュー（SV） 技術標準の見解（TV） 各ビューは、以下に説明するように、アーキテクチャの特定の視点を示しています。通常、各システム開発では、DoDAF ビューセット全体のサブセットのみが作成されます。この図は、運用ビュー、システムおよびサービスビュー、技術標準ビューをリンクする情報を示しています。共通のアーキテクチャ データ要素によって駆動される 3 つのビューとその相互関係は、相互運用性やパフォーマンスなどの指標を導き出し、これらの指標の値が運用上の任務とタスクの有効性に与える影響を測定するための基礎となります。[ 1 ]
すべて表示 すべてのビュー（AV）製品は、アーキテクチャ全体を包括的に記述し、アーキテクチャの範囲とコンテキストを定義します。DoDAF V1.5のAV製品は、次のように定義されます。
AV-1 の概要と概要情報 範囲、目的、想定されるユーザー、描写される環境、分析結果（該当する場合） AV-2統合辞書 すべての製品で使用されているすべての用語の定義。
運用面 運用ビュー （OV）製品は、国防総省の任務を遂行するために必要なタスクと活動、運用要素、および情報交換の説明を提供します。OVは、運用ノードと要素、割り当てられたタスクと活動、およびノード間の情報フローをテキストとグラフィックで表現します。OVは、交換される情報の種類、交換の頻度、これらの交換によってサポートされるタスクと活動、および交換の性質を定義します。DoDAF V1.5 OV製品は、次のように定義されます。
OV-1の高度な運用コンセプト図 運用構想に関する高レベルの図解およびテキストによる説明（高レベルの組織、任務、地理的構成、接続性など）。 OV-2運用ノード接続の説明 運用ノード、各ノードで実行される活動、およびノード間の接続性と情報フロー。 OV-3運用情報交換マトリックス ノード間で交換される情報、およびその交換に関連する属性（メディア、品質、量、必要な相互運用性のレベルなど）。 OV-4 組織関係図 組織間の指揮、統制、調整、その他の関係。 OV-5運用活動モデル 活動内容、活動間の関係、入力と出力。さらに、オーバーレイ表示によって、コスト、実行ノード、その他の関連情報を表示することもできます。 OV-6a運用規則モデル 運用活動の順序とタイミングを記述するために使用される3つの製品のうちの1つで、運用を制約するビジネスルールを特定する。 OV-6bの運用状態移行の説明 ビジネスプロセスのイベントに対する反応を特定し、業務活動の順序とタイミングを記述するために使用される3つの製品の1つ。 OV-6c運用イベント追跡の説明 シナリオまたは重要な一連の出来事における行動を追跡し、運用活動の順序とタイミングを記述するために使用される3つの製品の1つ。 OV-7論理データモデル 運用ビューのデータ要件と構造的なビジネスプロセスルールに関する文書。（DoDAF V1.5の場合。DoDAF V2.0のDIV-2に相当。）
システムとサービスビュー システムおよびサービスビュー（SV）は、国防総省の機能を提供または支援するシステム、サービス、および相互接続を記述する一連のグラフィカルおよびテキスト製品です。SV製品は、特定の物理的（地理的）場所にある特定の物理システムに焦点を当てています。SVから運用ビュー（OV）へのアーキテクチャデータ要素間の関係は、組織とその運用を支援するためにシステムが調達され、配備される際に例示できます。DoDAF V1.5のSV製品は次のとおりです。
SV-1 システム/サービスインターフェースの説明 SV-1は、OV-2の運用ノードによって表される組織／人間の役割をサポートするために、システムノードとこれらのノードに常駐するシステムを図示する。SV-1はまた、システム間およびシステムノード間のインターフェースも識別する。 SV-2システム/サービス通信の説明 通信システム、通信リンク、および通信ネットワークに関する関連情報を示します。SV-2は、システムをサポートする通信媒体の種類を文書化し、SV-1で説明されているインターフェースを実装します。したがって、SV-2は、OV-2で示されるニーズラインの側面を自動化するSV-1インターフェースの通信の詳細を示します。 SV-3 システム-システム、サービス-システム、サービス-サービス マトリックス SV-1で説明されているアーキテクチャのインターフェース特性の詳細を、マトリックス形式で示します。 SV-4a/SV-4b システム/サービス機能の説明 SV-4a は、システム機能階層とシステム機能、およびそれらの間のシステムデータフローを文書化します。DoDAF v1.0 の SV-4 は、DoDAF v1.5 では「SV-4a」と指定されています。OV-5 またはビジネスプロセス階層と SV-4a のシステム機能階層の間には相関関係がありますが、必ずしも 1 対 1 のマッピングである必要はありません。そのため、そのマッピングを提供する運用アクティビティからシステム機能へのトレーサビリティ マトリックス (SV-5a) が必要となります。 SV-5a、SV-5b、SV-5c 運用活動からシステム機能、運用活動からシステムおよびサービスへのトレーサビリティマトリックス SV-5aおよびSV-5bの運用活動は、アーキテクチャに適用される運用活動のセットと、そのアーキテクチャに適用されるシステム機能のセットとの間の関係を規定する仕様です。DoDAF v1.0のSV-5およびSV-5の拡張は、DoDAF v1.5ではそれぞれ「SV-5a」および「SV-5b」と指定されています。 SV-6システム/サービスデータ交換マトリックス システム間で交換されるシステムデータの特性を規定します。本製品は、システムに実装されている自動情報交換（OV-3以降）に重点を置いています。口頭指示などの非自動情報交換は、OV製品でのみ記録されます。 SV-7システム/サービス性能パラメータマトリックス システムおよびシステムハードウェア/ソフトウェア項目の定量的特性、それらのインターフェース（インターフェースによって伝送されるシステムデータおよびインターフェースを実装する通信リンクの詳細）、およびそれらの機能を規定します。各システム、インターフェース、またはシステム機能の現在のパフォーマンスパラメータ、および将来の特定の時点における期待または要求されるパフォーマンスパラメータを規定します。パフォーマンスパラメータには、要件を策定し仕様を定義できるシステムのすべての技術的パフォーマンス特性が含まれます。アーキテクチャ定義の初期段階では、パフォーマンスパラメータの完全なセットが不明な場合があるため、この製品はシステムの仕様、設計、開発、テスト、そして場合によっては展開および運用ライフサイクルの各段階を通じて更新されることが想定されます。 SV-8システム/サービス進化の説明 システム、あるいはシステムが組み込まれているアーキテクチャが、長期間にわたってどのように進化していくかを記述した進化計画をまとめたものです。一般的に、タイムライン上のマイルストーンは、進化のタイムラインを正しく理解するために非常に重要です。 SV-9システム/サービス技術予測 標準的な予測手法を用いて対象とした、現在および将来的に必要となる基盤技術を定義します。将来的に必要となる基盤技術とは、現在の技術水準と予想される改善点を踏まえて合理的に予測できる技術を指します。新しい技術は特定の期間に関連付けられるべきであり、その期間はSV-8のマイルストーンで使用される期間と相関関係を持たせることができます。 SV-10a システム/サービス規則モデル アーキテクチャまたはそのシステムが、特定の条件下でどのように動作するかに関する規則を記述する。 SV-10b システム/サービスの状態遷移の説明 システム（またはシステム機能）が様々なイベントに応答して状態を変化させる様子をグラフィカルに表現する方法。この図は基本的に、アーキテクチャ内のシステムが現在の状態に応じて（新しい状態へ移行する動作を行うことで）応答するイベントの集合を表す。各遷移は、イベントとそれに対応する動作を指定する。 SV-10c システム/サービス イベントトレースの説明 特定のシナリオの結果として、参加システム（外部および内部）、システム機能、または人間の役割間で交換されるシステムデータ要素を時系列順に検証します。各イベントトレース図には 、特定のシナリオまたは状況を定義する説明が付随する必要があります。システムおよびサービスビューのSV-10cは、運用ビューで説明されている重要なイベントシーケンスのシステム固有の側面または詳細を反映している場合があります。 SV-11 物理概略図 フレームワーク内で、実際のシステム設計に最も近いアーキテクチャ成果物の1つ。この成果物は、アーキテクチャ内のシステムで使用される様々な種類のシステムデータの構造を定義します。（DoDAF V1.5の場合。DoDAF V2.0のDIV-3に相当します。）
技術標準の見解 技術標準ビュー（TV）製品は、アーキテクチャを規定する技術標準、実装規則、ビジネスルール、および基準を定義します。DoDAF V1.5のTV製品は以下のとおりです。
StdV-1 技術標準プロファイル - 指定されたアーキテクチャに適用される標準の抽出。（DoDAF V1.5 で定義。DoDAF V2.0 で StdV-1 に名称変更。）StdV-2 技術標準予測 - 適切な期間内に、当該アーキテクチャに適用されることが予想される新たな標準規格の説明。（DoDAF V1.5 で定義。DoDAF V2.0 で StdV-2 に名称変更。）
バージョン2.0の視点 DoDAF V2.0の視点の図。[ 11 ] DoDAF V1.5 ビューから DoDAF V2.0 ビューポイントへの進化。[ 12 ] DoDAF V1.5 ビューから DoDAF V2.0 ビューポイントへのマッピング。[ 13 ] DoDAF V2.0では、アーキテクチャビューポイントは、理解を容易にするために整理されたデータで構成されています。ISO規格に準拠するため、必要に応じて用語が「ビュー」から「ビューポイント」に変更されました（例：運用ビューは運用ビューポイントになりました）。
すべての視点（AV） 建築コンテキストの包括的な側面のうち、あらゆる視点に関連するものを説明する。 能力観点（CV） DoDAF V2.0の新機能。能力要件、納入時期、および配備された能力を明確に示します。 データと情報に関する視点（DIV） DoDAF V2.0の新機能。能力および運用要件、システムエンジニアリングプロセス、システムおよびサービスに関するアーキテクチャコンテンツ内のデータ関係と整合構造を明確に示します。 運用上の視点（OV） 機能を支える運用シナリオ、活動、および要件が含まれます。 プロジェクトビューポイント（PV） DoDAF V2.0の新機能。運用要件と能力要件、および実施中の各種プロジェクト間の関係性について説明します。プロジェクトビューポイントでは、国防調達システムプロセスにおける能力要件と運用要件、システムエンジニアリングプロセス、システム設計、およびサービス設計間の依存関係についても詳しく説明します。 サービス視点（SvcV） DoDAF V2.0の新機能。運用機能および能力機能を提供または支援する、実行者、活動、サービス、およびそれらの交換を明確にするソリューションの設計を提示します。 標準規格に関する見解（StdV） 技術標準ビューから名称変更。能力および運用要件、システムエンジニアリングプロセス、システムおよびサービスに適用される、運用、ビジネス、技術、および業界のポリシー、標準、ガイダンス、制約、および予測を明確に示します。 システム視点（SV） レガシーサポート のために、運用機能と能力機能を提供またはサポートするシステム、その構成、相互接続性、コンテキストを明確にするソリューションの設計を明確にします。DoDAF V2.0 では、DoDAF V1.5 からシステムが変更されました。システムは、 コンピュータ ハードウェア とコンピュータ ソフトウェアだけではありません。システムは現在、活動を実行する (実行者のサブタイプであるため) コンポーネント (機械、人間) の集合体という一般的な意味で定義され、相互作用または相互依存しています。これは、相互作用または相互依存する要素を持つ小さな機器から、システムファミリー (FoS) およびシステム オブ システムズ (SoS) まで、あらゆるものになり得ます。システムは、資材 (機器、航空機、船舶など) と人員タイプで構成されていることに注意してください。DoDAF V1.0 および DoDAF V1.5 のアーキテクチャは引き続き使用できます。適切な場合 (通常はポリシーまたは意思決定者によって示されます)、DoDAF V1.0 および V1.5 のアーキテクチャを更新する必要があります。DoDAF V2.0 以前のアーキテクチャを DoDAF V2.0 アーキテクチャと比較する場合、新しいアーキテクチャでは概念の違い (ノードなど) を定義または説明する必要があります。DoDAF V1.5 製品に関しては、DoDAF V2.0 モデルの一部に変換されています。ほとんどの場合、DoDAF V2.0 メタモデルは DoDAF V1.5 のデータ概念をサポートしていますが、注目すべき例外が 1 つあります。ノードです。ノードは複雑な論理概念であり、より具体的な概念で表現されます。
AV-1 の概要と概要情報 プロジェクトのビジョン、目標、目的、計画、活動、イベント、条件、指標、効果（成果）、および成果物について説明します。 AV-2統合辞書 本書全体を通して使用されているすべての用語の定義を含むアーキテクチャデータリポジトリ
CV-1ビジョン 変革に向けた取り組みの全体ビジョンに関連する企業全体の懸念事項に対処し、一連の機能に対する戦略的コンテキストを定義します。CV-1の目的は、アーキテクチャ記述で説明されている機能に対する戦略的コンテキストを提供することです。 CV-2の能力分類 能力の分類体系を捉えます。このモデルは、能力の階層構造を示します。これらの能力は、タイムラインのコンテキストで表示される場合があります。CV-2は、1つ以上のアーキテクチャ全体で参照されるすべての能力を指定します。 CV-3の能力段階的導入 能力の達成計画は、異なる時点または特定の期間に行われる。CV-3は、実行者や場所の解決策に関係なく、活動、条件、望ましい効果、遵守される規則、資源の消費と生産、および対策の観点から能力の段階的達成状況を示す。 CV-4の能力依存性 計画された機能と、機能の論理的なグループ分けの定義との間の依存関係。 CV-5 能力と組織開発のマッピング 能力要件の充足は、特定の能力フェーズにおける計画された能力展開と相互接続を示します。CV-5は、実行者と場所、およびそれらに関連する概念の観点から、そのフェーズにおける計画されたソリューションを示します。 CV-6の能力と運用活動のマッピング 必要とされる能力と、それらの能力が支援する運用活動との間のマッピング。 CV-7の能力とサービスのマッピング 機能と、それらの機能によって実現されるサービスとの間のマッピング。
DIV-1 概念データモデル 必要とされる高レベルのデータ概念とそれらの関係性。 DIV-2 論理データモデル データ要件と構造的なビジネスプロセス（アクティビティ）ルールの文書化。DoDAF V1.5では、これはOV-7に相当した。 DIV-3 物理データモデル 論理データモデルエンティティの物理的な実装形式。例えば、メッセージ形式、ファイル構造、物理スキーマなど。DoDAF V1.5では、これはSV-11であった。 注：これら3つのDIVデータモデルの関係性、および概念データモデル、論理データモデル、物理データモデルの比較については、「論理データモデル」を参照してください。
OV-1の高度な運用コンセプト図 運用コンセプトを概略的に図解または文章で説明したもの。 OV-2運用リソースフローの説明 業務活動間で交換される資源の流れの説明。 OV-3運用リソースフローマトリックス 交換された資源の説明と、交換に関連する属性。 OV-4 組織関係図 組織的背景、役割、または組織間のその他の関係。 OV-5a運用活動分解ツリー 能力と活動（運用活動）は、階層構造で組織化されている。 OV-5b運用活動モデル 能力と活動（運用活動）のコンテキスト、および活動、インプット、アウトプット間の関係。追加データには、コスト、実行者、またはその他の関連情報が含まれる場合があります。 OV-6a運用規則モデル 活動（運用活動）を記述するために使用される3つのモデルのうちの1つ。運用を制約するビジネスルールを特定する。 OV-6b状態遷移の説明 業務活動（アクティビティ）を記述するために用いられる3つのモデルのうちの1つ。ビジネスプロセス（アクティビティ）がイベント（通常は非常に短いアクティビティ）にどのように反応するかを特定する。 OV-6c イベントトレースの説明 活動（運用活動）を記述するために用いられる3つのモデルのうちの1つ。シナリオまたは一連の出来事における行動を追跡する。
PV-1プロジェクトポートフォリオの関係性 これは、組織とプロジェクト間の依存関係、およびプロジェクトポートフォリオを管理するために必要な組織構造について説明するものです。 PV-2プロジェクトのタイムライン プログラムやプロジェクトに関するタイムライン図。主要なマイルストーンと相互依存関係を示す。 PV-3プロジェクトから能力マッピングへ プログラムやプロジェクトを能力にマッピングすることで、特定のプロジェクトやプログラム要素がどのように能力の達成に貢献するかを示す。
SvcV-1 サービスコンテキストの説明 サービス、サービス項目、およびそれらの相互関係を特定すること。 SvcV-2 サービスリソースフローの説明 サービス間で交換されるリソースの流れの説明。 SvcV-3a システムサービスマトリックス 特定のアーキテクチャ記述における、システム間およびサービス間の関係。 SvcV-3b サービス - サービスマトリックス 特定のアーキテクチャ記述におけるサービス間の関係性。これは、関心のある関係性（例えば、サービスタイプのインターフェース、計画されたインターフェースと既存のインターフェースなど）を示すように設計できます。 SvcV-4 サービス機能の説明 サービスによって実行される機能と、サービス機能（アクティビティ）間のサービスデータフロー。 SvcV-5 運用活動とサービス追跡マトリックス サービス（活動）を運用活動（活動）にマッピングする。 SvcV-6 サービスリソースフローマトリックス これは、サービス間で交換されるサービスリソースフロー要素の詳細と、その交換の属性を提供します。 SvcV-7 サービス測定マトリックス 適切な期間におけるサービスモデル要素の測定値（指標）。 SvcV-8 サービス進化の説明 一連のサービスをより効率的なサービス群に移行するための、あるいは既存のサービスを将来の実装へと進化させるための、計画された段階的な手順。 SvcV-9 サービス技術・スキル予測 特定の期間内に利用可能になると予想される、将来のサービス開発に影響を与えるであろう新興技術、ソフトウェア／ハードウェア製品、およびスキル。 SvcV-10a サービスルールモデル サービス機能の説明に用いられる3つのモデルのうちの1つ。システム設計または実装の何らかの側面によってシステム機能に課される制約を特定する。 SvcV-10b サービス状態遷移の説明 サービス機能の説明に用いられる3つのモデルのうちの1つ。イベントに対するサービスの応答を特定する。 SvcV-10c サービス イベントトレースの説明 サービス機能の説明に使用される3つのモデルのうちの1つ。運用上の視点で説明されている重要な一連のイベントについて、サービス固有の詳細を特定する。
StdV-1 規格プロファイル ソリューション要素に適用される規格の一覧。DoDAF V1.5では、これはTV-1に相当した。 StdV-2規格予測 新たな標準規格の説明と、それが既存のソリューション要素に及ぼす潜在的な影響を、一定の期間内に記述する。DoDAF V1.5では、これはTV-2であった。
SV-1システムインターフェースの説明 システム、システム構成要素、およびそれらの相互接続の特定。 SV-2システムリソースフローの説明 システム間で交換されるリソースの流れの説明。 SV-3 システム-システムマトリックス 特定のアーキテクチャ記述におけるシステム間の関係性。これは、関心のある関係性（例えば、システムタイプのインターフェース、計画されたインターフェースと既存のインターフェースなど）を示すように設計できます。 SV-4システム機能説明 システムが実行する機能（活動）と、システム機能（活動）間のシステムデータフロー。 SV-5a運用活動とシステム機能のトレーサビリティマトリックス システム機能（活動）を運用活動（活動）にマッピングする。 SV-5b運用活動とシステム追跡マトリックス システムを機能または運用活動（活動）にマッピングすること。 SV-6システムリソースフローマトリックス システム間で交換されるシステムリソースの流れ要素の詳細と、その交換の属性を提供します。 SV-7システム測定マトリックス 適切な期間におけるシステムモデル要素の測定値（指標）。 SV-8システム進化の説明 一連のシステムをより効率的なシステム群に移行するための、あるいは既存のシステムを将来の実装へと進化させるための、計画された段階的な手順。 SV-9システムズ技術・技能予測 特定の期間内に利用可能になると予想される、将来のシステム開発に影響を与えるであろう新興技術、ソフトウェア／ハードウェア製品、およびスキル。 SV-10aシステムルールモデル システム機能の説明に用いられる3つのモデルのうちの1つ。システム設計または実装の何らかの側面によってシステム機能に課される制約を特定する。 SV-10b システム状態遷移記述 システム機能の説明に用いられる3つのモデルのうちの1つ。システムがイベントに対してどのように反応するかを特定する。 SV-10cシステムイベントトレースの説明 システム機能の説明に用いられる3つのモデルのうちの1つ。運用上の視点で説明されている重要な一連のイベントについて、システム固有の詳細を特定する。
DoDAFを使用した統合アーキテクチャの構築 統合アーキテクチャの図解。[ 1 ] DODAF 2.0 アーキテクトガイド[ 14 ]
DoDAF を使用して統合アーキテクチャを作成し、必要な製品を決定するには、さまざまなアプローチがあります。アプローチは、要件と期待される結果、つまり、結果として得られるアーキテクチャが何に使用されるかによって異なります。たとえば、DoDAF v1.0 では、次の製品が「OV、SV、TV の定義を満たすために必要な最小限の製品セット」としてリストされています。注: DoDAF では OV-1 アーティファクトはコア製品としてリストされていませんが、その開発は強く推奨されています。以下にリストされているアーティファクトの順序は、アーティファクトを開発する推奨順序を示しています。ビュー生成の実際の順序とカスタマイズの可能性は、アプリケーション ドメインと作業の特定のニーズによって決まります。
AV-1 : 概要と概要情報 AV-2 ：統合辞書 OV-1 ：高レベル運用コンセプト図 OV-5 ：運用活動モデル OV-2 ：運用ノード接続の説明 OV-3 ：運用情報交換マトリックス SV-1 ：システムインターフェースの説明 TV-1 ：技術標準プロファイル DoDAFに関する懸念の一つは、これらの製品が対象となるシステムにおける実際の利害関係者の懸念にどれだけ適切に対応しているかという点です。DoDAF製品、少なくとも3つのビューは、 ANSI/IEEE 1471-2000 またはISO/IEC 42010の観点 として捉えることができます。しかし、ANSI/IEEE 1471-2000またはISO/IEC 42010に準拠したアーキテクチャ記述を作成するには、選択した各DoDAF製品に対応する利害関係者とその懸念を明確に特定する必要があります。そうしないと、顧客のいない製品を作ってしまうリスクがあります。
DoDAF V1.5 製品マトリックス[ 15 ] 図「DoDAF V1.5製品マトリックス」は、国防総省統合参謀本部 議長指令（CJCSI）6212.01Eが、ネットワーク対応主要業績指標（NR-KPP）の文脈において、各分析タイプに必要なDoDAF V1.5製品をどのように規定しているかを示しています。
初期能力文書（ICD）。運用ユーザーによる代替案の初期分析、および必要に応じて独立した代替案分析から導き出された、特定の能力ギャップに対する物的解決策の必要性を文書化したものである。能力ギャップは、機能領域、関連する軍事作戦の範囲、望ましい効果、および時間の観点から定義される。 能力開発文書（CDD）。提案されたプログラムを開発するために必要な情報をまとめた文書であり、通常は段階的な調達戦略を用いて作成される。CDDは、軍事的に有用で、兵站的に支援可能で、技術的に成熟した能力を、費用対効果の高い方法で段階的に向上させる方法を概説する。 能力生産文書（CPD）。調達プログラムの単一インクリメントに特有の生産要素を規定する文書。 情報サポート計画 (ISP)。[ 16 ] [ 17 ] テーラード情報支援計画 (TISP)。TISP プロセスの目的は、特定のプログラム (ACAT II 以下) が I&S 認証に必要な要件を作成するための、動的かつ効率的な手段を提供することです。一部のプログラム マネージャーは、ISP の内容をテーラードするよう要求できます (参照 ss)。ASD (NII) / DOD CIO によって OSD 特別関心対象として指定されていないプログラムについては、コンポーネントが、CJCSI 6212 リソース ページからリンクされている TISP 手順で指定されている最低限の要件と、I&S 認証プロセスに関して J-6 が特定した特別なニーズに従って、テーラード プランの詳細について最終決定を行います。
表現 DoDAF製品の表現は、以下のような多くの図解技法を用いて作成できます。
OMG 内では、UMLを使用する際のDoDAF製品の表現を標準化するために、UPDM （Unified Profile for DoDAF and MODAF）という取り組みが行われている。
DoDAFは、生成される成果物の表現方法を一般的に記述していますが、具体的なフォーマットやモデリング手法に関してはかなりの柔軟性を認めています。DoDAFのデスクブックでは、従来のシステムエンジニアリング やデータエンジニアリングの 手法、そしてUMLフォーマットの使用例が示されています。[ 18 ]
グラフィック表現に加えて、通常は国防情報技術ポートフォリオリポジトリ（DITPR）またはその他のアーキテクチャリポジトリにメタデータを提供することが求められます。
DoDAF には、フレームワークを支えるメタモデルがあり、各ビューで使用できるモデリング要素の種類とそれらの間の関係を定義しています。DoDAF バージョン 1.0 から 1.5 では、 IDEF1X (後に UML)で定義され、結果として得られるリレーショナル データベース から派生したXML スキーマを持つ CADMメタモデルが使用されていました。バージョン 2.0 以降、DoDAF は IDEAS Group の 基盤オントロジーを新しいメタモデルの基盤として採用しました。この新しいメタモデルは「DM2」と呼ばれ、「DoDAF メタモデル」の頭文字をとったものです。DM2 の 3 つのレベルはそれぞれ、部門プロセスの特定のビューアにとって重要です。
概念レベル、すなわち概念データモデル（CDM）は、アーキテクチャ記述を作成するための高レベルのデータ構成要素を非技術的な用語で定義し、あらゆるレベルの経営幹部や管理者がアーキテクチャ記述のデータ基盤を理解できるようにします。これは、DoDAF V2.0 DIV-1 ビューポイントで表現されています。 論理データモデル（LDM）は、属性などの技術情報をCDMに追加し、必要に応じて関係性を明確な使用定義に明確化します。DoDAF V2.0 DIV-2ビューポイントで表現されています。 物理交換仕様（PES）は、一般的なデータ型が指定され、実装属性（ソース、日付など）が追加されたLDMで構成され、XSDとして生成されます。DoDAF V2.0 DIV-3ビューポイントで表現されています。[ 6 ] DM2の目的は以下のとおりです。
DoDAFモデル（旧称「製品」）とその6つのコアプロセスにおける使用法に関する記述および議論のための限定語彙を確立し、定義する。 国防総省エンタープライズアーキテクチャ（EA）コミュニティ・オブ・インタレスト（COI）内のアーキテクチャ開発・分析ツールとアーキテクチャデータベース間、およびその他の信頼できるデータソースとの間で、連合型EAデータ交換のセマンティクスとフォーマットを指定する。 EAデータの発見と理解を支援する： DM2情報カテゴリを用いたEAデータの発見 DM2の精密な意味論に言語的追跡可能性（エイリアス）を付加することで、EAデータの理解度を向上させる。 アーキテクチャ記述における意味的精度の基盤を提供し、コアプロセスの意思決定を支援するために、異種アーキテクチャ記述の統合と分析をサポートする。[ 6 ] DM2 は、アーキテクチャ データ要素を定義し、アーキテクチャ記述の統合と連携を可能にします。また、アーキテクチャ記述内および記述間で意味的 (つまり理解) の一貫性の基盤を確立します。このようにして、DM2 は JCA、コンポーネント、連邦政府および連合パートナー間でのアーキテクチャ情報の交換と再利用をサポートし、プロセスとシステムの相互運用性の理解と実装を促進します。DM2 は、プロセス オーナー、意思決定者、アーキテクト、および新しいテクノロジーの継続的なデータ要件を満たすように成熟するにつれて、一貫して理解しやすい方法で公開されるアーキテクチャ データ要件をより完全にサポートするリソースへと進化し、組織の境界を越えてアーキテクチャ データを発見、共有、再利用することの容易性を高めます。[ 6 ]
データ層での情報利用を容易にするため、DoDAFは、グラフィック、表形式、またはテキスト形式によるデータ可視化のためのモデル群を記述しています。これらのビューは、アーキテクチャ記述を作成するためのステークホルダーの要件に関連しています。[ 6 ]
他のアーキテクチャフレームワークとの関係 UPDM （Unified Profile for DoDAF and MODAF ）は 、 米国と英国の防衛アーキテクチャフレームワークにおけるUMLとSysMLの使用を標準化するためのOMGのイニシアチブです。さらに、オーストラリア、カナダ、スウェーデン、英国、米国が支援し、NATOオブザーバーも参加する多国籍組織 IDEASグループは 、エンタープライズアーキテクチャのための正式なオントロジーを開発するイニシアチブを開始しました。
参考文献 1 2 3 4 5 6 7 8 DoD (2007) DoDアーキテクチャフレームワーク バージョン1.5。2007年4月23日 ↑ DoD (2009) DoDアーキテクチャフレームワーク バージョン2.0。2009年5月28日 ↑ (参考: Zachman Framework ) ↑ 「アーキテクチャフレームワークに関するよくある質問」 。 2007年8月7日 取得 。 ↑ 「CJCSM 3170.01C 統合能力統合開発システムの運用」 。2007年5月1日。 1 2 3 4 5 6 「DoDAF メタ モデル (DM2)」 。 ↑ DoDAF 2.0 をリリースする国防総省 CIO メモ ↑ 「DODAF - DODアーキテクチャフレームワークバージョン2.02 - DOD副最高情報責任者」 。 ↑ DoD CIO DoDAF ウェブサイト ↑ 「DODAF 2.0 機能の観点」 。 ↑ DoDAF V2.0の視点の図 ↑ DoDAF V1.5の見解からDoDAF V2.0の見解への進化 ↑ DoDAF V1.5 ビューから DoDAF V2.0 ビューポイントへのマッピング ↑ 「DoDAF V2.0 Volume 2 Architects Guide May 2009」 （PDF） 。 2013年2月17日に オリジナル （PDF）からアーカイブ済み。 2013年1月2日 に取得 。 ↑ DoDAF V1.5 製品マトリックス ↑ 「情報支援計画（DAU ACQuipediaエントリ）」 。 2013年3月9日に オリジナルからアーカイブ済み 。 2013年8月27日 に取得。 ↑ 「E4.A2 ISPアーキテクチャガイダンス」 （PDF） 、 情報技術（IT）および国家安全保障システム（NSS）の相互運用性とサポート性に関する手順 、2004年、83ページ 、 2017年1月24日に オリジナル （PDF）からアーカイブ、 2016 年6月3日に取得 ↑ 「アーカイブされたコピー」 。 2007年9月27日に オリジナル からアーカイブされました 。 2007年8月5日 に取得。 {{cite web}}: CS1 maint: タイトルとしてアーカイブされたコピー (リンク)
さらに読む デニス・E・ウィスノスキー 、ジョセフ・ヴォーゲル著。『Dodaf Wizdom: 米国防総省アーキテクチャフレームワークを用いたエンタープライズアーキテクチャ構築プロジェクトの計画、管理、実行に関する実践ガイド』 。Wizdom Systems, Inc.、2004年。ISBN 1-893990-09-5 。スティーブン・H・ダム博士（2015）。『DoDアーキテクチャフレームワーク2.0：統合実行可能アーキテクチャ開発のためのシステムエンジニアリング適用ガイド』 。CreateSpace Independent Publishing Platform、2015年。ISBN 1-502757-62-1 。
外部リンク DoDAFホームページ（DoD CIO）DODAF 2.02 PDF、2010年8月 第1巻：概要と概念 – マネージャー向けガイド 第2巻：建築データとモデル – 建築家のためのガイド 第3巻：メタモデルオントロジー基盤と物理的交換仕様 – 開発者ガイド 第4巻：ジャーナル - ベストプラクティス DoDAF v1.5、2007年4月23日 第1巻：定義とガイドライン（PDF） 第2巻：製品説明（PDF） 第3巻：アーキテクチャデータ記述（PDF） DoDAF V1、2004年2月9日 アーキテクチャフレームワークフォーラムのDoDAFセクション。他のアーキテクチャフレームワークに関連するDoDAFに関する情報リソース。 DoD CMO ビジネスエンタープライズアーキテクチャ (BEA) 2020年11月2日にWayback Machine に アーカイブされましたDoD BEA 10.0 アーキテクチャ製品ガイド 2008年と2009年の統合EAカンファレンスにおけるDoDAF 2.0に関する2つのプレゼンテーション 国防総省情報エンタープライズアーキテクチャ メタデータレジストリ CJCSI 6212.01シリーズ 欧州宇宙機関アーキテクチャフレームワーク（ESAAF） - 欧州の宇宙システム・オブ・システムズのためのフレームワーク 
