（五）小结：多歧路

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

三、聊聊中台

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

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

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

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

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

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

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

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

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

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

（二）中台与“组合拳”

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

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

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

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

（三）特化与泛化

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

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

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

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

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

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

 

四、开放式架构

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

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

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

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

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