中台架构的未来在哪—开放式架构

 

春节前应“技术琐话”之约，试图写一篇讨论架构方法论的文章，然而动笔之后，才发现，自己似乎陷入了Frederick P. Brooks先生在《设计原本》一书中指出的问题：“设计中最困难的部分在于决定要设计什么”。

2020年1月18日，有人戏称是“中台”历史上最“困难”的一天，一篇炸圈的文章将对“中台”的讨论又一次推向高点，虽然“泼冷水”的意味十足。其实笔者之前也谈到过，“中台”自诞生伊始就非一个严谨的定义，而是一种比喻，比喻当然也就容易导致争论不休，“中台”现在面临的问题其实也和笔者动手写这篇文章面对的问题差不多。但是，将“中台”理论不断明晰化的尝试仍是个好事情，毕竟，这是国内企业掀起的一次对架构设计方法的有益探索。

笔者在2019年11月南京中台大会上也曾讲到，如今很多领域都在谈国产化、自主可控，架构领域难道不需要吗？架构领域方法论的持续完善、国产理论的持续创新，是驾驭技术组合的关键，底层技术的不断自主化并不会必然带来顶层设计能力的自主化，而数字化转型，除了需要底层技术的支撑外，卓越的上层设计更是重中之重。走出有中国特色的数字化道路，底层技术能力与上层设计能力缺一不可。

对企业级软件架构设计方法的研究需要所有人共同关注，它是在持续进化的，也是未来企业走向数字化过程中，实现业务与技术深度融合的必经之路。Brooks先生在同一本书还提到：“好的设计者应该投入大量精力来学习判例……但现代设计匆忙的节奏却对这种实现非常不利”，他写下此语是在10年前，今天，这种情况只能说是有过之而无不及吧。

讨论架构问题永远是困难的，虽然笔者能力有限，但是出于对架构理论的爱好，还是尝试通过本文与各位读者共同探讨架构方法的演进与改良。

 

一、软件工程与企业架构

（一）懵懂的早期：没有工程、没有架构

架构设计是随着软件复杂度的上升而真正受到人们重视的。1946年，巨大的电子管计算机ENIAC诞生，软件行业的帷幕拉开，但是此后十几年的时间里，软件设计都只是少数人的事情，这个行业大部分时间都在实验室中发展。虽然高级语言出现，但是大多数程序设计人员的主要武器是汇编语言。模块化的思路逐渐出现，但是软件过程管理是很原始的，也没有所谓的架构设计方法，流行的就是“先写了再说”。

 

（二）方法的开始：瀑布模型和Zachman模型

混乱的管理方式引发了60-70年代的软件危机，于是，1968年NATO会议上，“软件工程”的概念首次被提出，其核心思想就是建立并使用完善的工程化原则，通过一系列方法，以较经济的手段获得能在实际机器上有效运行的可靠软件。这个“朴素”的目标，反映了软件行业早期存在的时间不可控、质量不可控、预算不可控等诸多问题造成的困扰。

1970年，Winston Royce在《大型软件系统开发的管理》一文中，提出了“瀑布模型”，将开发分成如图1所示的7个明确的阶段：

 

图1瀑布模型

Royce其实认为这是一个有风险的开发过程，并提出了5个修改建议，包括在分析阶段之前增加一个在信息不足条件下的预设计、开发过程中增加客户参与等，但是大家却把这个被他列为批评对象的“瀑布模型”作为开发的标准过程，包括美国国防部，他的建议却鲜为人知了。其中的分析阶段也就包括了架构设计工作，逐渐又被细分为概要设计和详细设计。但是这个时期的架构设计主要还是针对软件设计，还没有发展出成形的企业架构理论。

随着人们对软件设计工作认识的不断深入，大型软件设计与企业管理的关系越来越紧密，这也体现了人们对软件设计的本质性目标——为企业服务的认知。基于此，1987年Zachman提出了首个较为完整的企业架构模型，该模型按照“5W1H”，即What（数据）、How（功能）、Where（网络）、Who（角色）、When（时间）、Why（动机）6个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统6个层次，将企业架构分成36个组成部分，描述了一个完整的企业架构要考虑的内容，如表1-1所示。

表1  Zachman模型简介

这个架构设计方法论已经将系统设计应支持企业经营管理目标的要求表达出来，但是该模型的一个不足是Zachman并没有给出一个详细的构建方法。

 

（三）成熟的进步：螺旋模型和TOGAF

1988年，软件工程上又一个里程碑式的方法诞生了，Barry Boehm提出了“螺旋模型”，该模型如图2所示：

图2螺旋模型

螺旋模型通过持续对原型进行验证式、增量交付的方式，弥补“瀑布模型”在需求管理方面不足，是一种对需求的渐进式探索，也加强了对项目风险的管理。Brooks在2010年著书时仍对该模型赞赏有加。

随着信息化程度的加深，企业越发认识到将IT融入企业管理的重要性，IT人员也意识到与业务结合的重要性，于是，1995年TOGAF（The Open Group Architecture Framework ，开放组体系结构框架）应运而生，业务架构的概念也被明确提出来。TOGAF认为企业架构分为业务架构和IT架构两大部分，业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容，业务架构再作用于IT实现。TOGAF的设计交付物如表2所示：

表2  TOGAF交付物示意

可以看出，到TOGAF时代，在内容上，企业架构和业务架构发展的已经较为完善了；在工艺上，TOGAF也有明确的操作要求，也正是因为有详细的要求，TOGAF被公认的缺点之一就是太“重”，有点像是架构领域的“瀑布模型”。

从Zachman到TOGAF，尽管理论日臻成熟，但是企业架构设计与实际开发过程之间的结合一直不是很好，更像是在两条线上发展，表面看起来，Zachman模型似乎还能跟“瀑布模型”走得到一起，毕竟二者都被认为是“漫长”的，但大部分开发实际上在这个时期都是沿着“竖井式”的道路在走，仍旧缺乏对企业级设计的关心。至于TOGAF，它跟螺旋模型、迭代模型之间在实操上有不易结合之嫌，恐怕不少企业接受了应用TOGAF思路的咨询方案，却在实施过程中将其束之高阁了。尽管如此，TOGAF对推动企业架构发展的作用仍是非常大的。

 

（四）对更快的探索：敏捷开发、DDD和微服务

对效率的探索涌现出了更多的软件工程方法、设计方法，不同方法间逐渐形成组合，从单一方法到“组合拳”也是一个很有意思的过程。

不满足于软件工程的进步，90年代，敏捷开发的思路开始出现。2001年，在美国犹他州雪鸟滑雪胜地，敏捷方法发起者组织敏捷聚会并起草大名鼎鼎的《敏捷宣言》，“敏捷”开发也在这次聚会上正式定名。虽然目前对敏捷开发的认识还不是很一致，但大体上的开发流程，可以在网上找到很多类似图3的介绍：

图3敏捷开发流程（来自互联网）

敏捷开发的矛头可谓直指“瀑布模型”，大多数讲敏捷开发的书几乎都以此开头。笔者并非一个敏捷实践者，因此也无法深入讨论这一方法的优缺点，但是从对其实现过程的介绍来看，企业架构的设计显然没有包含在敏捷过程中，敏捷强调的是产品和用户维度，而且敏捷的“轻文档”理念与企业架构已有的“重文档”方法之间也是有矛盾的。

由于研究的人很多，敏捷开发在软件过程管理和软件设计方面都有较快发展。尽管有人质疑其效果，但是据称全球排名第11的资产管理公司——荷兰国际集团（ING）是在全公司推行敏捷开发的，该公司拥有员工113,000人，在全球50个国家为6千多万客户提供金融服务。

除了对过程的加速，架构设计方法本身也有创新。2003年，Eric Evans提出了DDD，也即领域驱动设计方法，该方法的特点是在需求分析、软件设计方面的一体化实现，通过领域模型直接形成可以指导到“类”设计的软件架构模型。但是DDD明显只是一个软件架构设计方法，而非企业架构设计，并且，DDD领域的大师级人物Vaughn Vernon认为企业级是无法从顶层直接设计的，只能在领域建模完成后，逐个领域地进行尝试性融合。Eric Evans也在其书的结尾对“总体规划”方法表示了一种委婉的不信任。DDD最经典的架构图如图4和图5所示：

图4六边形架构（来自互联网）

 

图5领域模型示例（来自互联网）

Eric Evans曾提出该方法主要面向敏捷过程，二者其实在方法层面有相似之处，都强调快速由需求进入开发过程，也都注重对模式的运用。但是因为DDD方法掌握起来有一定难度，因此并没有真的随着敏捷开发“火”起来，倒是借了另一种架构风格的“东风”，微服务。

微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格注重用具备独立数据库的微服务来替代原有的单体应用设计方式，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是Restful API。这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。从理念上看，极具灵活性、快速响应能力、可复用性和扩展性，案例上更是有传奇公司Netflix做标杆。

但是这种架构风格并没有很好地处理它的前身SOA遗留的问题，就是如何确定服务的颗粒度，于是，不温不火快10年的DDD派上用场了。DDD这种可以直接按照限界上下文导出数据和行为相结合的设计结果的方法，很适合推微服务一把。Chris Richardson在其著作《微服务架构设计模式》一书中就专门花了两章来介绍DDD与微服务的结合。

在对更快的探索中，敏捷开发、DDD和微服务提供了一种包括软件过程、架构设计和工程实现在内的“组合拳”，当然，这并不意味着所有企业都要这么用，只是一种参考而已。此外，求快的同时，这些方法也都欠缺对企业架构的关注，它们都是可以提升IT开发效能的有力工具，但是，在To B端，仍需要一种可以面向企业级能力建设的方法作为总体导引。

 

（五）小结：行路难

架构设计的思路到上个世纪70年代才逐渐开始发展出来，软件行业希望也能像工业、建筑业一样具有行业级的设计原则、标准，从而使高质量软件的产出得到保证。但是，到目前为止，架构之路殊为不易，还没有哪种方法升华为举世公认的原则或者榜样。

软件工程到今天才算年过半百，还是个比较年轻的领域。从“瀑布模型”进化到“螺旋模型”大约用了20年；敏捷开发快20岁了，DDD也有17岁；微服务虽然很年轻，才5岁，但是它的前身SOA是1996年诞生的。企业架构从Zachman模型诞生到现在是33岁，而TOGAF到现在也就25岁，只相当于软件工程的一半年纪。如此说来，这些方法以其要服务的目标领域而言，都还是只是刚刚进入“青年”这个水平。

然而上述方法我们至今仍在对其某一方面大加挞伐，没有一个是“银弹”，没有一个不曾被人骂做“坑”。但是贵在探索和坚持，这些方法经历时间的洗礼，仍未褪去“稚嫩”，仍需要“呵护”与反复实践才能健康成长。

现代社会的快节奏对架构的积累确实是一个挑战，“快”原本应该是目标，而今成了方法。我们对很多架构方法的理解尚不深入，对其应用也需要对方法创立者的初衷深加体会，比如，敏捷方法的创始人、“敏捷宣言”起草者之一的Jeff Sutherland在《敏捷革命》一书中提到其灵感来源的“OODA”方法，建议在每个冲刺中都要完整使用，但在各类敏捷书籍中却鲜有提及；Vernon也提到，无论是对敏捷方法还是对DDD而言，“知识获取”都至关重要，但是“知识获取”显然需要积累；即便是对口诛笔伐的“瀑布模型”，也一样存在众多误解。

抛去这些争议不谈，我们至少可以从软件工程与企业架构的发展历程中看到这样两个个趋势：一是关注点从软件架构向企业架构的进化，也就是对软件设计核心目标的认识，软件设计绝不是“先写了再说”，也不一定是越快越好；二是不同方法之间更明显的结合趋势，面向企业的软件设计是一个很复杂的事情，既然很难由某一个方法自己搞定，那就“抱团取暖”吧。

 

二、企业级业务架构（EBA）与“组合拳”

（一）关于EBA

上文谈到了架构演进的一个趋势，就是关注点从软件架构向企业架构的进化，这反映了技术在面对不断上升的业务复杂度时，对自身局限的认知。不深入了解业务和企业，就很难建立面向整个企业的系统规划，企业内部也就很难有效打通，事实上，比尔·盖茨先生1999年在《未来时速》中提出的为企业打造“数字神经”的想法，至今也还没能完全实现。

“数字神经”的打造跟理清企业架构是分不开的，如同给一个城市设计管道系统一样，它与城市的结构是要匹配和共同演进的。而企业架构中非常重要、技术人员又很难处理的，正是业务架构。业务架构在Zachman手中萌生，到TOGAF时明确，尽管那个定义还是挺难理解的。TOGAF将企业架构（EA）和业务架构（BA）都推向了一个新高度，并且给出了包含业务架构在内的著名的“4A”结构，但是其实施难度一直饱受争议，由于周期通常较长，分析业务架构能够投入的业务人员就是有限甚至很难保证的，当然，这与企业自身的实施决心也有关。

国外有些基于BA的成功案例，比如US Patent and Trademark Office（USPTO）于2013年启动了TMNG（TrademarkNext Generation）项目，按照BA方法梳理了企业层面的20多条价值链、19个1级能力、100余个2级能力，并按照能力复用等条件确定实施优先级，能力复用越多的，计划排期越靠前。TMNG项目持续5年，从第一年只能释放1组价值链环节，到第四年可以6组价值链环节同时实施，这一方面显示了对方法应用的熟练，另一方面也是来自于可复用能力的增加。

国内，建设银行是贯彻业务架构方法的典范。由于长期受到“竖井式”开发的影响，该行于2011年痛下决心启动了“新一代核心业务系统”转型工程，以企业级业务架构方法驱动IT开发转型，进而推动企业转型。工程实施时间长达6年，通过业务模型方法构建了全行统一的业务架构，梳理了20余个业务领域、80余个业务应用、100余个业务组件、900余个活动、4500余个任务、20000余个数据实体，规划了全行100余个新老系统的SOA风格改造，将整个企业连接起来。此后，工行、中行也都在近两年构建了自己的企业级业务架构模型。

综上，EBA其实对开发最大的指导作用在于它对业务的深刻理解、对企业整体性的解读与规划、对业务能力的聚类与组件的划分，从而使IT对业务的支持上升到合作、融合的高度而非原有的实现，它的作用其实更多还是在过程中，而非文字里。

笔者基于原有的工作经验，将EBA设计方法进一步改造为通用方法论，以期能够为更多领域的设计人员提供借鉴。EBA方法这两年有复兴之势，一方面是有建行这样的大型实施案例，另一方面也有来自阿里巴巴这样的互联网头部企业对业务架构的重视。如果再说更深层次的原因，也许是现在又到了一个“转型”的时期，互联网企业这类跨界竞争者对原有行业的巨大冲击，使大家认识到，未来企业都将会带有较强的科技属性，信息化将进入它自身的高级阶段，并逐渐走向数字化阶段。这样的“转型”时期需要已经不仅是“一招鲜吃遍天”的爆款产品，更重要是大多数传统企业需要首先完成自身的“科技化”改造，需要首先实现企业内部技术基因的增强，实现业务与技术的深度融合，这种转型非常需要EBA的支撑。提高企业的整体性正是EBA方法的强项，正如笔者在《企业级业务架构设计：方法论与实践》一书中对EBA的定义：“以实现企业战略为目标，对企业能力进行整体规划并将其传导到IT实现端的结构化分析方法”。

企业无分大小都有战略，都有架构，就算没有显性地表现出来，所以，各种规模的企业都可以尝试用EBA方法为自己诊脉，就算你没有最终将它应用于IT实现。笔者介绍的方法没有那么复杂，充分地认识自己不是坏事，正所谓“知己知彼，百战不殆”，毕竟，无论做不做系统开发，企业每发展到一定时间，总会积累些“管理债务”要去偿还，EBA本身也可以应用于“管理”上的重构。

EBA的一般设计过程如图6所示：

图6EBA设计的一般过程

EBA的整体逻辑如图7所示：

图7EBA的整体逻辑

如图8所示，EBA强调的是“知行合一”，强调企业自己对方法论的驾驭和对架构师的培养，未来的企业管理必然包含架构管理，企业管理追求的“韧性”很可能将来自于架构的“弹性”和演化能力。

图8业务架构的知行合一

EBA方法也是一个业务架构设计与IT实现之间不断迭代的过程，如图9所示：

图9 业务架构设计与IT实现的持续迭代过程

 

（二）EBA与DDD

方法之间的结合也是一个趋势，当然，结合是一件难度很高的事情，它的基本要求之一就是尝试结合者自己要对各个方法都有充分的了解和实践经验，并且能够让学习者可以掌握，因为对学习者而言，这意味着“1+1>2”的学习量。

EBA方法在形成业务架构解决方案之后，本身对IT实现端采用的方法没有特殊的限制性要求，这也意味着进入IT实现端的需求分析阶段后，可以尝试采用DDD方法进行细化设计，因为二者都注重数据与行为的结合，EBA方法是通过流程模型与数据模型的结合进行表达的，DDD的实体表达方式则更为直接；二者都强调通用语言，只是范围上，EBA是跨领域的通用语言，而DDD是限界上下文内部的通用语言；二者也都希望实现业务和技术两端都能理解的解决方案，也都非常关注业务含义对模型设计的影响。

但是二者也有区别，结合也有一些的困难要克服。一个比较直接的问题来自于数据模型，EBA方法注重对企业级数据模型的设计，企业级数据模型对数据治理有非常重要的作用，对大数据应用也有很直接的影响。数据模型通常的设计方式与DDD中对数据的处理有一些区别，二者在数据建模方面，对实体的定义有共同之处，比如应关注实体的业务含义，但是具体定义、实体大小的考量上，都会在实操层面有区别，而且，EBA方法比较提倡在企业层面的数据概念的抽象和统一，但是DDD是从领域出发考虑问题的，而且这个领域也不同于EBA中范围较大的领域概念，其限界上下文涵盖的范围可能很小，从而产生多个领域都有同名不同义的实体。

比如，Vaughn Vernon在《领域驱动设计精粹》一书第二章介绍的“保单”的例子，就是在承保、审核、理赔三个限界上下文中分别定义了“保单”实体，每个实体都有重复的部分和差异的部分，这样做的原因则是认为整合会造成一个过于臃肿的“超负荷”的“保单”实体。这样的实体也许大家在设计过程中也曾经遇到过，就是一个数据实体包含了过多的属性，导致数据层面没有很好地分离“关注点”。

Chris Richardson在《微服务架构设计模式》一书的第二章中也给出了一个通过DDD处理类似问题的例子，就是对“上帝类”的拆分，“上帝类”作为全局类，可以为多个不同领域的应用调用，因而也就设计了包含不同领域的状态和行为的复杂结构，比如书中提到的“Order（订单）”，下单、送餐、付款等多个领域都会触发订单状态的转换，如果将丰富的行为打包成一个中央Order数据库，会导致微服务设计方面出现“紧耦合”，微服务之间不够独立；如果只保留一个纯数据服务的Order Service，又会成为“贫血模型”。其解决之道同样也是在不同领域定义同名不同义的Order。

这两个例子其实体现了与EBA很不同的处理方式，EBA希望实现企业级的数据模型定义，也即，在企业级范围内尽可能消除同名不同义的数据实体，所以，“保单”、“订单”在EBA中通常会处理为一个而非多个实体，那么解决实体过于庞大的问题，还是要依靠对数据实体的业务含义、业务能力的识别，因为按照领域的拆分本身也会存在弊端，就是企业级数据查询与应用的困难。

对于Vernon举的例子，由于没有更多的信息，因此无法进行详细的比较，但是EBA的数据建模中，子实体的概念也可以满足不同领域的需要；Richardson举的Order的例子，在EBA方法中，很可能不会仅设计成一个庞大的Order实体，而是会拆分出客户、地址、付款单等多个数据实体，至于最后Order实体会剩多少个属性，就要看实际情况了。

但是Order这个例子中，更重要的一点是，EBA方法确实有可能会朝着设计一个中央Order数据库的方向前进，因为很可能将其定义为一个Order业务能力组件，供各类业务应用进行调用，这是企业级业务能力复用的一种体现。至于这个例子中，Richardson提到的“紧耦合”问题，其实并非是Order服务变动会引起其他服务变动，而是其他服务需要修改Order模式时，会引起Order服务变动，这在EBA中，也是会出现的问题，这个问题是要辩证的看，也即，在集中设计Order业务能力组件获得的好处和引起的耦合之间进行取舍。

综上，我们可以看到，EBA可以与DDD方法进行适当的结合，但是也有在数据模型、企业级抽象目标方面的矛盾，设计方法结合的实践者必须思考操作上需要注意的问题。

如果能够有效地实现EBA与DDD结合，那对于DDD而言，找到了从企业战略分解到DDD设计的整体引导方法；对于EBA而言， DDD则对提升组件或者构件的设计效率有一定帮助。这方面的结合已经有了不错的探索者，华为的朱如梦老师写过一篇专门探讨结合方式的文章《业务架构——跨领域的统一语言》，有兴趣的读者可以参阅。

 

（三）EBA与微服务

其实EBA与微服务之间，笔者觉得交集主要就是在软件架构设计上，说的更直接点儿就是服务拆分上。微服务在技术实现方面自有一套落地方法，而且有Netflix成功的大规模实践。尽管通讯机制导致的复杂性也让很多人头痛不已，但是相比服务拆分这种很难找到标准的事情，还是要相对好些，所以，微服务才出现了与DDD的结合，二者都是想在一个限界上下文中，找到能够适合为之设计独立数据库的一组行为。

EBA在落地层面也需要微服务这类可以提供较大灵活性、复用性、伸缩性的实施方式，如果结合的好，二者都能够相得益彰，EBA同样也可以解决服务划分问题，而且还附赠战略落地服务。EBA方法笔者在书中曾有个改良设计方法的建议，就是吸收2003年提出的构件理论在EBA解决方案中引入构件的概念，以“乐高”积木为目标设计功能模块，这些功能模块可以成为微服务设计中需要定义的服务。

微服务的局限性之一就是该方法比较适合重构，很难在一个系统的初期设计中找到合适的设计思路，因为，微服务事实上代表着对业务更深刻的理解和精炼，实际上，笔者提出的构件设计方式也很难用在系统的首次设计上，这一点二者倒是很相似。

说到二者的矛盾之处，主要也是操作层面，类似消除“上帝类”这种对企业级抽象的不同处理思路，微服务以追求服务尽可能高的“独立性”为目标，但是实践中，耦合通常都很难完全消除；EBA更看重的是对业务能力的聚类，尽管“高内聚、低耦合”也是其设计目标，但是聚类过程中，其实比微服务设计方式更容易出现耦合问题。对于真实开发工作而言，如何处理耦合问题还是要从实际出发，不能“一刀切”地论其好坏。

 

（四）EBA与敏捷开发

EBA与敏捷的关系，笔者在书中曾经论述过，主要是针对“敏捷宣言”的内容。按照多数读者的第一印象来讲，恐怕都会认为EBA这种“漫长”的实施过程与敏捷主张的开发过程“格格不入”，这一点在EBA首次设计时更为明显，坦白地讲，笔者并不认为这一阶段适合敏捷，因为认识和改变一个企业的整体架构，注定是一个需要深思熟虑的过程。

敏捷开发针对的是“瀑布模型”，但是EBA并非“瀑布模型”，它是一个对企业当前状态的刻画过程，是寻找企业战略落地措施的方法，应该说，二者是不同问题空间的解域，直接比较二者并不一定合适。

此外，敏捷开发崇尚的是“轻文档”而非“无文档”，Martin Fowler认为敏捷注重的是演进式设计，而不是轻视设计；Vernon也批评一些敏捷开发实践是用“任务板挪卡”代替了设计；Sutherland在“OODA”循环中也强调掌握全景信息而非只从自身视角看问题的重要性，每次Scrum结束提出MVP，都要重走一遍循环，因为MVP就是为了获得更多、更全的反馈信息，有了这些信息才能快速决策，快速决策绝非快拍脑袋，是因为有模式加速了对信息的处理速度，这才是敏捷的原动力，也是要总结方法论的原因，“全景信息+思维模式=快速决策”。

“OODA”循环如图10所示：

图10“OODA”循环（来自互联网）

与敏捷比，EBA确实是个“慢悠悠”的工作，思考的深度决定EBA的价值，因此，不给予充分的时间开展的EBA工作，无异于是在浪费时间。没必要试图用敏捷的思路去加速EBA过程，当今社会更缺乏的反倒是对企业级问题的“慢”思考。

EBA解决方案诞生后，敏捷方法可以用来促进EBA的落地过程吗？答案是肯定的，但是要让业务架构师参加到敏捷团队中，解释、修改EBA解决方案，这样才能确保实施团队充分理解作为实施前提的EBA解决方案。USPTO的例子也说明了EBA在确定任务优先级方面的作用，这点对敏捷而言也很重要。敏捷的周期很快，这也意味着，如果结合不好，那实施效果偏离原定解决方案的速度也会很快。

 

（五）小结：多歧路

EBA与“组合拳”的关系暂且论述到这里，总结一下：EBA最大的优势在于为“组合拳”提供企业层面的总体设计指引，这不是为了整体而整体，是为了实现整体性而整体，有了这个指引，才能更好地发挥“组合拳”的功效。但是，方法之间并非没有冲突，结合之路需要慎之又慎，如果我们当前无法像物理学家那样追逐“大一统理论”，那就让我们像Sutherland创立敏捷方法的初衷那样去实践，“当我着手开始建立Scrum时，并没有打算创造一套新的流程。我只是想汇总一下之前几十年里关于最佳工作方式的研究成果，看看都有哪些最佳做法，然后借鉴过来，效仿一下”，这其实是个很轻松的说法，知易行难。

 

三、聊聊中台

（一）“水深火热”的中台

“中台”概念的缘起大家都清楚，来自马云先生对一家欧洲游戏公司考察后的感悟，一个比喻。实践层面，钟华老师写的《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》是第一本比较完整地阐述阿里巴巴中台实践过程的著作，可以说是中台布道的开始吧，钟华老师如今仍在实践其理念。2019年中台可谓火的一塌糊涂，既有从原产地阿里巴巴出来的创业团队，也有将其原有实践简单包装冠以中台名号的“贴牌”者。

去年在的一次交流中，笔者曾经用Gartner曲线的形式，串起了与中台相关的书和文章，与参会者开了一个小小的玩笑，如图11所示：

图11中台曲线

彼时还没有那篇炸了圈儿的文章，笔者也无意将其补进去，毕竟这张图也只是个玩笑。任何技术形态都会经历这个历程，架构理念也不例外。有价值的自然会重新走回上升态势，哪怕是10年以后，或者像AI一样几起几落；没价值的也就寿终正寝了。Richardson 也说过：“人们往往容易被情绪因素所驱动，这也是为什么会有这么多关于技术的两极分化和过度粉饰的争论”。

中台就其设计理念而言，仍是为了有效降低系统设计复杂度、提升复用能力的企业架构方法。去年南京中台大会的闭门讨论中，主持人曾要求每位演讲嘉宾用一句话概括自己对中台的认知，笔者当时说的也是“跟我实践过的EBA相似，也只是一种架构方式”，确实，就目的而言，二者殊途同归，都是在考虑识别、沉淀企业的业务能力，将其模块化、服务化之后，更好地支持业务变化。

EBA与中台的差别，在实操层面也许主要是EBA并未考虑要将沉淀的业务能力剥离为中台层，因为EBA主张企业级复用，从这个角度讲，也不需要单独进行一个特殊的表达。EBA形成的业务组件之间按照调用的频率也可以适当进行分层，但这种分层结果并非现在中台的含义。除此之外，中台目前对企业战略如何分解落地也没有很详细的解释方法。

阿里巴巴也是业务架构理念的实践者，业务架构根据其设计范围可以区分为领域级和企业级，阿里巴巴对业务架构的应用，从其自身披露信息来看比较侧重于领域级，业务架构师按领域配置和开展工作。当然，设计发展到一定程度，总是会自然关注到企业级。

对中台的探索，笔者认为仍然值得开展下去，无论它以后还叫不叫中台，这是对架构设计理念的探索。从阿里巴巴的角度看，也是他们在技术底层实践越来越成熟之后，对上层设计的必然追求。笔者也不太赞同按照企业规模去给中台划个准入门槛，毕竟企业无分大小，只要系统建到一定规模或者数量，时间累积到一定程度，总有“技术债务”要还，总有重构的十足理由，那么作为一种架构设计理念去应用中台方法，未尝不可。如果说到成本，规模小的企业当然不必仿照阿里巴巴的方式构建昂贵的基础设施，设备成本是由系统的非功能性需求决定的，与企业的规模、财务能力也是匹配的，所谓中台烧钱，可能主要是想照搬阿里的技术方案造成的吧。抛开这个，它与一般的重构相比，是否真的会大幅度提高重构成本，笔者还是怀疑的。至于进行业务梳理的成本，只要企业想改革，这个成本无论用任何方法都是要付出的。

玄难和毗卢离职前，阿里的中台计划取名为“星环”，据说名称创意来自于刘慈欣老师的《三体》，是那艘超光速飞船的名字，对于快的追求不言而喻。但是从笔者的角度来看，倒是更喜欢美剧《无垠太空》中的“星环”，每个“星环”都是通向一个世界入口。企业自建中台需要自身的沉淀，中台产品提供商则需要行业沉淀，现实中，还需要对行业中处于不同位置或者细分领域的客户进行不同分类的沉淀，如此看，中台就像“星环”一样，是通向不同世界的入口。如果愿意再揶揄一下，走进入口，遇见的可能是“天堂”，也可能是“地狱”。

EBA也可以成为“星环”，道理是一样的。通过EBA也可以不断积累对行业或者细分领域的模型，这些模型不仅对架构设计者有所帮助，而且可能是未来走向自动化设计、AI设计的必经之路，因为AI也需要架构数据的供给才能产生设计能力，而目前架构领域连案例都经常是语焉不详、光怪陆离，更不说积累数据了。

 

（二）中台与“组合拳”

其实中台与“组合拳”的关系，阿里巴巴的人自己出来多讲讲会更好。从笔者的了解来看，阿里巴巴的中台实践中，“组合拳”的应用是不少的，他们的特点是一般不会强制团队使用某种方法。微服务显然是广泛使用的，敏捷开发、DDD在不同的团队中也都有应用，但是，应该不是每个团队在每次开发中都采用这些方法。

阿里巴巴的中台，据说在大规模构建之前面对的问题之一就是企业已经有上万个微服务，每次承接新需求都可能有数百个微服务受到波及，而服务数量如此之多，以至于没有人能搞清楚业务能力到底有哪些、是如何分布的，所以，搞起了业务架构，分离业务领域，理清不同领域的业务模式，再沉淀业务能力，形成中台。微服务是中台在技术层面落地的方式之一，但是中台设计要有效地为微服务的划分提供指导，并从架构层面提供业务能力的可视化，进而支持业务能力的持续优化，通过架构演进指导微服务的设计与变化。微服务则在技术落地上提升对业务能力的运维支持，提供良好的升级维护和可扩展性。

在分离业务领域方面，DDD方法也有一定范围的使用，毕竟这种方法与微服务的结合被广泛传说，而且DDD的思维方式就是侧重对限界上下文的分离，以达到在同一个限界上下文内对同一业务概念理解上的一致。每年Thoughtworks的大会上，也都有阿里人来分享应用DDD的经验。至于敏捷开发，更是常被当作互联网企业的标配。

中台跟“组合拳”的关系，其实也应该类似于本文第二部分中讨论的EBA跟“组合拳”的关系，只是现有的信息中，中台并没有像EBA那样给出一个明确的设计过程和方法，所以，分析也很难做的更深入，这并不是对着几张漂亮的架构图就可以做的比较。

 

（三）特化与泛化

笔者从各种交流，包括对笔者文章的留言中，也能感受到，中台面临的一个问题就是领域的积累达到一定程度之后，必须从企业层面去思考问题。所谓的做中台以支持业务的灵活变化，那到底业务是什么？到底是支持需求还是支持业务？技术人员到底理不理解业务？需要理解到什么程度？需求到底是来自业务人员的还是来自真实客户的？说到底，就是技术到底怎么支持业务，其实这样说还是有些“见外”，应该说，技术到底怎么跟业务融合。

这波对中台的争论，也反映了对阿里中台的一个认知问题，它到底是个特化的方法还是泛化的方法。

从阿里自身看，这首先是一个特化的方法，理由不难理解，他们要梳理自身过于复杂的微服务实现状况，要支持业务端给数千万商户提供的千变万化的营销、管理手段，要面对复杂的商业生态和大量的不确定性，应对每年“双十一”独步全球的高并发环境，应对互联网领域“唯快不破”的残酷竞争，还要应对大量的技术“无人区”，这样可谓“极端”生存环境下产生的方法，一定是个“特化”的方法。其实每个方法诞生之初都是“特化”的，面对的环境越极端，方法的特化性相应也越强，阿里的中台也理应属于这种情况。

但是大家需要的是一个泛化的方法，这就需要首先解释清楚方法的特化之处，考虑清楚对特化的处理，才能实现泛化的目标。作为一个局外人来看，笔者建议，把阿里中台方法中的各种武器首先拆分清楚来看，先不要抱着“要要要”、“买买买”的想法，而是搞清楚武器之间的关系和成本，应用的前提条件和最适宜解决的问题，再对号入座，实现“客户化”过程。比如，业务能力梳理方法、组织结构是不是直接对标阿里（阿里可是经常变的）、微服务要不要搞、阿里技术栈选用哪些、需要全链路压测吗等等之类的问题。一个泛化的方法在应用过程中还是会再经历一次本地的特化，尤其是中台、EBA之类的企业级方法，这也代表需要足够的时间和成本。“九尺之台，起于垒土”，中台的构建，也少不了“搬砖”的过程。

对于做中台产品的服务提供商而言，应当把中台认真当成一个软件工程方法看待，把其中的组成要素、软件过程、可选方案都研究明白，“工欲善其事必先利其器”，这是对工匠的基本要求。对于这些厂商而言，帮助客户搞清楚自己要的到底是特化的阿里中台还是泛化的中台，是很重要的。泛化的中台意味着要根据客户的实际情况决定中台的实施目标，而非靠“对标”的方式预先诱导实施目标，后者销售的意味太过强烈。当然，这种情况不只中台有，但凡商业化的东西，都有这个问题，说“酒香不怕巷子深”的越来越少了。

中台说到底也是一个技术怎样与业务融合的问题，看到了一个有成功实践做背书的技术理念，但是套用到自家业务实践上，却发现“知行合一”远非易事。

 

四、开放式架构

架构的演进随着信息化程度的加深和越来越多的优秀从业者的加入而逐渐变得更加有趣、更加复杂，从“先写了再说”到工程化的引入，从关注软件自身到关注企业，问题空间越来越大，越来越复杂，对解域空间的要求也不断上升。笔者通过前文，在回顾软件工程和企业架构发展过程的基础上，总结了两个架构演进趋势：从软件架构到企业架构、从单一方法到“组合拳”，并通过对EBA和中台的分析，对方法之间的差异比较与结合进行了论述。本处打算再简单讨论下第三个趋势：从内部架构到开放式架构。

银行是信息化起步较早的行业，而且大型银行组织结构复杂、技术开发投入高、应用范围大，在架构发展历程上，很具有代表性，国内银行在架构方面的发展历程如图11所示：

图11架构演进趋势

上世纪80年代后半期银行刚开始引入主机系统，此时构建的业务系统是“高度”分散的，每个地级市都有自己的业务系统，不同城市之间业务也是无法联通的，一笔汇款业务，现在是实时转账，零级清算、秒级到账，但是在那个时候是多级清算，跨地区汇款是从一个城市的网点到自己的市分行，市分行到省分行，省分行到总行，总行到目标地的省分行，省分行到市分行，市分行到网点，在地区割裂的情况下会是个什么效率，大家可想而知。到了90年代末，随着计算机性能的提升和网络的发展，数据集中的需求越来越强烈，有数据集中才能有业务集中，大集中架构拉开帷幕，大集中可以构建全行统一的业务系统，业务效率的提升是不言而喻的，但是由此带来的问题也逐渐显露，就是“竖井式”开发的问题。2011年，建行首先开始企业级转型，设计全行统一的企业级架构，包括企业级业务架构和7层12P的企业级系统架构，工程于2017年结束，内部一体化初步完成。

但是架构的演进不会就此打住，内部统一之后，更重要的就是适应面向数字化时代的开放与融合要求，深度参与到生态建设中，架构发展的下一阶段自然就是开放式架构，真正从社会分工、生态分工的角度，结合生态伙伴、客户的情况，综合分析架构解决方案。其设想如图12所示：

图12开放式架构理念演示图

数字社会必定是一个与今日大不相同的“新时代”，所有参与者都将迎来一个转型过程，无论是企业还是个人。虽然转型是渐进式的，但是准备自然要从现在开始做起，对于企业而言，架构“新时代”的到来是注定的，而这个“新时代”一定是业务架构与技术架构、业务与技术深度融合的时代，无论是EBA还是中台，都有机会在这个进程中扮演重要的角色，道路是漫长、曲折甚至孤独的，敢于在这条路上探索的都是勇士。

 

---

=>更多文章请参考：《中国互联网业务研发体系架构指南》

=>更多行业权威架构案例及领域标准、技术趋势请关注微信公众号：

更多权威内容关注公众号：软件真理与光