你好，我是付晓岩。

上节课，我介绍了构建数字化转型方法论最核心的思维模式，也就是架构思维，它是负责连接方法论与实践的。毕竟，光有思维模式还不够，得能融入到实践中才行，最直接的方式就是做架构设计了。架构思维，就是通过对企业架构的设计和实施，去指导企业数字化转型。

但是，很多人都不太清楚到底什么是企业架构，觉得企业架构就是个“花架子”，很虚，很抽象，对实践的指导意义不大，做不做都没问题，照样可以搞企业端的软件开发。

其实，这正是做数字化转型非常大的误区。如果没有整体观念，只是孤立地看待每次开发任务和每一个子系统，最后会导致你花了大价钱开发的各类系统之间互不协调，不但形不成合力，甚至会导致数据的不一致，使企业反倒被自己开发的系统所累。

数字化转型注定是企业的整体转型，如果不了解企业架构，你或许能帮助企业实现一些很不错的数字化创新点，但是无法帮企业实现整体转型。

所以，今天，我就跟你介绍下企业架构，包括它的发展历程和未来的方向，打破你对企业架构的误解，帮你建立起正确的认知，以免被某一种架构理论限制住自己的思维，阻碍了数字化转型的进程。

首先，我来给你讲一讲，为什么需要企业架构，它是怎么发展的。

为什么需要企业架构？

这里我们要先明确一个问题，不是所有的软件都会用到企业架构。虽然软件都有架构，但不同类型的软件考虑架构的视角不太一样。

从最终用户的角度看，软件大致有 2 种类型，给个人消费者用的，就是 C 端软件；给企业用户用的，也就是 B 端软件。

C 端软件的使用者是个人，所以，我们就不需要考虑企业架构的问题了，应该把个人使用习惯和感受放在第一位。但这不意味着 C 端软件的开发者就不必了解企业架构了，因为不少 C 端软件是企业开发出来的，作为企业来讲，还需要关注如何提升自己的开发效能，这也会用到企业架构。

而 B 端软件是给企业用的，设计得对不对、好不好，就得考虑企业到底是什么情况了。而且，每个企业都会用到很多软件，往往企业规模越大，用的软件就会越多，软件之间的协作也是一个必须考虑的问题。比如，中小银行可能会有 100~200 个业务系统，大型银行则会有 800~1000 个业务系统。那么，这些系统在业务协同和数据一致性方面怎么保证呢？

要想解决这个问题，就要用企业架构这种“顶层设计”了。不过，要是你以前没怎么接触过企业架构，可能一下子不太好理解我为什么这么讲，那咱们接下来就从软件行业的发展历程，来看看企业架构是怎么诞生的。咱们软件行业的前辈们可是没少吃缺乏顶层设计的亏，不然，真的认识不到企业架构的重要性。这个问题，你一定要重视。

早期的编程工作真的是“先写了再说”，毕竟每个行业一开始都是很懵懂的，没人知道怎么做合适。结果，这么搞了差不多 20 年，到上个世纪 60 年代，软件危机爆发了，软件开发的四大关键问题：时间、成本、范围和质量全面失控。人们对软件开发工作的不满越来越大，于是把建筑业、制造业的经验向软件行业引入，这就是引进工程化思想的开始。

大名鼎鼎的第一个软件工程模型“瀑布模型”就诞生于 1970 年，是温斯顿∙罗伊斯提出的。“瀑布模型”本身是一个观察结果，它指出软件开发包括系统需求、软件需求、系统分析、程序设计、编码、测试、运营等若干环节，这是第一次有人说清楚软件制作过程到底是怎样的。

工程化思想确实可以提高单个软件的质量，但是企业需要的通常是一堆软件，你现在可能就用过办公邮件、文件管理、ERP、CRM、MIS，等等，银行里更是会有几百个系统。

所以，单个软件质量的提升不会解决整体设计的缺陷，比如各系统间不能互相协同、数据定义不一致，出现业务孤岛、数据孤岛，你今天听说过的这些 B 端软件问题多数都是由来已久的，而不是刚刚出现。

B 端软件的生命周期也可能很长，加上软件之间需要协作，如果没有良好的架构设计做顶层指导，那升级、运维的复杂性对技术人员而言，也可能是“灾难性”的。

这就说明，光是工程化，加强对制作过程的管理还不够，还得加强设计能力，知道如何在企业这种复杂环境下设计系统。于是，一个从整体视角看问题的软件架构设计思路就应运而生了，它就是企业架构。

企业架构是什么发展的？

其实，“架构”这个词也是从古老的建筑行业引进来的，不是软件行业自己搞出来的。我来介绍下它的发展历程。

提出与完善

企业架构思想诞生于 1987 年，这时候，工程化已经搞了快 20 年了，但大家还是没有搞清楚，在 B 端怎么设计软件合适。

IBM 的雇员 Zachman 先生在 IBM 的内部刊物上发表了一篇文章《信息系统架构框架》，谈到了“架构”这个词在软件行业应用上的混乱，并提出了自己的架构设计思想，这篇文章后来被奉为企业架构的开山之作。

Zachman 的思想最重要的一点就是，架构是多视角的集合，是“一套架构（a set of architecture）”，而非“一个单一的架构（a single of architecture）”。架构是从多个视角观察企业得到的结果的总和，这实际上也是上一讲中提到的架构思维的全面性。

换句话说，我们不应该总抱着自己认定的视角去跟别人争，而是要努力去看看，到底需要多少种视角，才能理清企业的全貌，这样才能让我们设计的系统与企业的实际环境匹配上。

Zachman 的思想后来在 Open Group（开放组）的努力下发扬光大了。Open Group 在 1995 年提出了一个体系结构非常完整的方法论 The Open Group Architecture Framework（开放组架构框架，简称 TOGAF）。

TOGAF 首次正式定义了什么是企业架构，他们提出，企业架构就是“具有共同目标的组织集合体的基本组成部分及其内外部关系与治理原则”。这个很怪异的“组织集合体”指的就是企业，只不过它比你平时理解的企业范围大些，能被一个目标圈进来的组织，都可以被当成一个企业看，所以，TOGAF 是支持建立跨组织的架构的。

TOGAF 认为企业架构包括业务、数据、应用、技术四部分，也称“4A 架构”，实际上是 4 种架构视角。Zachman 主张的多视角架构，在这里算是成型了，做企业架构就要完整地做出这 4 种架构。

简单地说，企业就是处理了一堆数据的一堆业务活动，这些业务活动和数据被一堆功能实现，这堆功能又被部署在一堆技术平台上。

除了解释企业架构是啥，TOGAF 还给出了企业架构的完整开发过程，包括预备阶段、架构愿景、业务架构设计、信息系统架构等诸多过程和内容，算是跟大家说明白了企业架构该怎么去做。

企业架构理论在国内外还是有一定认可度的，尤其是在传统行业，制造、能源、金融、航空等领域，不少大企业都在用这个方法论指导他们的 IT 规划。不过，这也经常使人认为，企业架构是大企业才能搞的东西。但实际上，作为一种指导复杂环境下多系统协同设计的理念来讲，企业架构理论是不区分企业规模的。对于企业而言，没有企业架构思想，连系统的内部协同都做不好，又怎么进行数字化转型呢？

好，知道了企业架构的必要性，你可能会觉得，这东西你说得这么好，还有很多大企业支持，怎么我好像就没听过呢？或者说，听过的可能也觉得没有那么好。其实，这就是企业架构目前略有尴尬的处境了。

现状

TOGAF 诞生后，企业架构理论就在一路争论中缓缓前进了。这主要是因为，并不是有了方法论，企业架构的搭建就变简单了。实际上，人们反倒是充分地看到了企业整体架构有多复杂，这也导致了很多疑虑。

首先就是对方法论的质疑。

一方面，如果企业本身很复杂，一次性梳理企业全貌的话，投入的人员太多、周期太长，不仅会增加失败的风险，也容易跟不上业务的快速变化。

另一方面，这种设计复杂度太高，很多人都担心容易设计不到位，变更也麻烦。不知道怎么克服这些现实问题，很多企业就产生了顾虑。

其次，还有很多来自于对传统软件工程的质疑。

一提到传统的瀑布式开发，大家觉得又慢又容易落后，所以敏捷开发兴起，敏捷开发通常会搞短周期迭代，这就意味着，没给企业架构这种长周期的梳理工作留时间。

但是实际上，敏捷开发本身也需要关注企业全局。就像我在上节课说的，你给 5 件事排序，跟你给 10 件事排序，结果是不一样的。对敏捷开发来讲，过于强调快速设计，考虑问题的范围就可能会比较狭窄，那得出的设计方案也可能是有问题的，并非所有需求都是“火烧眉毛”的。

除此之外，也出现了否认企业架构可以整体设计的方法，比如领域驱动设计（DDD）的提出者 Eric Evans 就曾在对“总体规划”方法表示了一种委婉的不信任，也提出“使用不合适的结构还不如使用它，因此最好不要为了追求设计的完整性而勉强去使用一种结构，而应该找到尽可能精简的方式解决所出现的问题。要记住宁缺毋滥的原则”。

但是，现在国内的一些 DDD 应用发现，如果没有自上而下的考虑，不与企业战略、组织结构适当结合，做架构设计还是很困难的，所以，国内最近这些年的 DDD 应用，也在往结合企业整体分析的路线上走。除了怀疑之外，还有积极的进展，有一些新方法论陆续诞生，其中影响最大的莫过于从互联网领域发展出来的、以能力复用为主要目标的中台架构。

中台设计其实也是考虑企业全局的设计思路，从互联网企业一开始的猛打猛冲，走向了提倡节省资源、内部复用的中台化，实际上是选择了企业架构方向，尽管走的不是传统路线。

虽然 2020 年底又传出了阿里巴巴集团“拆中台”的声音，但是，你也不用太在意，中台的走势就像软件行业发展历程的缩影：从乱中取胜搞出软件危机，到强调秩序，诞生软件工程，再从单纯强调秩序转向自由选择，一切从实际出发，不对复用或不复用搞“一刀切”，就是跟着企业自己的需要在变而已。

虽然有各种声音，但是，随着数字化转型的到来，包括互联网公司在内，很多企业也在重新认识企业架构，大家越来越认可全局视角对数字化转型的价值，不考虑整体而获得的局部灵活性，一定程度上也是在给未来积累技术债务，这是阿里巴巴集团搞中台的“初衷”之一，也是很多互联网企业随后都发布了自己家的“中台”的原因吧。

未来

那么，企业架构要怎么发展，才能支持数字化转型呢？这里有两个重要的方向，分别是更好地适应企业生态越来越开放的发展要求，以及充分提升软件开发效率，才能让软件生产速度跟得上软件需求的疯狂膨胀。这两个方向的应对之道，分别是开放式架构和行业级标准化。接下来，我分别来讲一讲。

1. 开放式架构

数字化时代的到来，会让大家的连接越来越容易，持续打破空间限制，人与人之间、企业与企业之间的协作也会更容易，至少在技术层面是这样。

这意味着，不用区分企业内外，大家可以更好地连接彼此的能力了。这种连接，也要求我们在设计企业架构时，不能只盯着企业内部，要放眼整个生态进行设计。像现在搞供应链管理、平台生态那样，处理好彼此关系，进行总体规划，定位好自己在生态中的位置，开放式架构是大势所趋。

现在，国家在“十四五”规划中，也非常重视产业链、供应链的建设，这个是更广泛的全球视野下的规划，大到国家，小到企业，道理都是一样的。“治大国如烹小鲜”，跟着国家政策走，错不了的。

2. 行业级标准化

除了开放式架构，还有一个重要的方向是行业级标准化。关于这个方向，提的人不多，你可能听着有些陌生。实际上，企业架构理论中是考虑过这个问题的，比如 TOGAF 中就认为在企业自身的特定架构之上是可以存在行业架构的。

这种行业架构其实符合企业的长远利益，你想想，现在同一行业内的企业，软件功能存在大量相近甚至相同的东西，但是经常要重复开发，这部分的比例有可能达到开发量的 60% 以上，尤其是中后台业务，如果企业软件中这 60% 的重复部分可以开源，那对企业而言会有多大的益处！国家也是看到了开源的价值，才在“十四五”规划中鼓励企业开源自己的软件。

企业如果能够大胆开源自身的一些应用设计，也有助于提升自身的行业地位，接受你设计的企业越多，你与别人的连接也会更容易，对生态建设也更有利。此外，有人多帮你看看设计、看看代码，对软件质量提升也有好处。

总结

今天，我讲了企业架构的发展历程。到现在，这个理论才 30 多年，就是个青年，真算不上老，不要总被快节奏带着跑，很多事儿都需要沉淀，尤其是企业架构这种要把企业总体都看透的方法论，无论是方法论自身，还是学习者，都需要好好修行，这不是快餐，得和时间做朋友。

企业架构的流派虽然不止一个，但是总体来讲不算多，要想不被概念忽悠，最好的办法是花点时间，把这些理论都看看，自己心里有个数，才不会“中招”。

面向未来，企业架构的发展方向是开放式架构，也就是说，做企业架构不但要熟悉自家的事情，还要了解整个生态的事情。未来还要注重推动行业级标准化，这样才能不浪费大家宝贵的青春。

企业架构中还有一个重要话题，就是业务架构，业务架构是数字化转型的关键，是架构思维进入企业管理层乃至各个层面的关键，下节课我会重点给你讲一讲业务架构。

思考题

课后希望你可以结合今天所学的内容，分析一下自己的公司，如果推行企业架构，是不是可以把软件做得更好？

欢迎你畅所欲言，和我一起交流讨论。如果你觉得今天的内容对你有所帮助，也欢迎你分享给你的朋友或同事。