“
介绍企业架构的历史已经好多次了，在《企业架构设计的本质》中介绍过三个重要的框架：Zechman，DoDAF 和 TOGAF。除此以外市面上还有各种各样的书讲架构设计方法和实践，所以我再想是不是可以为架构设计圈做一点有意义的小事，就是把这些架构框架，架构书籍，甚至架构工具都解读一遍。现在使用最多，影响力最大的就是 TOGAF 了，所以我打算就从这个有点重的块头开始，和庖丁解牛一样一点点拆解，所以这个小事有个标签：和坚解构。
”
1 TOGAF 究竟有多重？
大家都说 TOGAF 好重，先说说 TOGAF 究竟有多重吧，我觉得这套东西是真的重，TOGAF 9.1 打印出来有 1249 页，我专门用体脂称称了一下，1.3kg！！！
这么厚的一本书不用想也知道内容一定很多，那这一千两百多页究竟都有点啥东西呢？为了方便大脑的记忆方式，我先做了一个简单的脑图。
我知道很多人看了这个脑图，心里的第一个反应一定是：我 X，这么多概念，有必要这么复杂吗？先别着急，其实这七个部分每一块都在尝试回答一个问题，所以我会用七个问题的视角来解读一下 The Open Group 为什么要划分成这七大块。
2 第一个问题：要弄懂 TOGAF 的先决条件是什么？
依据维特根斯坦的《逻辑哲学论》：人类没有办法理解和思考语言无法表达的东西。所以如果把 TOGAF 看成一套知识体系，想要理解它就必须要理解这套体系的语言，而语言的基本构成就是词语和语法。所以要弄懂 TOGAF 的先决条件就是先明确这套体系中的基本词语和基础语法。
所以 The Open Group 专门用了 80 多页的篇幅来介绍了 TOGOF 整体的知识结构，以及知识结构中的每一个部分会用到哪些基本概念，这个基本概念的定义又是什么。
关于这一部分内容我会在后续的文章中进行详细介绍，今天你只需要简单对下面这个图有个基本的印象就好了，这个图是《TOGAF 文件的结构》，是一张 TOGAF 知识体系的全景图。
3 第二个问题：如果一个组织想要进行体系化的架构设计，它需要做哪些事情，按照什么样的步骤来进行？
第一部分介绍了 TOGAF 的基本概念和全景图，第二部分讲的就是应该按照什么样的步骤才能完成体系化的企业架构设计，这些步骤合在一起称之为 ADM Architecture Development Method。
ADM 是 TOGAF 中最重的压箱石了，一共 9 个阶段，耗费了 250 多页纸张。这一部分的每个阶段都会在后面进行详细的解读，但在这篇文章希望你能够对下面这个 ADM 结构图有一个印象。这个结构图看起来复杂，弄个和一个海星一样，但是其实这就是人类解决复杂问题的一套惯用方法，通过愿景定义目标（阶段 A），然后用各种方法拆解问题（阶段 BCD），拆解完了以后制定实施方案（阶段 EF），最后进行实施和治理（阶段 GH）。
4 第三个问题：如果在使用 ADM 的时候遇到各种特殊情况应该咋办？
第二部分的 ADM 是一套通用的架构开发方法，在实际项目中，在不同的场景应用 ADM 还是需要一定的适配性调整的，比如说安保场景下如何应用 ADM？如果开发 SOA 风格的架构又应该如何应用 ADM。这就需要两个关键概念来才能管理企业架构开发这些复杂的场景了，它们是迭代和层级。TOGAF 第三部分就是讲如何通过迭代和层级的调整，以及在不同的层级重复采用 ADM 来适配实际的场景。
这一部分还介绍了几个 ADM 技巧来帮助架构师更好地解决各种场景下的架构开发：架构原则，利益干系人管理，架构特征模式，业务场景描述，差距分析技巧等等。
5 第四个问题：使用 ADM 的产出物都应该有什么？
执行 ADM 的架构师会有大量的工作输出，所以第四部分就是通过一个架构内容框架为这些输出提供模型，从而使架构师创建的主要工作产物可以被一致地定义和结构化地表达。
下面这个图就是架构内容框架的内容元模型，也就是遵循完整 ADM ，在每个阶段的工作输出应该有什么：
- 预备阶段产出架构原则
- 阶段 A 架构愿景阶段产出业务战略，技术战略，业务原则，架构愿景，利益相关者
- 阶段 B 业务架构阶段产出企业动机，企业组织和企业功能
- 阶段 C 信息系统架构阶段产出数据架构和应用架构
- 阶段 D 技术架构阶段产出平台服务，逻辑技术构件，物理技术构件
- 阶段 E 和 F 机会点解决方案、迁移规划阶段产出工作包和架构合同
- 阶段 G 架构治理阶段产出架构标准，架构指引，架构规格
- 阶段 H 架构变革管理相当于有了新的架构愿景，因此要再走一遍 ADM
6 第五个问题：如何让架构和企业保持统一，并且是连续的？
企业是在断变化的，业务在变化，技术在变化，组织也在变化，如何让 ADM 的产出物能够和企业的这些变化持续保持统一，这就是第五部分要回答的问题。
TOGAF 把这个问题划分成了三个连续统一体：
- 企业连续统一体对企业总体背景环境相关的资产进行分类。
- 架构连续统一体提供一致性的方式来定义架构中的一般规则，表达方式和关系。
- 解决方案连续统一体提供一致性的方式来定义解决方案的实施过程。
这一部分知识体系比较抽象，所以暂时只需要知晓有这三个层级的连续统一体就够了，后面在解读这部分的时候会用更具体的案例进行解释。
7 第六个问题：如何实现应用的可移植性，如何实现软件系统的互操作性？
前面企业连续统一体讲的是 TOGAF 通过一些工具和方法让架构能够持续地和企业发展保持一致，但这种保持一致的代价是昂贵的。所以在第六部分 TOGAF 给出了两个模型，通过这个两个模型来实现应用的可移植性和互用性，这样就可以降低由于企业变化导致架构变化的高昂成本。
-
第一个模型是技术参考模型 TRM（Technical Reference Model），这个模型旨在强调两个公共架构的目的：
- 1.通过应用平台界面实现的应用可移植性。
- 2.通过通信基础设施界面实现的系统互用性。
- 第二个模型是集成的信息基础设施参考模型，这个模型是 TRM 的子集，用于实现无边界信息流的通信基础设施。翻译一下，就是如果要打破信息孤岛，那么应该如何进行软件的层面的技术架构设计。
8 第七个问题：企业如何像建立业务能力一样建立架构能力？
前面五个部分看起来东西很多，概念也很复杂，但实际上都是在围绕着 ADM 架构开发方法这个东西介绍 ADM 是什么，ADM 怎么用，ADM 的产出物有什么，企业如何用 ADM 才能保持持续统一。但这些东西都是在讲事情是怎么做，最后做这些事情的还是组织，还是组织里面的人，所以第七部分就是讲应该如何建立企业架构能力。
下面是企业架构能力的整体结构图，治理机构是架构委员会，它负责制定架构合规性规范，架构契约是开发团队和治理团队之间的联合协议。
最重要的是需要基于架构能力框架建立一个有架构技能的资源池，这个资源池是一个企业进行架构开发和架构治理的核心力量。
9 最后一个问题：TOGAF 为啥这么复杂？
我估计读到这里你和我的感觉一样，没有做详细的展开，光只是速览一下 TOGAF 整体的全景就觉得这东西够复杂的。为啥要弄得这么复杂呢？我猜测可能有两方面的原因，一个原因是这套体系本来是一点点堆积上来的，所以就越堆积越庞大了；另外一个原因是软件构建本来就很抽象，而架构概念又是抽象上的抽象，叠加抽象的结果就是没有合适的上下文语境从概念理解概念很困难。
所以我会在后面的解读中尝试给出一个概念，一个方法的上下文语境，最好能够是一个例子。我希望最终带给你的帮助不是如何使用 TOGAF 的这些概念和方法进行企业架构设计，这套东西真的太重了，挥舞起来容易伤到自己。而是能够透过这些概念和方法学习 TOGAF 的思考过程，并能把这些思考过程整合到自己的底层架构能力中。
