对于大型系统利用 DoDAF
规格的架构规划，其实均有个共同的特点，也就是有多个节点(Node)、多个信息系统(Information System)
何表达表达多个节点之间的关连性、如何表达多个信息系统之间的互动。
Operation View，也会利用如 UML 的循序图(sequence diagram)，如 OV6，来表达节点之间的动态互动情形。
而 UML 循序图一般是被用来表达软件系统内部，参与对象之间的互动合作关系。
其实这隐含什么意思呢？ 很简单的道理！ 在 Operation View，也可以运用对象导向分析的手法，与 System View 所不同的只有：一个是把 Node 当物件；另一个是把 System 当物件；但是相同的是：两者均用对象导向分析设计的思维来作塑模(Modeling)。
对我而言，在抓这类大型系统的架构时，首要就是要先能界定出系统的整体框架。当把某一个设计的目标框架，界定为一个系统时，就会分
出 "外" 与 "内"，而两者的分析手法与看待系统的角度就会不一样了。 "外" 重视的是 "用"，所以会观察系统所提供的服务，而服务就会衍生出，系统应该提供什么
"接口(interface"
让外部的参与者来用；再来
"内" 重视的就是系统的组成元素，这就是属于结构分析的角度。结构分析观察的两个重点是，一个为静态的结构关系、另一个就是，在动态为了完成某一个 "用" 的功能服务时，会有哪些元素的参与、它们彼此之间又是如何传递讯息的。
最终，你就会发现到，到底是如何 "界定" 某一个框架为一个系统，会是架构师最大的课题与其必备的素养了。
OV-1 的精要(Essential)为何呢？
利用可视化的视图协助高阶决策者(如指挥官)，以 “鸟瞰” 的方式来看出系统的全貌 (包括系统的外与内部观点)。
- 开发的系统为何？ (联合作战指挥系统)
- 谁触发(Trigger)系统作业？ (通信雷达侦测系统侦测到敌空降部队与敌军机的来袭)
- 系统的外部支持为何？
(UDA, 台美联防舰队) - 系统的内部组成元素？
(各节点，包括直属部队、陆、空军作战指挥中心、后勤中心等)
再来，我们就会利用战情演练与情境描述等，来作为系统的架构规划，以及持续验证系统的作业。
工具没啥好介绍的，况且席间诸多长官与教授们问最多的问题就是有没有 "自动化" 的机制，可以从某一个 View 的设计图，自动转化到另外一个
View 的设计图。这个... 我总觉得他们研究的方向会不会有问题？ 我只能反问：1. 如果规则明确，例如
OV-2(作业节点连结) 转 OV-5(作业活动流程)有很明确转换规格的话，那么工具当然可以支持。 (可想而知的答案是，当然没有那种必然明确的规则) 2.能不能转到程序代码？ 这些我都觉得都不是问题耶，前提是有没有那种确定的规则？
要能懂得设计符合 DoDAF 架构规格的系统，要具备的是软件设计基础功夫的底子；要能有整体性的架构观，要知道什么时候该封装、什么时候该打开，分析系统的内部；要懂得如何把一个看
起来好像很大的系统(关于系统的定义，可不一定指软件系统，在这种大格局下，包括企业单位，都可能是一个系统)，该如何大题小作；又懂得那个时候该具焦在 某一个焦点上，然后小题大作。 这一种整体性的设计思维，正是架构规划与设计个中的窍门之所在。
AV-1
— 架构总览文件报告。
OV-4
— 组织关系图。
OV-1
— 高阶层次概念视图。
OV-5
— 企业层级使用案例图。
— 作业活动图。
OV-2
— 作业节点连结设计图。
OV-6
— 作业活动状态图。
— 作业活动循序图。
OV-3
— 作业信息交换矩阵表
SV-1
— 系统接口概观设计图。
SV-4
— 系统使用案例图。
— 系统循序图。
SV-2
— 系统接口规格设计图。
SV-5
— 系统与作业活动关系矩阵。
— 服务与作业活图关系矩阵。
SV-3
— 系统与系统的关系矩阵。
— 系统与服务的关系矩阵。