不止中台：全面的架构演进趋势和方法

小编按：

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

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

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

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

一、软件工程与企业架构

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

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

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

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

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

表1  Zachman模型简介

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

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

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

表2  TOGAF交付物示意

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

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

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

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

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

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

图6 EBA设计的一般过程

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

图8 业务架构的知行合一

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

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

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

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

（五）小结：多歧路

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

三、聊聊中台

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

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

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

图11 架构演进趋势

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

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

文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树人工智能机器学习工具包Scikit-learn211379 人正在系统学习中