程序员们，是时候重新关注下企业架构了！

现在很少有程序员没有听说过“中台”，但很少有程序员了解企业架构，更少有程序员会把企业架构的作用联系到数字化转型上，但这是已经涌起的趋势，是每个真正关心如何做好 B 端实现的程序员都需要具备的思维方式。想走好脚下的路，也需要多抬头看看天，所以，是时候重新关注下企业架构了，也许关注了企业架构，你会逐渐获得不一样的设计视角，会越来越知道自己写的软件有什么样的价值，而不只是有什么样的功能，这些价值最终也会转变成你自身的价值。

那什么是企业架构呢？今天有什么样的企业架构实践？未来需要什么样的企业架构设计思路呢？本文就打算分三部分跟各位程序员读者谈谈这个平时很少涉及到的话题。

1 企业架构是什么？

回答一个事物是什么，做好的方式莫过于“溯源”，知道它怎么产生的，也就知道该怎么去认识它。那么企业架构从哪里来的呢？答案是为了解决一个我们今天依然很常见的“毛病”：软件开发中的“先写了再说”。早期的软件开发是不会有什么章法的，多数行业的诞生期都是活在一片“混沌”中，软件行业也不例外，编程甚至是对硬件高度依赖的。但是到了上个世纪 60 年代，这种全凭能力与灵感的开发方式，无法有效地保证项目的顺利实施，必须有工程手段去加强多过程控制，于是，今天被人们大肆诟病的“瀑布模型”很“惊艳”地诞生了，别看现在很多人一谈“瀑布”一脸的不屑，但是当年“瀑布模型”也曾在美国军方的开发指导文件中占有一席之地。

“瀑布模型”是过程模型，还不是架构设计方法论，借鉴它的思路，确实可以更好地控制单个软件的生产，但是企业的需求是无法被单一软件满足的，哪怕搞到 ERP 那么大、那么复杂，也还有一堆其他系统一起上阵，才能搞定企业的需求。那这么多的软件都是“高内聚，低耦合”，可以“老死不相往来”，“低调”地走完自己的一生吗？答案是否定的，他们不仅不会“老死不相往来”，甚至可能“吵”得一塌糊涂，比如，数据的不一致、用户体验的不一致；企业希望他们能协同工作，但是他们有可能只具备很差的互操作性，甚至无法互操作，这当然给 RPA 留下了“美丽”的成长空间。

IT 是件很烧钱的事情，企业花了大把的 IT 投入，如果只是给自己建上一堆高耸林立的“烟囱”，那会让人觉得很不开心，这只是给不得不持续追加 IT 投入留下了“借口”。当然，这种现状 IT 人自己也是很不满意的，这岂是“高智商”行业所为？于是，早在 1987 年，IBM 的 Zachman 先生在其论文《信息系统架构框架》中提出了应该从多个视角整体分析企业，从而合理进行软件架构设计的思想，这篇论文就成为了“企业架构”思想的开山之作。

但是，Zachman 先生提出的只是设计思路，没有讲清楚具体的设计过程和方法，直到 1995 年，更为成熟的企业架构框架 TOGAF（the Open Group Architecture Framework，开放组架构框架）诞生了。TOGAF 今天经常被批评过程“笨重”，但是，回到 1995 年，这可是解决了一个大问题，就是 Zachman 先生提出的那么有道理的东西到底怎么做出来。对企业来讲，最重要的是一件事情该怎么组织，毕竟企业不是只有一个程序员，可能有 100 个、1000 个、100000 个，那这么多人怎么才能有序地整个企业的软件做好？无论是搞企业架构和瀑布，还是搞敏捷，你都得教给企业一个可以被大多数人理解和执行的过程，否则，想法无法转化为实现。

我们今天谈论的企业架构其概念大多来自于给出了一个完整构建过程的 TOGAF。在这里，笔者简要介绍下，在 TOGAF 中，企业指“有共同目标的组织集合体”，也就是，不是单纯指领了工商牌照的企业，而是“组织”，可以是一个企业，也可以是一堆企业，甚至是非盈利组织，也可以是企业中的一个部门，这么看，是不是很有“可扩展性”？是的，你用它来套今天很火的“生态”也是毫不违和的。这里的关键就是“共同目标”，这也指出了“企业架构”的设计目的，为了更好地实现“共同目标”。“架构”则引用了 ISO 的概念，即，架构是指系统的基本组成部分，各组成部分之间及其与环境之间的关系，决定其设计与演进的治理原则，也即，架构主要包括结构、关系、原则。那么，组合一下，“企业架构”的概念应当是“具有共同目标的组织集合体的基本组成部分及其内外部关系与治理原则”，用普通话讲，就是把企业分成一个一个的组成部分，确定好它们之间的关系和设计原则，再去分别实现，然后组合起来成为一个企业。按照 TOGAF 对企业的定义，那么企业架构大到可以对整个生态进行架构设计，也可以小到对部门内的业务进行设计，只要最终是跨两个以上的系统进行设计，就能体现出设计思维上的优势，范围越大，优势越明显。

那么，企业架构都会设计哪些内容呢？TOGAF 给出的企业架构内容元模型如下：

图一 TOGAF 企业架构内容元模型

可以看出，Zachman 先生多视角架构的理念得到了体现，表现为业务、数据、应用、技术四个架构，因为架构的一词的英文字首为“A”，又称“4A”架构，在这里可以看到，数据和应用又被合称为“信息系统架构”。

整体看，企业架构的设计既包括对了对企业的愿景、战略、业务、组织的分析，有包括基于业务分析而进行的应用系统设计分析，是业务与技术相连接的设计思维。但是，企业架构也有一个问题，就是大多数企业架构理论都没有很好地给出从业务分析到应用设计的衔接方法。

既然提到了“大多数”这个词，那就意味着企业架构理论还有别的方法论，是的，还有联邦企业架构框架（Federal Enterprise Architecture Framework，FEAF）、国防部架构框架（Department of Defensive Architecture Framework，DoDAF）、CBM（Component Business Model）等一系列企业架构框架和方法论。总的来讲，这些方法论之间的差异就是用什么样的理念进行企业的整体设计，本文不在此展开了，笔者有关于企业架构理论的专著讨论此事。

从上述介绍看，“中台”无疑也是一种“企业架构”方法，因为它同样需要基于整体视角进行设计。所以，我们可以看到面向整个企业的“中台”设计；“中台”也可以只对着一个事业部去做，只要它的业务够复杂，需要横向拉通业务和系统，这一点也跟企业架构一样，小大由之。

2 企业架构做的怎么样？

这么漂亮宏大包罗万象的理论，实践的怎么样呢？

先说说 TOGAF 吧，TOGAF 不仅是个框架，其中的“TOG”，也就是 The Open Group，还是个论坛型组织，专门负责研究和推广企业架构，目前有会员企业 800 多，当然，主要是欧美的大型企业居多，今年是该组织成立 25 周年，10 月份还组织了一系列的推广活动。在 The Open Group 的努力下，TOGAF 的方法论一直有持续更新，如今是 9.2 版了。实践案例集中在大型企业，能源、航空、制造、金融企业等，都有案例，与 SAP、IBM 等大型软件供应商、咨询服务商都有良好合作，有大量的资质认证培训，也是唯一具有权威认证的企业架构师资质。

但是，不得不说，TOGAF 的很多实践还是在借用其理念而不是完整、一板一眼地按照其方法论进行实施，所以，业界也常有一个说法，就是，判断一个项目是否是 TOGAF 项目，不是看其交付物，而是看其过程。也就是说，不是对着 TOGAF 手册去检查设计文档是不是种类齐全，而是看项目执行过程是不是接近 TOGAF 的 ADM 过程模型，也就是类似下图这个过程模型：

图二 TOGAF 过程示意图

国内企业极少有设立专门的企业架构部门的，但是笔者确实接触过一家头部科技企业，设立有非常完整的企业架构管理组织，并设有企业架构委员会。