摘要：DODAF（Department of Defense Architecture Framework，国防部架构框架）是美国国防部制定的一套用于指导信息系统体系结构开发、描述和集成的标准框架。基于DoDAF，美国防部制定了一系列的体系架构标准，为各个领域的复杂系统的理解、比较、集成和互操作奠定了架构基础，保证各个异构系统具备相互集成和互操作的架构可行性。当然，DoDAF是美军根据自身情况设计制定的，并不一定适应我们的装备研制或民用领域。我们需要结合行业和业务特点，对DoDAF进行裁剪和优化，以制定更符合业务实际的行业体系架构设计指导文件。
国防部体系架构框架（Department of Defence Architecture Framework, DoDAF）是美国国防部发布的，用于指导体系架构开发的顶层的，全面体系框架和概念模型，并规定了架构师和各级管理者应该如何规范的收集和管理分散在国防部、联合能力域（Joint Capability Areas, JCA）、部门或项目中的数据，以实现信息的有效共享，提高关键决策能力。
当前，DODAF已成为国际上公认的复杂信息系统体系结构设计的重要参考框架之一。它不仅在美国国防领域内得到深入应用，还对其他国家的军事和民用信息系统建设产生了深远影响。DODAF提供了一套全面的、通用的方法论和工具集，用于指导系统体系结构的规划、设计、实现和评估。
DODAF的核心思想是通过定义一系列的视图和模型，来描述系统的各个方面，包括作战视图、系统视图、技术视图等。这些视点和模型从不同的角度和层面出发，共同构成了对系统体系结构的全面描述。同时，DODAF还强调了数据在体系结构描述中的核心地位，通过元模型和数据字典等手段，确保了体系结构描述的一致性和可重用性。
在最新版本中（如DoDAF 2.02版），DODAF进一步强化了数据驱动的设计思想，并增加了对新兴技术（如云计算、大数据等）的支持。此外，DODAF还与其他国际标准和框架（如TOGAF、FEAF等）进行了融合和互补，以更好地适应复杂多变的信息化环境。
MODAF（英国国防部体系结构框架）、NAF（北约体系结构框架）、DNDAF（加拿大国防部体系结构框架）和ADOAF（澳大利亚国防部体系结构框架）都是基于DODAF发展而来的，用于指导各自国家或组织内部体系结构开发的框架。以下是北约其他国家的国防部体系架构框架概述：
1.MODAF是英国国防部的体系结构框架，它是基于DODAF发展而来，但更侧重于支持英国特定的国防需求和操作。MODAF提供了一套丰富的视点和视图，用于描述和分析军事体系结构。
2.NAF是北约体系结构框架，是基于DoDAF的原则和概念发展而来的，但它经过定制以满足北约特定的需求和操作。它旨在支持北约成员国之间的互操作性，并提供一种共同的语言和方法来描述和分析军事体系结构。
3.DNDAF 是加拿大国防部的体系结构框架，它也基于DODAF，但针对加拿大的国防需求进行了定制。
4.ADOAF是澳大利亚国防部的体系结构框架，它同样是基于DODAF，以支持澳大利亚的国防体系结构开发。
如下图所示，DoDAF项目从1996年开始推行，目前已经发布2.0版本。
DoDAF 2.0的主要构想包括：
1.提供一系列的顶层的体系结构概念、指南、构建步骤和最佳实践，以促进体系结构开发，并支持指挥、管理和能力域的决策流程。
2.支持组织组织向网络中心化的方向发展，支持组织实现面向服务的架构的开发。
3.成功将特定的体系架构产品转换成体系结构数据，并将其作为制定重要决策所需的信息。由于DoDAF模型和国防部各级决策者共同使用“通用视图”，DoDAF架构师可以实现从国防部、联合能力域、各个部门和项目中导出信息的可视化，实现开发视图更具有灵活性，更加符合团队文化和习惯。
4.提供方法和推荐技术，使得架构师或其他开发者可以借此来创建体系架构，满足和支持组织的管理和决策需求。
1.DoDAF元模型
DoDAF 2.0以数据为中心，并引入了国防部体系架构框架元模型（DoDAF Meta-Model, DM2）的概念。DM2由概念数据模型（Conceptual Data Model, CDM）、逻辑数据模型（Logical Data Model, LDM）和物理交换规范（Physical Exchange Specification, PES）组成，是构成国防部体系结构框架整体的重要组成部分。
DM2定义了体系结构数据元素，为体系结构描述内部或之间的语义一致性建立了基础，使体系结构描述可以集成与形成联邦。通过这种方式，DM2使得国防部、JCA、部门和项目之间的体系结构数据可以复用和交换，促进了业务流程和系统的互操作性。
DM2系统可以满足业务流程主管、各级决策者、架构师和其他开发者在新技术发展中的数据需求，全面支持体系结构的数据和数据需求，可以以前后一致、可理解的方式发布，且更容易地跨越组织边界，进行检索、共享和复用，大大提升了数据对关键决策的支撑能力。可以说, DM2和DoDAF保障了架构师工作的下限。
2.DoDAF中的八大视图
元模型定义数据，视图呈现数据。具体来说，元模型为架构开发提供了基础的概念结构，而视图则是这些概念在特定上下文中的应用和展示。DoDAF通过八个主要视图来描述体系架构。
（1）全景视图（All View, AV）
全景视图的子视图包括
a. AV-1-体系架构描述：提供架构的总体概述，描述项目背景、范围、假设、目标和利益相关者信息。
b. AV-2-一体化字典：提供架构中使用的所有术语、定义、缩写和参考文献的列表，以确保架构描述的一致性。
全景视图的内涵与作用为：
全景视图提供了架构背景和基本信息，确保架构的理解一致性。AV-1 概述了架构的范围和目的，AV-2 则是架构的“字典”，帮助定义架构中使用的术语和数据。全景视图是 DoDAF 其他视图的基础，确保架构在多个利益相关者之间具有一致的理解。
（2）能力视图（Capability Viewpoint, CV）
能力视图的子视图包括：
a. CV-1-能力视图描述：描述了希望实现的能力，以及这些能力如何支持组织的总体目标。
b. CV-2-能力层次结构：展示能力之间的层次关系，显示各个能力如何分解为子能力。
c. CV-3-能力阶段图：表示不同能力在时间上的交付情况及其与任务的关联。
d. CV-4-能力依赖关系图：显示能力与能力之间的依赖关系。
e. CV-5-能力到组织映射：描述能力与负责提供这些能力的组织实体之间的映射关系。
f. CV-6-能力到系统映射：显示系统或服务如何实现特定的能力。
能力视图的内涵与作用为：
能力视图专注于描述体系架构的能力需求，展示实现这些能力的阶段性目标。它帮助组织理解哪些能力需要在何时具备，并与组织目标对齐。能力视图对于规划和管理大型系统的能力演化和提升至关重要。
3.数据和信息视图（Data and Information Viewpoint, DIV）
数据与信息视图的子视图包括：
a. DIV-1-概念数据模型：描述系统中关键数据实体及其关系，帮助理解需要处理的核心信息。
b. DIV-2-逻辑数据模型：描述详细的数据结构，包括数据实体、属性和它们之间的关系，但不涉及具体实施细节。
c. DIV-3-物理数据模型：展示数据的具体实现方式，包括数据存储、数据流、数据库设计等物理结构。
数据与信息视图的内涵与作用为：
数据和信息视图侧重于描述架构中的数据和信息流，帮助理解系统如何生成、管理、存储和交换数据。它有助于确保系统中的数据一致性和准确性，支持信息的共享和集成。
4.作战视图（Operational Viewpoint, OV）
作战视图的子视图包括：
a. OV-1-作战概念图：高层次地展示主要作战任务、操作节点及信息流。
b. OV-2-作战资源流图：描绘作战节点之间的资源和信息流，展示作战实体之间的交互。
c. OV-3-作战信息交换矩阵：定义各作战节点之间的具体信息交换需求。
d. OV-4-作战组织关系图：展示参与作战的组织及其相互关系。
e. OV-5a-活动模型：描述执行作战相关任务的活动及其输入、输出和控制机制。
f. OV-5b-作战活动模式：以更加结构化的方式展示作战活动及其关联。
g. OV-6a-作战规则模型：描述作战活动的业务规则。
h. OV-6b-作战状态转换图：描述作战活动状态的变化和转换条件。
i. OV-6c-作战事件追踪图：显示作战过程中事件的时间顺序和相互依赖关系。
j. OV-7-作战信息模型：描述作战活动中使用的信息和数据。
作战视图内涵与作用为：
作战视图描述了作战任务和操作需求，定义了系统如何在作战环境中运作。它帮助架构师理解作战活动中的关键任务、任务之间的依赖关系、信息流和资源流，从而确保系统设计能够满足作战需求。
5.项目视图（Project Viewpoint, PV）
项目视图的子视图包括：
a. PV-1-项目时间表：显示项目的实施时间表，包括各个项目的关键里程碑和交付物。
b. PV-2-项目关系图：展示项目之间的依赖关系、项目的资源分配情况以及与能力实现的关联。
c. PV-3-能力到项目映射：显示项目如何支持能力的开发和交付。
项目视图的内涵与作用为：
项目视图侧重于项目管理方面，描述如何通过项目来实现体系架构中的能力。它帮助理解项目之间的依赖关系以及如何通过项目时间表管理能力交付。项目视图对规划、管理、跟踪项目的进度和资源配置起到了关键作用。
6.服务视图（Services Viewpoint, SvcV）
服务视图的子视图包括：
a. SvcV-1-服务接口描述：描述服务的接口，定义不同服务之间的交互及其提供的功能。
b. SvcV-2-服务资源流图：展示服务之间的资源、信息流动情况。
c. SvcV-3-服务信息交换矩阵：定义服务之间的信息交换需求。
d. SvcV-4-服务功能描述：描述服务提供的功能及其功能分解。
e. SvcV-5-服务能力实现图：显示服务如何支持能力的实现和交付。
f. SvcV-6-服务状态转换图：说明服务在不同状态间的转变和条件。
g. SvcV-7-服务事件追踪图：描述服务间事件的时序和依赖。
h. SvcV-8-服务性能参数图：显示服务的性能属性和约束条件。
服务视图的内涵与作用为：
服务视图展示了系统中的服务组件及其交互，重点描述了服务的功能、接口和信息流。它有助于理解服务如何相互协作和支撑架构中的能力，特别用于 SOA（面向服务的架构）或云计算环境。
7.标准视图（Standards Viewpoint, StdV）
标准视图的子视图包括：
a. StdV-1-标准概述：描述应用于体系架构的标准，包括技术、操作、管理等方面的标准。
b. StdV-2-标准预测：描述未来标准的演进趋势，以及这些标准如何影响体系架构的开发和生命周期管理。
标准视图的内涵与作用为：
标准视图定义了体系架构中使用的标准，确保系统设计符合国防部和相关组织的技术和操作要求。它有助于确保系统的互操作性、可扩展性和合规性，并为未来的技术升级提供指导。
8.系统视图（Systems Viewpoint, SV）
系统视图的子视图包括：
a. SV-1-系统接口描述：描述系统组件及其接口，展示系统之间的交互。
b. SV-2-系统资源流图：展示系统之间的资源和信息流动情况。
c. SV-3-系统信息交换矩阵：定义系统之间的信息交换需求。
d. SV-4-系统功能描述：描述系统功能及其分解，说明系统如何执行任务。
e. SV-5a-系统功能到作战活动映射：展示系统功能如何支持作战活动。
f. SV-5b-系统功能到能力映射：展示系统功能如何支持能力实现。
g. SV-6-系统状态转换图：描述系统状态的变化和条件。
h. SV-7-系统性能参数图：描述系统的性能要求和约束条件。
i. SV-8-系统事件追踪图：描述系统事件的时间顺序和依赖关系。
系统视图的内涵与作用为：
系统视图侧重于描述系统组件的功能、接口、性能和交互，帮助理解系统如何支持作战任务和能力。系统视图有助于确保系统设计的功能性、可操作性和互操作性。
如何根据庞大的体系结构数据和视图规范来构建体系架构呢？答案是通过模型来收集体系架构数据，组织体系架构数据，并规范体系架构的表达。
DoDAF提供了为各个视图提供了相应的模型，总计52个，如下所示。
上述的各个模型，可以作为体系结构数据收集和组织的模版，辅助架构师或其他开发人员进行体系架构设计开发。架构师依据一定的流程和顺序（一般是下文的6步开发法），参照各个视图下的模型，完成体系架构数据收集和组织后，就得到了特定的体系架构的数据集合。
将这些数据集合，以上述各大视图的方式可视化展现出来，就形成了体系结构视图。各方以体系架构视图，作为体系结构的唯一表达，就实现了数据跨组织的互理解和复用，并以此完成对体系架构的一致认知。至此，也就完成了体系结构的搭建。当然，体系结构视图不限于上述的形式，用户可以根据组织需要自定义适用的视图形式，对此，DoDAF 2.0并无任何限制。
在DoDAF的架构内，进行体系架构开发的过程，是一个以数据为中心的过程，而非以产品为中心的过程（在DoDAF中，产品是对体系架构中信息的图形化、表格化或文字描述的表现形式。这些产品用来表示各种视图（Viewpoints）中的内容，帮助架构师和利益相关者更好地理解系统的需求、设计和执行情况。每个 视图（Viewpoint） 都包含若干子视图（Views），而每个子视图的输出就是一个 产品）。这种以数据为中心的过程和方法确保能获取基本数据关系，以支持各种各样的分析任务，并确保了体系架构描述中各个视图的协调一致。体系结构开发过程中创建的各个视图提供了对底层体系结构数据的形象表达，传递着来自体系结构描述的，特定用户群体群活决策者所需的有用信息。
如图所示，DoDAF体系架构六步开发过程为：
1.明确体系结构的用途
在开发架构之前，明确体系结果的用途的目标是回答 “为什么要开发这个架构？”，即架构的预期用途和目标是什么。架构目的是支持具体的决策点，例如能力分析、投资规划、系统设计等。
明确架构的用途有助于确保架构开发工作的方向不会偏离需求和目标。通过确定架构的具体用途，架构师可以定义架构的范围和内容，从而确保架构产品能够支持组织的决策需求。
明确体系架构的用途的关键活动包括：
a. 与利益相关者协商，明确他们的需求。
b. 确定架构将支持的主要决策点，如能力评估、技术选择或投资优先级等。
c. 明确架构的目标（如支持作战、资源分配、系统集成等）。
d. 定义架构预期的寿命周期，确定它将支持的长期或短期任务。
2.确定体系结构的范围
确定架构的范围是为了明确架构开发的边界。这一步定义了架构要覆盖的内容和深度，包括时间范围、地理范围、组织范围、技术范围等。此步骤还包括识别相关的任务、活动、系统、服务等。
通过确定架构的范围，架构师可以避免过度设计和不必要的扩展，确保架构开发工作的重点集中在满足需求的关键领域。明确的范围定义有助于架构师和利益相关者在架构开发过程中保持一致的理解。
确定体系结构的范围关键活动包括：
a. 明确架构的时间跨度（如当前状态、中期目标、未来愿景）。
b. 确定架构的地理范围（如全球、特定地区或作战区域）。
c. 定义架构涉及的组织/机构，以及它们在架构中的角色。
d. 制定技术和作战任务的具体范围，确保涵盖所有关键活动和系统。
3.确定开发体系结构所需数据
视图是 DoDAF 提供的标准化输出，用于描述架构的不同方面，例如作战视图、系统视图、服务视图等，数据则是生成这些视图所需的信息。
确定产品和数据的需求有助于架构师理解开发过程中需要收集和生成的关键信息，从而确保架构能够满足决策需求。通过定义产品和数据需求，架构师可以规划数据收集工作，并确保架构的完整性。
确定开发体系结构所需数据的关键活动包括：
a. 确定要开发的视图（如作战视图、系统视图、能力视图等）。
b. 定义支持架构产品生成所需的数据类型（如作战活动、系统接口、能力需求等）。
c. 识别数据的来源和数据收集方式，确保数据的可用性和适用性。
d. 确保数据符合 DoDAF 的标准化格式和要求。
4.采集、组织、关联和存储体系结构数据
在这一步中，架构师开始实际的数据收集工作。根据前一步确定的产品和数据需求，架构师收集所需的架构数据，并将其组织、存储在适当的系统中，以便在后续架构开发过程中使用。
数据收集和组织是架构开发的基础。通过收集和存储数据，确保架构开发有足够的信息支持决策分析。数据的有效性、质量和一致性直接影响到架构产品的准确性和可用性。
采集、组织、关联和存储体系结构数据的关键活动包括：
a. 收集来自多个来源的数据，如现有系统、文档、数据库、利益相关者访谈等。
b. 将数据组织成标准化的格式，以便后续开发架构产品（确保数据的一致性、准确性、完整性）。
c. 确保数据易于存储和检索，便于架构开发和分析。
d. 确保数据的安全性和保密性，符合相关法规要求。
5. 为实现体系结构目标进行各种分析
对包含了所需全部数据的体系结构进行静态、动态和实验分析，以确定数据的有效性，并根据既定的体系架构的用途和目标，对不满足要求的数据和视图进行修正。
通过分析和修正所需数据，确保收集和存储的数据能够正确支撑体系结构的构建，从而为发布体系结构视图奠定数据基础。
为实现体系结构目标进行各种分析的关键活动包括：
a. 缺陷分析
b. 能力分析
c. 互操作性评估
d. 业务流程分析
e. 测试体系结构的完整性、准确性和充分性等
6. 根据决策者的需要进行成果展示
在这一步中，架构师基于收集到的数据，生成所需的架构产品。这些产品包括图形、表格和文字描述，展示了体系架构的不同方面，如作战活动、系统交互、信息流和技术标准等。
开发架构产品是将数据转化为实际可用输出的过程。这些产品通过可视化信息、结构化描述等方式，帮助利益相关者理解体系架构的各个方面，并为决策提供依据。
根据决策者的需要进行成果展示的关键活动包括：
a. 使用收集到的数据，开发架构所需的各种视图和产品。
b. 确保架构产品的准确性和一致性，符合 DoDAF 标准。
c. 根据架构的用途和范围，开发适当的架构产品，支持不同类型的分析（如能力分析、系统集成、技术评估等）。
d. 验证架构产品，确保它们能够有效支持预期的决策需求。