小编按：付老师这篇一万四千字的长文，有不少独创性的远见卓识。比方中台施行组合拳，不拘泥一家；EBA vs DDD 等。在十万加爽文式快餐浏览更容易被 follow 的时代，本文重发，谨以此献给能读懂或者打算读懂的读者们。毕竟业余畛域是有浏览门槛的。
应技术琐话之约，试图写一篇探讨架构方法论的文章，然而动笔之后，才发现，本人仿佛陷入了 Frederick P. Brooks 学生在《设计本来》一书中指出的问题：“设计中最艰难的局部在于决定要设计什么”。
2020 年 1 月 18 日，有人戏称是“中台”历史上最“艰难”的一天，一篇炸圈的文章将对“中台”的探讨又一次推向高点，尽管“泼冷水”的象征十足。其实笔者之前也谈到过，“中台”自诞生伊始就非一个谨严的定义，而是一种比喻，比喻当然也就容易导致争论不休，“中台”当初面临的问题其实也和笔者入手写这篇文章面对的问题差不多。然而，将“中台”实践一直明晰化的尝试仍是个好事件，毕竟，这是国内企业掀起的一次对架构设计办法的无益摸索。
笔者在 2019 年 11 月南京中台大会上也曾讲到，现在很多畛域都在谈国产化、自主可控，架构畛域难道不须要吗？架构畛域方法论的继续欠缺、国产实践的继续翻新，是驾驭技术组合的要害，底层技术的一直自主化并不会必然带来顶层设计能力的自主化，而数字化转型，除了须要底层技术的撑持外，卓越的下层设计更是重中之重。走出有中国特色的数字化路线，底层技术能力与下层设计能力缺一不可。
对企业级软件架构设计办法的钻研须要所有人独特关注，它是在继续进化的，也是将来企业走向数字化过程中，实现业务与技术深度交融的必经之路。Brooks 学生在同一本书还提到：“好的设计者应该投入大量精力来学习判例……但古代设计匆忙的节奏却对这种实现十分不利”，他写下此语是在 10 年前，明天，这种状况只能说是有过之而无不及吧。
探讨架构问题永远是艰难的，尽管笔者能力无限，然而出于对架构实践的喜好，还是尝试通过本文与各位读者独特探讨架构办法的演进与改进。
一、软件工程与企业架构
1.1 糊涂的晚期：没有工程、没有架构
架构设计是随着软件复杂度的回升而真正受到人们器重的。1946 年，微小的电子管计算机 ENIAC 诞生，软件行业的帷幕拉开，然而尔后十几年的工夫里，软件设计都只是多数人的事件，这个行业大部分工夫都在实验室中倒退。尽管高级语言呈现，然而大多数程序设计人员的次要武器是汇编语言。模块化的思路逐步呈现，然而软件过程治理是很原始的，也没有所谓的架构设计办法，风行的就是“先写了再说”。
1.2 办法的开始：瀑布模型和 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 并没有给出一个具体的构建办法。
1.3 成熟的提高：螺旋模型和 TOGAF
1988 年，软件工程上又一个里程碑式的办法诞生了，Barry Boehm 提出了“螺旋模型”，该模型如图 2 所示：
图 2 螺旋模型
螺旋模型通过继续对原型进行验证式、增量交付的形式，补救“瀑布模型”在需要治理方面有余，是一种对需要的渐进式摸索，也增强了对项目风险的治理。Brooks 在 2010 年著书时仍对该模型赞叹有加。
随着信息化水平的加深，企业越发意识到将 IT 融入企业治理的重要性，IT 人员也意识到与业务联合的重要性，于是，1995 年 TOGAF（The OpenGroup Architecture Framework，凋谢组体系结构框架）应运而生，业务架构的概念也被明确提出来。
TOGAF 认为企业架构分为业务架构和 IT 架构两大部分，业务架构是把企业的业务策略转化为日常运作的渠道，业务策略决定业务架构，它包含业务的经营模式、流程体系、组织构造、地区散布等内容，业务架构再作用于 IT 实现。TOGAF 的设计交付物如表 2 所示：
表 2 TOGAF 交付物示意
能够看出，到 TOGAF 时代，在内容上，企业架构和业务架构倒退的曾经较为欠缺了；在工艺上，TOGAF 也有明确的操作要求，也正是因为有具体的要求，TOGAF 被公认的毛病之一就是太“重”，有点像是架构畛域的“瀑布模型”。
从 Zachman 到 TOGAF，只管实践日臻成熟，然而企业架构设计与理论开发过程之间的联合始终不是很好，更像是在两条线上倒退，外表看起来，Zachman 模型仿佛还能跟“瀑布模型”走失去一起，毕竟二者都被认为是“漫长”的，但大部分开发实际上在这个期间都是沿着“竖井式”的路线在走，仍旧不足对企业级设计的关怀。至于 TOGAF，它跟螺旋模型、迭代模型之间在实操上有不易联合之嫌，恐怕不少企业承受了利用 TOGAF 思路的征询计划，却在施行过程中将其束之高阁了。尽管如此，TOGAF 对推动企业架构倒退的作用仍是十分大的。
1.4 对更快的摸索：麻利开发、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 畛域模型示例（来自互联网）
EricEvans 曾提出该办法次要面向麻利过程，二者其实在办法层面有相似之处，都强调疾速由需要进入开发过程，也都重视对模式的使用。然而因为 DDD 办法把握起来有肯定难度，因而并没有真的随着麻利开发“火”起来，倒是借了另一种架构格调的“东风”，微服务。
微服务最早由 Martin Fowler 与 James Lewis 于 2014 年独特提出，微服务架构格调重视用具备独立数据库的微服务来代替原有的单体利用设计形式，每个微服务运行在本人的过程中，并应用轻量级机制通信，通常是 Restful API。这些服务基于业务能力构建，并可能通过自动化部署机制来独立部署，服务能够应用不同的编程语言实现，以及不同数据存储技术，并放弃最低限度的集中式治理。从理念上看，极具灵活性、疾速响应能力、可复用性和扩展性，案例上更是有传奇公司 Netflix 做标杆。
然而这种架构格调并没有很好地解决它的前身 SOA 遗留的问题，就是如何确定服务的颗粒度，于是，不温不火快 10 年的 DDD 派上用场了。DDD 这种能够间接依照限界上下文导出数据和行为相结合的设计后果的办法，很适宜推微服务一把。Chris Richardson 在其著述《微服务架构设计模式》一书中就专门花了两章来介绍 DDD 与微服务的联合。
在对更快的摸索中，麻利开发、DDD 和微服务提供了一种包含软件过程、架构设计和工程实现在内的“组合拳”，当然，这并不意味着所有企业都要这么用，只是一种参考而已。此外，求快的同时，这些办法也都欠缺对企业架构的关注，它们都是能够晋升 IT 开发效力的无力工具，然而，在 To B 端，仍须要一种能够面向企业级能力建设的办法作为总体导引。
1.5 小结：行路难
架构设计的思路到上个世纪 70 年代才逐步开始倒退进去，软件行业心愿也能像工业、建筑业一样具备行业级的设计准则、规范，从而使高质量软件的产出失去保障。然而，到目前为止，架构之路殊为不易，还没有哪种办法升华为举世公认的准则或者楷模。
软件工程到明天才算年过半百，还是个比拟年老的畛域。从“瀑布模型”进化到“螺旋模型”大概用了 20 年；麻利开发快 20 岁了，DDD 也有 17 岁；微服务尽管很年老，才 5 岁，然而它的前身 SOA 是 1996 年诞生的。企业架构从 Zachman 模型诞生到当初是 33 岁，而 TOGAF 到当初也就 25 岁，只相当于软件工程的一半年纪。如此说来，这些办法以其要服务的指标畛域而言，都还是只是刚刚进入“青年”这个程度。
然而上述办法咱们至今仍在对其某一方面大加挞伐，没有一个是“银弹”，没有一个未曾被人骂做“坑”。然而贵在摸索和保持，这些办法经验工夫的洗礼，仍未褪去“稚嫩”，仍须要“呵护”与重复实际能力健康成长。
古代社会的快节奏对架构的积攒的确是一个挑战，“快”本来应该是指标，而今成了办法。咱们对很多架构办法的了解尚不深刻，对其利用也须要对办法创立者的初衷深加领会，比方，麻利办法的创始人、“麻利宣言”起草者之一的 Jeff Sutherland 在《麻利反动》一书中提到其灵感起源的“OODA”办法，倡议在每个冲刺中都要残缺应用，但在各类麻利书籍中却鲜有提及；Vernon 也提到，无论是对麻利办法还是对 DDD 而言，“常识获取”都至关重要，然而“常识获取”显然须要积攒；即使是对口诛笔伐的“瀑布模型”，也一样存在泛滥误会。
抛去这些争议不谈，咱们至多能够从软件工程与企业架构的倒退历程中看到这样两个个趋势：一是关注点从软件架构向企业架构的进化，也就是对软件设计外围指标的意识，软件设计绝不是“先写了再说”，也不肯定是越快越好；二是不同办法之间更显著的联合趋势，面向企业的软件设计是一个很简单的事件，既然很难由某一个办法本人搞定，那就“抱团取暖”吧。
二、企业级业务架构（EBA）与“组合拳”
2.1 对于 EBA
上文谈到了架构演进的一个趋势，就是关注点从软件架构向企业架构的进化，这反映了技术在面对一直回升的业务复杂度时，对本身局限的认知。不深刻理解业务和企业，就很难建设面向整个企业的零碎布局，企业外部也就很难无效买通，事实上，比尔·盖茨学生 1999 年在《将来时速》中提出的为企业打造“数字神经”的想法，至今也还没能齐全实现。
“数字神经”的打造跟理清企业架构是分不开的，如同给一个城市设计管道零碎一样，它与城市的构造是要匹配和独特演进的。而企业架构中十分重要、技术人员又很难解决的，正是业务架构。业务架构在 Zachman 手中萌发，到 TOGAF 时明确，只管那个定义还是挺难了解的。TOGAF 将企业架构（EA）和业务架构（BA）都推向了一个新高度，并且给出了蕴含业务架构在内的驰名的“4A”构造，然而其施行难度始终饱受争议，因为周期通常较长，剖析业务架构可能投入的业务人员就是无限甚至很难保障的，当然，这与企业本身的施行信心也无关。
国外有些基于 BA 的胜利案例，比方 US Patent and Trademark Office（USPTO）于 2013 年启动了 TMNG（Trademark Next 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 所示：
图 6 EBA 设计的个别过程
EBA 的整体逻辑如图 7 所示：
图 7 EBA 的整体逻辑
如图 8 所示，EBA 强调的是“知行合一”，强调企业本人对方法论的驾驭和对架构师的造就，将来的企业治理必然蕴含架构治理，企业治理谋求的“韧性”很可能将来自于架构的“弹性”和演变能力。
图 8 业务架构的知行合一
EBA 办法也是一个业务架构设计与 IT 实现之间一直迭代的过程，如图 9 所示：
图 9 业务架构设计与 IT 实现的继续迭代过程
2.2 EBA 与 DDD
办法之间的联合也是一个趋势，当然，联合是一件难度很高的事件，它的根本要求之一就是尝试联合者本人要对各个办法都有充沛的理解和实践经验，并且可能让学习者能够把握，因为对学习者而言，这意味着“1+1>2”的学习量。
EBA 办法在造成业务架构解决方案之后，自身对 IT 实现端采纳的办法没有非凡的限制性要求，这也意味着进入 IT 实现端的需要分析阶段后，能够尝试采纳 DDD 办法进行细化设计，因为二者都重视数据与行为的联合，EBA 办法是通过流程模型与数据模型的联合进行表白的，DDD 的实体表达方式则更为间接；二者都强调通用语言，只是范畴上，EBA 是跨畛域的通用语言，而 DDD 是限界上下文外部的通用语言；二者也都心愿实现业务和技术两端都能了解的解决方案，也都十分关注业务含意对模型设计的影响。
然而二者也有区别，联合也有一些的艰难要克服。一个比拟间接的问题来自于数据模型，EBA 办法重视对企业级数据模型的设计，企业级数据模型对数据治理有十分重要的作用，对大数据利用也有很间接的影响。数据模型通常的设计形式与 DDD 中对数据的解决有一些区别，二者在数据建模方面，对实体的定义有共同之处，比方应关注实体的业务含意，然而具体定义、实体大小的考量上，都会在实操层面有区别，而且，EBA 办法比拟提倡在企业层面的数据概念的形象和对立，然而 DDD 是从畛域登程思考问题的，而且这个畛域也不同于 EBA 中范畴较大的畛域概念，其限界上下文涵盖的范畴可能很小，从而产生多个畛域都有同名不同义的实体。
比方，Vaughn Vernon 在《畛域驱动设计精粹》一书第二章介绍的“保单”的例子，就是在承保、审核、理赔三个限界上下文中别离定义了“保单”实体，每个实体都有反复的局部和差别的局部，这样做的起因则是认为整合会造成一个过于臃肿的“超负荷”的“保单”实体。这样的实体兴许大家在设计过程中也已经遇到过，就是一个数据实体蕴含了过多的属性，导致数据层面没有很好地拆散“关注点”。
ChrisRichardson 在《微服务架构设计模式》一书的第二章中也给出了一个通过 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 则对晋升组件或者构件的设计效率有肯定帮忙。这方面的联合曾经有了不错的探索者，华为的朱如梦老师写过一篇专门探讨联合形式的文章《业务架构——跨畛域的对立语言》，有趣味的读者能够参阅。
2.3 EBA 与微服务
其实 EBA 与微服务之间，笔者感觉交加次要就是在软件架构设计上，说的更间接点儿就是服务拆分上。微服务在技术实现方面自有一套落地办法，而且有 Netflix 胜利的大规模实际。只管通信机制导致的复杂性也让很多人头痛不已，然而相比服务拆分这种很难找到规范的事件，还是要绝对好些，所以，微服务才呈现了与 DDD 的联合，二者都是想在一个限界上下文中，找到可能适宜为之设计独立数据库的一组行为。
EBA 在落地层面也须要微服务这类能够提供较大灵活性、复用性、伸缩性的施行形式，如果联合的好，二者都可能井水不犯河水，EBA 同样也能够解决服务划分问题，而且还附赠策略落地服务。EBA 办法笔者在书中曾有个改进设计办法的倡议，就是排汇 2003 年提出的构件实践在 EBA 解决方案中引入构件的概念，以“乐高”积木为指标设计功能模块，这些功能模块能够成为微服务设计中须要定义的服务。
微服务的局限性之一就是该办法比拟适宜重构，很难在一个零碎的初期设计中找到适合的设计思路，因为，微服务事实上代表着对业务更粗浅的了解和精炼，实际上，笔者提出的构件设计形式也很难用在零碎的首次设计上，这一点二者倒是很类似。
说到二者的矛盾之处，次要也是操作层面，相似打消“上帝类”这种对企业级形象的不同解决思路，微服务以谋求服务尽可能高的“独立性”为指标，然而实际中，耦合通常都很难齐全打消；EBA 更看重的是对业务能力的聚类，只管“高内聚、低耦合”也是其设计指标，然而聚类过程中，其实比微服务设计形式更容易呈现耦合问题。对于实在开发工作而言，如何解决耦合问题还是要从理论登程，不能“一刀切”地论其好坏。
2.4 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 在确定工作优先级方面的作用，这点对麻利而言也很重要。麻利的周期很快，这也意味着，如果联合不好，那施行成果偏离原定解决方案的速度也会很快。
2.5 小结：多歧路
EBA 与“组合拳”的关系暂且阐述到这里，总结一下：EBA 最大的劣势在于为“组合拳”提供企业层面的总体设计指引，这不是为了整体而整体，是为了实现整体性而整体，有了这个指引，能力更好地施展“组合拳”的效用。
然而，办法之间并非没有抵触，联合之路须要慎之又慎，如果咱们以后无奈像物理学家那样追赶“大一统实践”，那就让咱们像 Sutherland 创建麻利办法的初衷那样去实际，“当我着手开始建设 Scrum 时，并没有打算发明一套新的流程。我只是想汇总一下之前几十年里对于最佳工作形式的研究成果，看看都有哪些最佳做法，而后借鉴过去，效仿一下”，这其实是个很轻松的说法，知易行难。
三、聊聊中台
3.1“生灵涂炭”的中台
“中台”概念的缘起大家都分明，来自马云学生对一家欧洲游戏公司考查后的感悟，一个比喻。实际层面，钟华老师写的《企业 IT 架构转型之道：阿里巴巴中台战略思想与架构实战》是第一本比拟残缺地论述阿里巴巴中台实际过程的著述，能够说是中台布道的开始吧，钟华老师现在仍在实际其理念。2019 年中台堪称火的一塌糊涂，既有从原产地阿里巴巴进去的守业团队，也有将其原有实际简略包装冠以中台名号的“贴牌”者。
去年在的一次交换中，笔者已经用 Gartner 曲线的模式，串起了与中台相干的书和文章，与参会者开了一个小小的玩笑，如图 11 所示：
图 11 中台曲线
彼时还没有那篇炸了圈儿的文章，笔者也无心将其补进去，毕竟这张图也只是个玩笑。任何技术状态都会经验这个历程，架构理念也不例外。有价值的天然会从新走回回升态势，哪怕是 10 年当前，或者像 AI 一样几起几落；没价值的也就死于非命了。Richardson 也说过：“人们往往容易被情绪因素所驱动，这也是为什么会有这么多对于技术的两极分化和适度掩饰的争执”。
中台就其设计理念而言，仍是为了无效升高零碎设计复杂度、晋升复用能力的企业架构办法。去年南京中台大会的闭门探讨中，主持人曾要求每位演讲嘉宾用一句话概括本人对中台的认知，笔者过后说的也是“跟我实际过的 EBA 类似，也只是一种架构形式”，的确，就目标而言，二者必由之路，都是在思考辨认、积淀企业的业务能力，将其模块化、服务化之后，更好地反对业务变动。
EBA 与中台的差异，在实操层面兴许次要是 EBA 并未思考要将积淀的业务能力剥离为中台层，因为 EBA 主张企业级复用，从这个角度讲，也不须要独自进行一个非凡的表白。EBA 造成的业务组件之间依照调用的频率也能够适当进行分层，但这种分层后果并非当初中台的含意。除此之外，中台目前对企业策略如何合成落地也没有很具体的解释办法。
阿里巴巴也是业务架构理念的实践者，业务架构依据其设计范畴能够辨别为畛域级和企业级，阿里巴巴对业务架构的利用，从其本身披露信息来看比拟侧重于畛域级，业务架构师按畛域配置和发展工作。当然，设计倒退到肯定水平，总是会天然关注到企业级。
对中台的摸索，笔者认为依然值得发展上来，无论它当前还叫不叫中台，这是对架构设计理念的摸索。从阿里巴巴的角度看，也是他们在技术底层实际越来越成熟之后，对下层设计的必然谋求。笔者也不太同意依照企业规模去给中台划个准入门槛，毕竟企业无分大小，只有零碎建到肯定规模或者数量，工夫累积到肯定水平，总有“技术债权”要还，总有重构的十足理由，那么作为一种架构设计理念去利用中台办法，未尝不可。
如果说到老本，规模小的企业当然不用仿照阿里巴巴的形式构建低廉的基础设施，设施老本是由零碎的非功能性需要决定的，与企业的规模、财务能力也是匹配的，所谓中台烧钱，可能次要是想照搬阿里的技术计划造成的吧。抛开这个，它与个别的重构相比，是否真的会大幅度提高重构老本，笔者还是狐疑的。至于进行业务梳理的老本，只有企业想改革，这个老本无论用任何办法都是要付出的。
玄难和毗卢到职前，阿里的中台打算取名为“星环”，据说名称创意来自于刘慈欣老师的《三体》，是那艘超光速飞船的名字，对于快的谋求显而易见。然而从笔者的角度来看，倒是更喜爱美剧《无垠太空》中的“星环”，每个“星环”都是通向一个世界入口。企业自建中台须要本身的积淀，中台产品提供商则须要行业积淀，事实中，还须要对行业中处于不同地位或者细分畛域的客户进行不同分类的积淀，如此看，中台就像“星环”一样，是通向不同世界的入口。如果违心再揶揄一下，走进入口，遇见的可能是“地狱”，也可能是“天堂”。
EBA 也能够成为“星环”，情理是一样的。通过 EBA 也能够一直积攒对行业或者细分畛域的模型，这些模型不仅对架构设计者有所帮忙，而且可能是将来走向自动化设计、AI 设计的必经之路，因为 AI 也须要架构数据的供应能力产生设计能力，而目前架构畛域连案例都常常是语焉不详、斑驳陆离，更不说积攒数据了。
3.2 中台与“组合拳”
其实中台与“组合拳”的关系，阿里巴巴的人本人进去多讲讲会更好。从笔者的理解来看，阿里巴巴的中台实际中，“组合拳”的利用是不少的，他们的特点是个别不会强制团队应用某种办法。微服务显然是宽泛应用的，麻利开发、DDD 在不同的团队中也都有利用，然而，应该不是每个团队在每次开发中都采纳这些办法。
阿里巴巴的中台，据说在大规模构建之前面对的问题之一就是企业曾经有上万个微服务，每次承接新需要都可能有数百个微服务受到波及，而服务数量如此之多，以至于没有人能搞清楚业务能力到底有哪些、是如何散布的，所以，搞起了业务架构，拆散业务畛域，理清不同畛域的业务模式，再积淀业务能力，造成中台。微服务是中台在技术层面落地的形式之一，然而中台设计要无效地为微服务的划分提供领导，并从架构层面提供业务能力的可视化，进而反对业务能力的继续优化，通过架构演进领导微服务的设计与变动。微服务则在技术落地上晋升对业务能力的运维反对，提供良好的降级保护和可扩展性。
在拆散业务畛域方面，DDD 办法也有肯定范畴的应用，毕竟这种办法与微服务的联合被宽泛传说，而且 DDD 的思维形式就是偏重对限界上下文的拆散，以达到在同一个限界上下文内对同一业务概念了解上的统一。每年 Thoughtworks 的大会上，也都有阿里人来分享利用 DDD 的教训。至于麻利开发，更是常被当作互联网企业的标配。
中台跟“组合拳”的关系，其实也应该相似于本文第二局部中探讨的 EBA 跟“组合拳”的关系，只是现有的信息中，中台并没有像 EBA 那样给出一个明确的设计过程和办法，所以，剖析也很难做的更深刻，这并不是对着几张丑陋的架构图就能够做的比拟。
3.3 特化与泛化
笔者从各种交换，包含对笔者文章的留言中，也能感触到，中台面临的一个问题就是畛域的积攒达到肯定水平之后，必须从企业层面去思考问题。所谓的做中台以反对业务的灵便变动，那到底业务是什么？到底是反对需要还是反对业务？技术人员到底理不了解业务？须要了解到什么水平？需要到底是来自业务人员的还是来自实在客户的？说到底，就是技术到底怎么反对业务，其实这样说还是有些“见外”，应该说，技术到底怎么跟业务交融。
这波对中台的争执，也反映了对阿里中台的一个认知问题，它到底是个特化的办法还是泛化的办法。
从阿里本身看，这首先是一个特化的办法，理由不难理解，他们要梳理本身过于简单的微服务实现情况，要反对业务端给数千万商户提供的变幻无穷的营销、管理手段，要面对简单的商业生态和大量的不确定性，应答每年“双十一”独步寰球的高并发环境，应答互联网畛域“唯快不破”的残暴竞争，还要应答大量的技术“无人区”，这样堪称“极其”生存环境下产生的办法，肯定是个“特化”的办法。其实每个办法诞生之初都是“特化”的，面对的环境越极其，办法的特化性相应也越强，阿里的中台也理当属于这种状况。
然而大家须要的是一个泛化的办法，这就须要首先解释分明办法的特化之处，思考分明对特化的解决，能力实现泛化的指标。作为一个局外人来看，笔者倡议，把阿里中台办法中的各种武器首先拆分分明来看，先不要抱着“要要要”、“买买买”的想法，而是搞清楚武器之间的关系和老本，利用的前提条件和最合适解决的问题，再对号入座，实现“客户化”过程。比方，业务能力梳理办法、组织构造是不是间接对标阿里（阿里可是常常变的）、微服务要不要搞、阿里技术栈选用哪些、须要全链路压测吗等等之类的问题。一个泛化的办法在利用过程中还是会再经验一次本地的特化，尤其是中台、EBA 之类的企业级办法，这也代表须要足够的工夫和老本。“九尺之台，起于垒土”，中台的构建，也少不了“搬砖”的过程。
对于做中台产品的服务提供商而言，该当把中台认真当成一个软件工程办法对待，把其中的组成因素、软件过程、可选计划都钻研明确，“工欲善其事必先利其器”，这是对工匠的根本要求。对于这些厂商而言，帮忙客户搞清楚本人要的到底是特化的阿里中台还是泛化的中台，是很重要的。泛化的中台意味着要依据客户的理论状况决定中台的施行指标，而非靠“对标”的形式事后诱导施行指标，后者销售的象征太过强烈。当然，这种状况不只中台有，凡是商业化的货色，都有这个问题，说“酒香不怕巷子深”的越来越少了。
中台说到底也是一个技术怎么与业务交融的问题，看到了一个有成功实践做背书的技术理念，然而套用到自家业务实际上，却发现“知行合一”远非易事。
四、开放式架构
架构的演进随着信息化水平的加深和越来越多的优良从业者的退出而逐步变得更加乏味、更加简单，从“先写了再说”到工程化的引入，从关注软件本身到关注企业，问题空间越来越大，越来越简单，对解域空间的要求也一直回升。笔者通过前文，在回顾软件工程和企业架构倒退过程的根底上，总结了两个架构演进趋势：从软件架构到企业架构、从繁多办法到“组合拳”，并通过对 EBA 和中台的剖析，对办法之间的差别比拟与联合进行了阐述。本处打算再简略探讨下第三个趋势：从外部架构到开放式架构。
银行是信息化起步较早的行业，而且大型银行组织结构复杂、技术开发投入高、利用范畴大，在架构倒退历程上，很具备代表性，国内银行在架构方面的倒退历程如图 12 所示：
图 12 架构演进趋势
上世纪 80 年代后半期银行刚开始引入主机零碎，此时构建的业务零碎是“高度”扩散的，每个地级市都有本人的业务零碎，不同城市之间业务也是无奈联通的，一笔汇款业务，当初是实时转账，零级清理、秒级到账，然而在那个时候是多级清理，跨地区汇款是从一个城市的网点到本人的市分行，市分行到省分行，省分行到总行，总行到指标地的省分行，省分行到市分行，市分行到网点，在地区割裂的状况下会是个什么效率，大家可想而知。
到了 90 年代末，随着计算机性能的晋升和网络的倒退，数据集中的需要越来越强烈，有数据集中能力有业务集中，大集中架构拉开帷幕，大集中能够构建全行对立的业务零碎，业务效率的晋升是显而易见的，然而由此带来的问题也逐步露出，就是“竖井式”开发的问题。2011 年，建行首先开始企业级转型，设计全行对立的企业级架构，包含企业级业务架构和 7 层 12P 的企业级零碎架构，工程于 2017 年完结，外部一体化初步实现。
然而架构的演进不会就此打住，外部对立之后，更重要的就是适应面向数字化时代的凋谢与交融要求，深度参加到生态建设中，架构倒退的下一阶段天然就是开放式架构，真正从社会分工、生态分工的角度，联合生态搭档、客户的状况，综合剖析架构解决方案。其构想如图 13 所示：
图 13 开放式架构理念演示图
数字社会必然是一个与今日大不相同的“新时代”，所有参与者都将迎来一个转型过程，无论是企业还是集体。尽管转型是渐进式的，然而筹备天然要从当初开始做起，对于企业而言，架构“新时代”的到来是注定的，而这个“新时代”肯定是业务架构与技术架构、业务与技术深度交融的时代，无论是 EBA 还是中台，都有机会在这个过程中表演重要的角色，路线是漫长、波折甚至孤单的，敢于在这条路上摸索的都是壮士。
起源：技术琐话
作者：IDCF 社区分享嘉宾 付晓岩