解构 TOGAF-2-EA的野心

“

介绍企业架构的历史已经好多次了，在《企业架构设计的本质》中介绍过三个重要的框架：Zechman，DoDAF 和 TOGAF。除此以外市面上还有各种各样的书讲架构设计方法和实践，所以想是不是可以为架构设计圈做一点有意义的小事，就是把这些架构框架，架构书籍，甚至架构工具都解读一遍。现在使用最多，影响力最大的就是 TOGAF 了，所以我打算就从这个有点重的块头开始，和庖丁解牛一样一点点拆解，所以这个小事有个标签：和坚解构。

”

前一篇文章《解构 TOGAF-1-整体全景图 》中反复提到了 TOGAF 很重，足足有 1.3kg。那为什么 The Open Group 要把 TOGAF 这套方法论弄的这么庞大、复杂、厚重呢？简单一点，容易理解一点不好吗？

刚好前几天在付晓岩老师的读者群里也在讨论关于方法论的问题， 有的人认为方法论是重要的，做任何事情之前最好有方法论的指引；也也的人认为现在很多人过于追崇方法论了，遇到问题就想用看到的方法论往上硬套，很多方法论都比较复杂，结果很多时候套上去别人不理解也没法解释清楚，然后把原因归结为对方思维层次不够，最后问题不但没有解决反而因为引入方法论变的更混乱了。

TOGAF 就很容易产生这样的担忧，这么重的方法论，那么多的概念，在理解方法论的过程中必然会产生分歧，最后整个组织会不会因为引入 TOGAF ，不但没有解决反而带来了更多新的问题呢？

要解决这个担忧，就首先要弄清楚 TOGAF 认为 EA 要解决的问题究竟是什么，明白了 EA 的问题域，才好理解 TOGAF 这套方法论为什么这么复杂。

1 TOGAF 对架构和企业架构的定义

ISO/IEC 42010:2007 将架构定义为：一个系统的基础组织，体现在系统组件，组件之间及组件与环境之间的相互关系，以及对系统设计和演进进行治理的原则中。

TOGAF 对架构的定义是：

1. 一个系统的正式描述，或指导系统实施的组件层级详细计划。
2. 组件结构，组件之间的相互关系，以及对这些组件的设计随时间演进的治理原则和指南。

这个定义要求架构需要具备三个关键内容：组件，关系，治理原则，以后解读到具体的业务架构，数据架构，应用架构和技术架构的时候，可以用来更好的去理解不同维度的架构中组件是什么，关系是什么，治理原则又是什么。

TOGAF 对企业架构的定义：

• 企业架构是定义企业各组成部分如何构建以及它们之间的关系，以及它们的设计和演变的原则、规定。
• 业务流程和 IT 基础设计的组织逻辑，反映了组织运营模式的集成和标准化需求。
• 一种定义组织结构和运营的概念蓝图，目的是确定组织可以最有效地达到其当前和未来目标。

2 企业架构的问题域究竟是什么

前面的两个定义比较抽象，我们先来思考这样一个问题：企业为什么需要企业架构？

TOGAF 的官方解释是：企业架构的目的是，在贯穿整个企业的范围内，将通常碎片化的已有流程（手动和自动）优化为一个对变化做出响应并支持业务战略达成的综合环境。

良好的企业架构会给企业带来重要的业务收益：

• 更高效的业务运营
• 更高效的 IT 运行
• 更好的投资回报
• 更低的未来投资风险
• 更快，更简单和更便宜的采购

读完上面这些有没有一种觉得好像懂了，但又好像没懂的感觉？我第一次读完就是这种感觉。所以我又去研究了一些相关的资料，发现可以用一个金字塔模型更直观地解释 EA 对于企业的价值和它在企业中的地位。

在金子塔的顶尖是企业的目标和战略方向，最上面一层是 EA 企业架构，EA 下面是 PM 项目管理，PM 下面是 OM 运营管理。用一个更具体的例子能够更好地理解这个金字塔，假定现在有一个企业是做餐饮的，这个企业的目标是每个城市都要有连锁店。

运营管理 OM 需要负责的事情是如何完成完整的企业价值交付，比如如何让一个顾客发现他们的店，如何吸引进店，如何点单，如何做菜，如何买单，顾客是否满意等等这些都是运营管理的范围。

项目管理 PM 需要负责的事情是如何完成一个项目的开发和实施，比如在一个新城市新开一个连锁店就是一个项目，如何选址，如何装修，如何招募员工等等这些都是项目管理的范围。项目和运营最大不同就是项目是有明确终结点的，最后这个连锁店开业了项目就结束了。

企业架构 EA 需要负责的事情是如何才能高效达成企业的目标。如果企业的目标是每个城市都要有连锁店，企业架构负责的范围是：这么多城市需要按照什么顺序扩张，每个项目的建设流程是什么，项目过程中什么可以做，什么不能做，如何让新项目速度更快，成本更低，连锁店开业以后有没有可复用的模式招揽客户，项目和连锁店可以使用什么 IT 系统，又需要提供什么信息等等。

3 EA的野心

所以从这个金字塔可以发现，理想状态的 EA 拥有判断项目和业务能否进行的否决权；以及指导项目如何建设，运营如何进行的规范权；还有要求项目和运营提供必要信息的信息权。这个点估计跟很多企业对 EA 的理解都有些不同，按照 TOGAF 的野心，EA 的问题域是成为一个企业的大脑，而不是一个只是画画线框图，设计一下 IT 系统，解决一下 IT 系统性能，安全，高可用这些问题的技术部门。

清楚了 TOGAF 的这个野心，就能理解这套方法论为什么这么复杂和厚重了。因为，这套方法论需要给企业的最高决策层逻辑清晰的论证清楚 EA 是可以成为一个企业的大脑，最终帮助企业实现战略目标的。它需要让这些 CXO 们意识到，这套方法论是完备的，它详细考虑到了企业架构的每一个细节；这套方法论是规范的，它可以进行标准化的架构设计；这套方法论是和企业管理相容的，企业管理者能够基于他的认知体系理解这套方法论。

为什么要写一篇文章专门去讲这个问题？那是因为如果不理解 TOGAF 的这个野心，在接触 TOGAF 这些复杂概念和框架的时候会天然的产生排斥感，但如果明白了 TOGAF 是想用企业架构来治理企业实现战略目标，从这个视角至少能降低一些排斥感。