阿里架构师谈中台系列（二）：阿里业务中台的方法论

Photo @ David Emrich 

文 |焦先

编者按：

阿里巴巴业务中台系列文章第一篇--《阿里巴巴架构师：十问业务中台和我的答案》自 2019 年 11 月 28 日发布至今日，仅在“阿里巴巴中间件”公众号已有 1.8W+ 阅读量， 40+ 自媒体（公众号）转载，本篇文章作为阿里巴巴业务中台系列文章的第二篇，详细介绍阿里巴巴建设业务中台相关的方法论。

引子

---

人类 5000 年的文明之所以能够传承至今，是因为有其独有的传承规律；人们不断的挖掘和总结前人的成就，并将之发扬光大，而方法论正是这样一种传承方式的代表。得利于最近 20 年互联网的高速发展，阿里巴巴也不断的对自身发展进行总结和沉淀，本文将带领大家近距离观察阿里巴巴多年沉淀下来的指导其在电商领域建设的方法论，抛砖引玉，希望能给大家一些启发。（本文内容仅代表作者个人观点，欢迎交流）。

中台的由来

---

很多人知道，早在阿里巴巴三淘系（天猫、淘宝、1688）时代，阿里内部就已经意识到系统和数据割裂的弊端，并且在快速发展的时候愈发凸显：会员的账号体系是割裂的，用户的积分是割裂的，业务和数据都是割裂的，各个部门有许多重复的工作，没有做到共享。所以在 2008 年的时候，集团内部就启动了“千岛湖计划”，做的第一件事情就是把会员体系打通；当这个做完后，我们很快就看到了价值，随后我们就成立了共享业务事业部，其实就是类似于现在业务中台做的事情；随后， 2009 年就是大步往前迈的过程，我们做了一个“五彩石计划”，为什么叫“五彩石”呢，因为是五个中心：商品、交易、库存、营销、店铺；这个完成以后，对阿里的电商体系，这个六大中心基本上就可以支撑所有电商核心业务的运转了。

图-1 阿里巴巴业务中台演进：从“孤岛”到“共享”

而后面的故事很多人就都知道了，在这个“共享业务”之上我们长出了聚划算、双十一等非常成功的业务模式，当然这里面也有很多失败的业务，但是试错的成本明显降低了。

中台方法论

---

前面讲了一些阿里发展的历史，其实这么多年的内部实践，再加上阿里云助力企业数字化转型的外部实践，阿里沉淀出了一套中台建设的方法理论，而这套理论也在后面的实践中不断的丰富和完善。图-2 就是“阿里业务中台方法论”的概要图：

图-2 阿里巴巴业务中台方法论

最上面是战略层面的业务蓝图和规划，这个其实是非常重要的；往下就是服务中心的设计规划，到细粒度的服务设计，再到后面的服务实现和部署，以及往后的上线和优化，覆盖整个中台建设周期的内容；同时还有技术及数据架构的原则和开发规范，用来提高项目实施的效率；此外，不仅仅是技术层面或者项目层面的内容，也包含了中台成熟度模型，就是如何去评价一个中台或项目的成熟度；还包括持续的中台治理策略；最后是组织文化的匹配。

 

其实这两年的业内推出了很多的中台，但是我们仔细看一下，有一些实质上是打着中台的名义进行系统的重构，把一些老的IT架构用上新的技术；另外还有一些中台实质上是数据的集成，把一些烟囱式的系统通过服务总线集成起来，再加上一些微服务的概念，包装一下叫中台；其实我们从这一张图就可以看出来真正的中台需要什么。

简单说，业务中台建设是需要包括人，组织，平台，数据，标准，规范等一整套的建设方法，以及中台实施、运行支持、持续优化、合作生态等一系列支持体系。

业务蓝图

做中台，先做的就是顶层输入，也叫做蓝图规划，出发点是解决企业面临的核心业务、管理等问题。

中台建设是一个企业的战略，所有首先就要问很多问题，比如当前的行业现状是什么、目前的战略规划是什么、竞争对手是什么、优势和劣势是什么、企业对一个中台的建设，不管是IT系统还是业务中心，希望做成的是什么样子，这个不仅仅是对我们中台实施的支持，也是对整个项目的非常关键的一环，下面的 图-3 只是一个例子，这其中我们要关注他们的核心业务流程，关注组织里的 KPI 的考核，这些都是最初始的输入，后续要讨论的未来的中台建设要做成什么样子，所以这个顶层输入是非常重要的一点。

图-3 业务蓝图和顶层设计（脱敏处理）

服务中心设计

接下来，就是中台建设的整个生命周期。这里面非常核心的就是如何识别和抽象出共享服务中心的能力，也就是说这个中心是如何产生的，以及如何设计的；下面的 图-4 就是一个比较抽象概括出来的一个流程。

图-4 如何架设业务中台服务中心

先从需求开始，对于业务中台需要非常充分的业务领域调研，这个调研可以是多层次、多维度、多频次、多角色的，包括组织架构、当前的核心流程、目标流程，当前核心的业务痛点，这个痛点不限于 IT 层面，更多的是业务层面的痛点，调研的结果通过分析产生核心的用例。

接下来，我们会运用业务领域分析方法（目前我们主要是采用 DDD 的领域建模方式），将收集到的用例建立业务模型和属性，以及模型间的关系；所有的需求都可以抽象成业务领域模型，下一步就是把这些领域模型进行划分，识别出来一些关键的业务域和一些目标备选的服务中心；这个过程中也是有多个维度的，可以通过横向的中心划分的维度，或者是纵向的业务维度，通过技术、业务、管理等多个维度划分出业务域。

服务中心识别出来以后，下一步就是服务中心的核心能力的建设，也就是各个中心应该具备什么样的服务能力，这种能力的识别也是通过多种方式，我们目前主要是采用业务的时序流程分析的方法：

1、从各个业务功能用例来分析与中心之间的关系；

2、整理业务实体和服务接口基于中心优化现有系统流程，并完成一次迭代；

3、从平台层面抽象出需要的中台服务能力；

4、再从业务规划的层面完善将来的中台服务能力。

总之这四步的核心就是通过中心里详细的核心业务流程产生各个中心的各种能力，可以包括对外接口，本身的模型，下面的和其他系统的交互，然后识别出中心的核心对外赋能的API。

 

到这里，我们已经比较完整的得到了业务中台所有服务中心的详细模型和能力。图-5 是一个具体流程的例子。当然，这本身是一个很大的话题，鉴于篇幅这里就不详细展开了。

图-5 如何架设服务中心 - 一个例子（脱敏处理）

另外，图-4、图-5 下方的“行业参考模型”也是我们认为很重要的，这些服务中心的能力一定要形成行业沉淀，这个沉淀对于企业来说一定是核心的资产，这是区别于其他中台的一个很重要的方面。同时在不同的行业，把一些行业通用的能力（比如说会员、商品、交易等）建立起一些通用的规划（或者叫最佳实践）和能力的沉淀，这个对企业今后的发展是非常重要的。

实现

现在各个服务中心的模型已经设计好了，下一步就是工程上的实现；这里需要强调一点的是，阿里的业务中台是一个体系，而不限于使用某一个技术栈，只要是符合业务中台的理念的成熟的技术都是可以的。这里 图-6 展示一套比较成熟的最佳实践，首先是前面说的中心建模这一块使用 DDD 的领域建模，有人会问为什么选择 DDD 呢？DDD 领域驱动设计的特点是领域对象与现实世界的业务映射，能够形成清晰的分层架构，设计上可以做到领域对象在场景里的复用。当然，领域建模是一个很大的话题，不作为本次讨论的重点，就不展开了。

再就是我们整个微服务的建设体系，以及下面的敏捷开发 Agile，DevOps ，相关的最佳实践都可以在项目的实施过程中使用起来。其实很多人也问，业务中台和微服务是什么关系呢？其实微服务是中台实现上的一种技术架构和手段，微服务的设计思想也是符合业务中台的理念。

图-6 业务中台在工程与实现的最佳实践

上线和优化

前面是实施，之后就是上线和优化，这个也是我们保证中台建设顺利落地的关键的一环；要强调的是，这个是符合我们中台的持续实施、持续演进、持续沉淀的理念，体现了中台的思想。

线上优化和保证主要包含这么几方面：一是系统的全链路监控和压测的设计和实施，以及后续针对分布式系统的性能瓶颈有针对性的优化；阿里云是有相关产品的，可以最大模拟真实场景下的系统压力表现。二是重保服务，在企业重大营销活动前，对整个链路进行梳理，配合上面的压测系统，发现相关的瓶颈点，并制定相关应急预案，以及后续的总结和改进建议，做到事前、事中、事后的全方位覆盖。三就是高可用方案，这个阿里云也有相关的产品，大家可以关注下。

图-7 上线与优化

规范和标准

上面的三点，设计-实施-优化，这是从项目的一个生命周期角度来看，比较完整的；此外，为了保证项目的高效实施，中台方法论里包括开发规划、标准化、系统化，我们会有详细的规范和标准来做，最终目的是为了提升效率，减少不必要的 Bug 。

如图-8整个业务中台的规范包括技术架构、开发规范、接口标准、部署规范、日志规范，覆盖了设计、编码、测试、部署、运维等全生命周期阶段。这一部分也是阿里多年沉淀下来的财富，对广大的开发人员和架构师有很好的指导作用。

图-8 业务中台规范

中台成熟度模型

一个中台无论是建设之初、还是实际过程中、还是尾声、还是后续的持续演进，如何去评价我们的中台做的好还是不好呢？方法论也提供了一套中台成熟度模型来做这件事，主要包括下面几个方面：

1、业务发展与战略目标

评估企业中台建设中与业务发展和战略方向的关联及贡献，评估成熟度。

2、业务架构

对企业当前的业务架构、目标业务架构、行业参考业务架构进行分析和评估，评估企业当前业务架构与目标架构、行业参考架构的差距，分析业务架构的成熟度。

3、业务中台架构

结合企业当前的业务架构，评估当前的业务中台架构、目标业务架构及行业参考业务中台服务架构的差距，分析业务中台架构的成熟度。

4、技术架构

评估业务技术架构中的成熟度，评估服务化、自动化、高可用、弹性扩展、数字化运营、异步及数据一致的能力。

5、业务能力中心服务及组件

评估企业业务中台中各中心的化分合理度，以及各中心组件及相互交互的成熟度。

6、中台组织架构

评估企业当前的业务中台组织架构与目标业务中台组织架构、业界最佳实践的差距，评估成熟度。

7、业务中台运营组织与流程

结合中台组织架构，评估业务运营过程中组织流程的成熟度。

8、中台治理架构

评估企业当前的业务中台治理流程、治理模型、治理结果，对于治理架构的成熟度进行分析和评估。

图-9 业务中台成熟度模型

持续治理

为了保证项目的顺利开展，从创建之初就需要一个组织，或者叫决策组、委员会，都需要长期的来跟进项目；这个组织要有决策机制、治理原则和策略、相关的工具以及相关的流程，共同把长期治理演进，长期的优化，形成一个正反馈的机制。

图-10 是一个供大家参考的运营治理决策图。

图-10 业务中台运营和治理

组织文化

最后一块就是组织文化。建设初期就需要组织上的变化，区别于传统公司自上而下的组织管理模式，我们推荐的是小规模的作战单位，其实阿里内部也是这种组织模式，和微服务的有些类似，更强调的是从业务领域出发来组织相关角色的人员。当然，组织的形式是多样的，不同的企业需要根据自身情况来做调整，但是最关键的是要做到信息共享、业务导向、统一共识。图-11 的例子就是我们之前在给外部某企业做中台的时候做的组织上的适配。

图-11组织文化适配

结语

---

本文简单介绍了阿里业务中台方法论的主要内容，当然里面的很多内容限于篇幅没有展开。本文也是阿里业务中台建设的一个缩影，希望能够给到大家一些启发。就像上世纪 90 年代 ERP 软件定义了企业 IT 系统一样，我们相信，未来业务中台作为支撑企业新 DT 时代的数字化转型，将成为企业未来发展不可或缺的战略项目。

作者信息：

焦方飞，花名焦先，2014年加入阿里，先后在中间件事业部、数据库事业部任职，现任云原生业务中台架构师。

关注下面公号，回复关键词「中台」即可获取阿里中台50页ppt～

“技术领导力”公众号

想加入社区，跟100位互联网大咖学习？

添加群助理Emma，注明“加群”

技术领导力社群

---

大家在看：

1.陆奇：真正的高手，都是长期主义者！

2.耻辱!2000多个Bug,13亿人出错,损失28亿

3.张小龙:厉害的人,不在最牛的时候吃老本

4.马云:核心团队是剩下来的,不是选出来的

5.阿里王坚:真正的理想主义,都是拿命来填

6.支付宝"配音女神",5亿人听她声音,31岁单身

好看就点在看