1.6　DoDAF

接下来我们介绍美国国防部架构框架（Department of Defensive Architecture Framework，DoDAF）。美国国防部热衷于研究企业架构和软件工程，而且起步很早，大约在20世纪70年代就开始了C4ISR（Command、Control、Communication、Computer、Intelligence、Surveillance、Reconnaissance）计划。1986年，美国国防部开始了信息管理技术架构框架（Technical Architecture Framework of Information Management，TAFIM）的研究，并在1991年发布1.0版本。TAFIM后来发展出两个分支，一个是大名鼎鼎的TOGAF，另一个是C4ISR AF（1996年发布1.0版本，1997年发布2.0版本），也就是DoDAF的前身。

DoDAF 1.0发布于2003年，这时企业架构理论已经进入成熟期，DoDAF不仅吸收了Zachman框架和TOGAF的长处，继承了美国国防部自己的长期积累，也对接了来自联邦政府的FEA，理念成熟、视角独特、体系灵活。DoDAF在2007年发布了1.5版本，2009年发布了2.0版本，2.0版本在1.5版本的基础上改动很大，框架更加清晰了。

DoDAF是一个很独特的架构框架，它将架构分为企业架构和解决方案架构两层。为符合现有翻译资料的习惯，笔者沿用“体系结构”一词代替其他框架中提到的“架构”一词。

DoDAF认为企业体系结构是一种基础的战略信息资产，规定了使命和执行使命所需的信息和技术，以及为适应使命变化而需要采用新技术的转型过程，包括基线体系结构、目标体系结构、分步实施的规划。企业体系结构资产应该像其他企业资产一样被管理，并通过管理成为企业用于正规决策程序的一个关键部分。只有创建的体系结构描述能够反映现实（如基线）或计划的变化、成长（如期望的目标）时，才能达到上述的接受程度。解决方案体系结构负责描述一个解决问题方案所有要素的关系，可用于更新或扩展一种或一种以上的其他体系结构。

DoDAF的定义很抽象，在实操上可以认为，DoDAF的体系结构开发过程的核心实际上是收集并确认具体设计对象领域需要的所有信息、要素，明确信息、要素之间的关系，以此指导系统开发，相当于建立系统的元模型。DoDAF将数据分成若干数据组，数据分组之间的高阶关系如图1-13所示。

在这个高阶元模型之下，还包括具体数据分组内部的元模型，比如活动的元模型，如图1-14所示。

图1-13　DoDAF数信视点元模型

数据的提炼是DoDAF体系结构开发的核心，但仅靠数据描述当然不足以构成对具体工作的指导，所以，完整的DoDAF体系结构开发是一个以数据为核心，应用多种视点（具体的模型、图表是视图，将描述流程、系统、服务、标准的多个视图进行有机组合称为视点）进行综合描述的架构设计过程，这一点继承了Zachman框架的思想。

DoDAF与TOGAF的不同之处在于，TOGAF提出了4种架构分类，但是在DoDAF中没有这些概念，因为DoDAF不提供对系统设计的全面建议，只是提供了对数据概念和要素关系的约束，以保证企业级的概念一致性，为跨系统的互操作提供基础。

图1-14　DoDAF活动元模型

DoDAF确定了8种视点作为体系结构的开发指引，共涉及52种模型，但并不强制使用这些模型，而是为用户提供使用指引。8种视点如图1-15所示。

图1-15　DoDAF的8种视点

上文介绍的元模型对8个视点中包含的元素基本都有覆盖，而体系结构开发过程中形成的数据模型都属于数信（数据和信息）视点，其他视点中的模型多为各种文档、表格、图形等形式，任一具体的系统设计都可以归结为若干视图的组合。要注意的是，2.0版本中的系统一词不仅指计算机软硬件，而是扩展为通常意义上的各部分之间的聚合，包括机器和人。

所以，通过DoDAF方法开发出来的体系结构，就是一套以数据的统一定义为核心的体系结构描述。DoDAF 2.0的首要目标是对高效决策所需要的数据进行采集、存储和维护，其次才是支持决策。这与其对自身的定位也是一致的：为了满足国防部特定的业务和作战需求，DoDAF框架定义了一种表示企业结构的方式，这种方式使得干系人在关注企业内特定利益相关领域的同时也能保持对全局的把握。DoDAF提供了从下层复杂事物中抽取基本信息的手段，并提供了一致和连续的信息表达方式，正因如此，我们不难理解为什么美国国防部2020年数据战略中有那么多DoDAF的影子。

这种目标也决定了DoDAF与其他框架相比的一大特点：概念的清晰性。无论是Zachman框架还是TOGAF，对概念的定义都很模糊，甚至是举例性的，但是DoDAF是以数据为核心的，所以它对于术语、概念、关系都尽可能给出了明确的定义，对数据开发的要求也相对丰富，作为一个框架级别的方法论，其可操作性是比较强的，其参考示例、参考模型对实践的指导性也更强。DoDAF的开发过程被称为“6步法”，如图1-16所示。

图1-16　“6步法”示意图

“6步法”中的架构师工作方法如图1-17所示。

图1-17　“6步法”中的架构师工作方法示意图

DoDAF非常注重元模型的应用和管理，不同层级的元模型组合基本上约定了架构师的解域空间，不断丰富和成熟的元模型也是保证架构师产出质量的基础，这一点值得其他工程方法借鉴。在数据提炼方面，DoDAF并没有指定专门的数据建模方法，因此建议遵循“三范式”要求。

软件开发的核心就是行为和数据，而行为除了依赖客户需求外，也应接受元模型的约束。行为也是可以被数据描述的，从这一角度来讲，软件开发也可以被认为是数据和数据关系的复现。数据关系包括静态关系和动态关系，行为就是一种动态关系，服务治理也是一种基于对服务的数据描述的管理。

DoDAF对“结构化”给出了一个非规定性的说明，如图1-18所示。

图1-18　“结构化”示意图

虽然文档中没有具体说明，但是从示意图中可以看出，结构化至少要包含对输入、输出、角色、活动、规则、度量的明确定义。

对于DoDAF而言，架构师必须以一种有意义的方式将体系结构信息传递给流程主管和其他干系人，否则企业体系结构学科很快就会夭折。许多现有的体系结构方法对于“如何组织体系结构信息”是有价值的，但是对于“如何将这些信息传递给更广泛的利益相关者”就不那么有价值了，体系结构信息需要以清晰、可理解、方便决策的方式展现出来。

尽管架构设计是面向数据的，但是也不能事无巨细，将所有细节都包含在开发过程中，在实际操作过程中需要尽量控制自己。DoDAF在这方面坚持适用原则，与特定项目或者使命目标一致，不会在体系结构描述中涉及所有细节，各层级体系结构的描述和用法也可以不同。

DoDAF的优点很多，但缺点也比较明显。DoDAF是美国国防部根据自己的架构理念量身定做的，未曾听说其扩展到其他领域。此外，由于不涉及具体设计，可能对很多企业而言，DoDAF并不能解决实际问题。但是，DoDAF中的一些理念，例如对元模型的关注和应用，很值得其他方法论借鉴。