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

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

  回答一个事物是什么，做好的方式莫过于“溯源”，知道它怎么产生的，也就知道该怎么去认识它。那么企业架构从哪里来的呢？答案是未解决一个我们今天依然很常见的“毛病”：软件开发中的“先写了再说”。早期的软件开发是不会有什么章法的，多数行业的诞生期都是活在一片“混沌”中，软件行业也不例外，编程甚至是对硬件高度依赖的。但是到了上个世纪 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 给出的企业架构内容元模型如下：

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

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

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

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

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

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

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

  此外，笔者有幸参加过一个在整个世界范围看也少有的极为完整的大型银行企业架构转型工程，是一家国有银行，工程历时六年多，项目投入和深度都是无与伦比的。该项目采用的是 TOGAF 加 CBM 的融合型方法论，其工程情况如下图所示：

  工程具有非常明显的 TOGAF 特征，但是交付物则有明显的 CBM 特征，是两种理论的融合，可见，企业架构的实施并非“死板”的，而是根据自身的需求灵活设计的。但是“灵活”的前提是要对方法论有深入的了解，对实施困难的克服有坚定的信心，办法总比问题多。笔者总结，企业架构的设计与实施，就是“问题决定工具，毅力决定结果”。

  在这段长达六年多的实践中，该行采用标准化的流程模型、数据模型、产品模型建模方法，对二十几个业务条线进行集中的企业级建模，建模的时间达到两年左右。其实这并非一个很长的时间，因为其中包含了对方法论的打磨，对行内战略的解读，对 80 多个主体业务专题长达半年的深度研究，是基于较为完整且长期的业务能力规划进行的业务模型设计，其中的数据模型更是对 3000 余个数据实体、20000 余个属性进行了企业级统一定义，对历史数据进行了完整的数据迁移，奠定了企业数据治理的坚实基础。基于业务模型，还对主体业务系统来进行了服务化重构，涉及众多核心系统。部分核心系统的重构是难度极高的，比如金融市场领域相关的业务系统，其完全替换更是一直持续到了近期，这对相关系统的国产化设计也做出了有益的探索。完整的企业架构设计相当于梳理了相互对应的一套业务能力地图和一套 IT 资产地图，这两者又共同构成了一套企业能力地图。

  业务的标准化是对业务行为的精准认识，这是一切合理化设计的基础，假如没有标准化约束，业务行为的认知可能是极为发散的，比如，该行最初的三级业务活动识别数量曾经达到接近 10000 个，而在进行结合了数据实体分析的标准化后，三级业务活动的数量骤降至 900 余个，这对 IT 设计而言，其需求的去伪存真程度可想而知，这种方法是否也可以让不合适的需求少很多？

  笔者深度参加了该行企业转型工程，在这一过程中完成了从一个业务人员到业务架构师的转变，从 2012 年算起，笔者做业务架构已经 9 年了，能算得上是这个小众领域中的“资深”人员。笔者从接触这样的领域开始，就认定了企业架构、业务架构的价值，也因此而努力到今天。“不谋全局者不足谋一域”，这就是企业架构的思维逻辑。解决孤岛问题、培养全局设计能力，这就是研究企业架构、业务架构的价值所在。业务架构也并非一个完全以业务能力为主的角色，当然，也非以技术为主，而是以“架构”为主，通过流程、数据、产品三种模型的结合分析，设计出业务的结构，为 IT 设计提供结构化的分析依据。提供丰富深入的业务信息是业务专家的职责，因为无论业务架构师如何努力，都不能够确保在第一时间内感受到业务变化，这是“位置”决定的，所以，能力的重点是对结构的分析和设计。一个合格的业务架构师要有快速切换领域的能力，而非一辈子专注一个领域，笔者自己也是客户信息、客户关系、养老金、同业、金融市场、资管、托管等多个领域切换过。当然，这不是单纯依靠能力，还要依靠架构资产，也就是业务模型。笔者之前在从事同业领域业务架构设计时，也是在之前没有接触过同业业务，依靠业务人员的输入和既有的企业级业务模型，完成对其全部业务涉及的二十多个业务组件的业务架构方案设计。

  从长期对业务架构设计的实践和对相关理论的研究，笔者也发现，其实做好业务架构设计进而做好应用设计的关键，并不是哪个“神奇”的方法决定的，无论是 DDD 还是敏捷，一样不能离开对业务深入的理解，或者极端点儿说，什么方法都比不上你跟业务人员多交流几天、帮助业务人员理清设计目标的效果。也正因为如此，作者觉得企业架构中的业务分析方法，更贴近于如何让业务人员结构化地分析业务，并且更快速地跟技术人员对设计目标达成一致，因为这种方法相对而言是业务人员学习成本比较小的。业务和技术的融合，需要方法论支持，但是更重要的是提供一个充分融合的操作的流程，这也是企业架构这种相对“慢”的方法“快”的地方，笔者也将这种思路代入了对企业架构方法论的改良中。

  不过从笔者的实践和与别的企业的交流看，笔者还是认为在企业内部采用一致的架构设计方法还是有很大价值的，尤其是对准备进行转型工作的传统企业而言，这一些企业本来就是体系化的，内部有很多密切的联系存在，如果在方法上不一致，相当于叠加了额外的沟通成本，对企业而言，这可能是消耗而非提效，企业不是这一些方法“百花齐放”的试验场。方法论在企业内不统一的另一个弊端就是影响企业的知识沉淀，无论是业务知识还是技术知识都一样，没有体系化的归纳能力，对人员能力的培养也会成问题，体系化知识训练出来的人员，其对执行力和对本企业的理解能力都会明显高于“野生”选手。该行最终通过业务模型沉淀了大量的知识，这些业务模型后来也成为了可以对外输出的商品。

  该行的工程中，特别值得别的企业借鉴的一点是对该行对工程的强大组织执行力，正是通过领导层的高度支持才能将众多的业务部门、业务人员长时间集中到一起进行企业级业务架构设计，而这种设计是企业级业务系统之间能够横向联通的关键，毕竟，只有业务部门自己才能打破相互之间的壁垒，这也是一些尝试从技术侧发起企业级业务系统设计在很多传统企业最终难以实现目标的原因，离开了业务的深度参与就不会有真正的企业级业务系统。很多企业觉得学不了该行的“大手笔”，其实这是个认知上的误区，“手笔”的大小取决于企业的“目标”，这是个价值判断题，而且是未来价值判断题。今天国内外看起来很强大的那些科技公司，都曾经弱小过，都曾经不被看好过，他们几乎都是在自己挣扎的路上时刻拼尽全力才有了现在的样子，也许它们的今天很多企业确实学不了了，比如 Google 小团队里那么高的博士密度，但是它们过去一路对极致的追求，则是很多企业现在能学的，这一点对于做企业架构来讲也是一样的。企业架构也不是一朝建成的，只要企业有足够的韧劲就行。

  目前国内银行业，尤其是头部大型银行，几乎都已经开展或者正在开展不同形式、深度的企业架构工作，企业架构的应用场景范围也正在逐渐向股份制银行扩散。那未来会不会有更多的中小银行开展企业架构工作呢？笔者相信会的，只要没有把数字化转型的全部支出都“误算”给企业架构，那企业架构的实际花销并不是非常大，尤其是当对企业架构设计服务的需求慢慢地增多，导致服务商的供给能力提升后，设计费用一定会朝向下降的方向，因为说到底，企业架构是一种整体设计的思维方法，企业经历过一定的实践后，逐步就会掌握这种设计理念，而慢慢的变多的人掌握这种设计理念，就会带动供给量放大和价格的下降。

  作为一种设计思维而言，有些企业尤其是 SaaS 类软件服务商，其实正在运用这类设计理念但是并没意识到这实际上也是企架设计，比如一些为中小企业信息化服务的厂商，他们在为客户提供服务前，也要努力把客户的主体业务流程梳理清楚并尽可能进行全程拉通或者横向拉通，以寻找业务断点、业务改进机会点。笔者曾与这类企业交流过，也为一些很有上升力的互联网公司培训过企业架构方法论。

  不过，一些做过或者接触过企业架构的企业和人员也产生了一些“误区”，比如总是想从实例上学习企架，而忽略了它的思维方法，结果，要么是看不出模型的作用，要么是把力气都用在死磕企业架构中那些“模糊”的定义上了。

  未来的企业是怎样的呢？当然是按照实际业务需要，尽可能数字化的。数字化如今是国家级的转型方向，在“十四五规划”中，数字化有单独的一篇，并且这一篇的首段，就点明了数字化的核心问题，“迎接数字时代，激活数据要素潜能，推进网络强国建设，加快建设数字化的经济、数字社会、数字政府，以数字化转型整体驱动生产方式、生活方式和治理方式变革”，这段话说明了数字化是一个新时代，主要抓手是数据、网络、软件，目标是建设数字化的经济、社会、政府，方式是整体转型，所以，每个企业的数字化发展也离不开这些关键点，这是“数字中国”的方向，自然每个企业都会深受影响。

  我们还能更加进一步分析下，这样的企业必然是要建立在更大的社会级、行业级数字化平台上，也就是基于数字生态构建的云上虚实结合企业。这样构建企业软件，需要更为灵活的 SaaS 服务方式，也就是说，不是基于重量级套件，而是由能更加灵活选搭的、更小、功能更单一的“构件”组成的，相当于基于一个大型标准化开源构件库进行选搭。为何需要这样？因为这样做才能够降本增效，数字化需要太多的软件，目前的开发模式无论如何也满足不了这么庞大的需求。数字化最重要的生产要素是数据，最重要的工具是软件，因为只有软件才能处理数据。那么，这一些要素、工具如果要满足这么多公司进行转型，那得需要什么样的效率才可以。如今，即便是大型科技公司，其开发模式也不过是“大规模小团队手工作坊”，完全没有办法与工业化生产的效率相比拟，如果继续这样，软件行业是担不起全社会数字化转型大任的。

  不仅仅是生产效率问题，传统的竖井式开发在高效推动企业信息化的过程中，也留下了大量的混乱的设计，这与企业架构始终没能充分的发挥作用，尤其是在思维影响上发挥作用有着很直接的关系，一个内部连接都有问题的企业，更无法做好生态连接。

  这些方向决定我们肯定要能力探索与“数字中国”建设方向相一致的企业架构方法论，并努力通过方法论提升整体设计能力和标准化程度，使软件真正具备成为基础产业的能力。为此，笔者抛砖引玉，提出了“聚合架构”，也就是基于底层标准化架构元素聚合上层架构元素的企业架构设计思路，使软件设计逐步走向形成行业级标准化构件库，非竞争性的通用能力基于标准化构件做微量改造，竞争性能力重点开发的设计模式，通过企业架构方法论最终为基于云的数字生态打造思路更容易跨企业对接的设计思维、设计语言。

  云上的数字化生态会不会最终成为“巴别塔”，也许取决于我们的程序员能否更好地牺牲一部分“自由”换取更大的“效能”。

  程序员们，是时候重新关注企业架构了！随着数字化的发展，企业的商业环境、我们的开发环境、我们面临竞争模式都将改变，国外已经有人提出将大规模软件开发能力列为国家竞争力了，这绝不是依赖“996”的小部队混战，一定是产业级的大兵团作战，我们应该“道路自信、理论自信”。

  ，互联网大厂资深行业解决方案总监。《企业级业务架构设计：方法论与实践》、《银行数字化转型》和《聚合架构：面向数字生态的构件化企业架构》三书作者，原国有大行资深业务架构师，多年负责业务架构设计、项目管理，有着非常丰富的银行业务经验和企业级项目业务架构设计经验。原 IBM 副合伙人，总监，金融行业企业架构师。

  云原生明星企业刚刚宣布倒闭：年收入数千万元、十年融资 4 亿元，GitOps 的未来何去何从？

  刚上线就崩了？字节版 GPTs 征战国内市场：无需编码，快速创建 AI 聊天机器人

  10个有关数字化的梦想与征途｜Digital 36 「2021年度企业数字化创新案例」调研