好文分享| 细品中台（上）

以下文章来源于微信公众号冷技术热思考 ，作者风轻扬，由于字数限制，分上下两篇。

两年前正当中台概念爆发的时候，我曾经写了三篇文章（什么是中台、怎么建中台、网易杭研的中台往事）对中台做了一次梳理，这两年，中台仍然持续是热门话题（虽然没有更热），我们及行业对中台的理解和实践也有了长足的进步。

从我们而言，两年前我们的中台和支撑技术（如网易轻舟和有数）只能说有了基础，这两年都成熟很多。我们也服务了一些外部客户，获得了一些非互联网行业中台经验。这些内外部经验我们进行了总结，出品了极客时间《数据中台》专栏。

从行业而言，有了滴滴、头条、美的等更多的行业案例，也有更多的行业专家针对中台话题发表了更多思考。如王健老师出品了极客时间专栏《讲透中台》，在我看来应该是在业界第一次完整的提出中台的建设方法论；钟华老师新写了《数字化转型的道与术》，把中台融入到企业数字化转型的大框架内；企业服务领域的老江湖用友也出了《数字化中台》，全面阐释业务、数据、智能、技术等中台体系；刘天（三爷）老师写了《中台产品经理宝典》；付晓岩老师、老K等也都发表了相关思考，就连刘润老师也止不住的把《尴尬的中台》每年旧文重发一次（似乎只字未改）。至于业界实践最多的数据中台，厂商出书已经形成一种风气，似乎不出书就显得不够格（我们没出书但也出了极客时间专栏）。

这段时间，我一直在梳理两年来我们和业界的相关进展，思考，总结，以下就是工作成果。全文约两万字，分上下两篇，上篇是中台篇，介绍中台相关的通用话题和业务中台，下篇是数据中台篇，专门介绍数据中台。只对数据中台感兴趣的朋友可以跳到下篇。

两年前读过的老朋友完全不用担心内容重复，和刘润老师不同，虽然我的核心思想是一脉相承的，但内容囊括了这两年的很多进展，总体丰富很多。王健老师也是这样，虽然两年前写了系列文章，但专栏进一步提出了方法论。钟华老师的思考则是突破了中台上升到企业数字化转型的大局观。

我们都在要求自己进步。

「中台篇」

一、中台是怎么来的

大家都知道中台是阿里提出的，问题是阿里为什么会想到中台这一招。关于这个缘由，有正史和野史两个版本。

1. 正史版

正史来自于钟华老师的《企业IT架构转型之道—阿里巴巴中台战略思想与架构实践》。说是2015年中的时候，马老师带领一众高管芬兰游戏公司Supercell，惊呼原来世界上还有这么高效的公司，回来后学习Supercell就提出中台战略。

Supercell是一家游戏公司，2010年中成立，马老师去看的时候才五年，但营收已经超过200亿美金，更神奇的是只有不到200人。2015年的阿里则是成立已经17年，马老师都熬不牢半退休了，营收才943亿人民币，员工数却高达34985，还正值马老师交棒给老陆后狂推来往而失败，正处于战略上的焦虑期。两厢对照，肯定会觉得Supercell真的是神，不服不行。

马老师应该特别喜欢琢磨公司的组织模式（你看阿里经常调组织架构），所以自然就发现Supercell这家公司很特别。Supercell的搞法是所谓的“细胞-部落”式，细胞是工作室，每个工作室就几个人，负责一个游戏，部落是共享的职能，负责公共、通用的游戏素材、算法等，为各工作室提供高效的支撑。这样的模式让Supercell特别善于创新试错，据说一个小团队几周时间就可以研发出一款新游戏推向市场，如果这个游戏失败了，公司甚至会举办仪式来庆祝从失败中学到了东西。

回来后，年底阿里就宣布全面启动中台战略。

当然，阿里能全面搞中台战略，除了Supercell的神启，也是要有事实基础的。这个基础就是2009年成立的共享业务事业部，这个事业部在2015年的时候，已经搞了用户中心、商品中心、交易中心等十几个中心。也就是说当时阿里最具特征的业务中台已经相当有雏形了。

2. 野史版

野史版的故事来自于阿朱。话说2013年5月10日晚，数万阿里人相聚黄龙体育中心，参加淘宝十周年的纪念晚会。但大家知道这个晚会不仅是纪念淘宝十周年的，更重要的是马老师要在会上宣布退休，交棒给老陆。我虽然不是阿里人，但也受邀在现场亲眼见证了交接过程。马老师一如既往的慷慨激昂，高呼“要相信年轻人”、“从明天起，生活就是我的工作”，然后老陆上台，马老师退场。

但马老师当然是退而不休。为了安全退休，阿里被拆分为25个事业部，并且实行了合伙人制。25个事业部各自为政，老陆上台后，根本搞不定这25路诸侯，无奈之下只能剑走偏锋，拼命做来往。老陆的算盘是要是来往做大，每个事业部都得求着来往要流量，那时我还不是让谁干嘛就干嘛？可惜来往没成，25个诸侯群起而轰之（老陆命令所有员工至少拉100个来往好友否则不发年终奖，把各路诸侯都得罪了），马老师把老陆废了，悄咪咪换上老逍。

老逍上台，也得想办法解决这个诸侯的问题啊，不然干不了两年也得下台（甚至更严重，老陆后来不久连合伙人的资格都被废了）。2015年5月老逍上任，年中马老师带高管拜访Supercell，大概率老逍是一起去了的。我觉得说是马老师受到了Supercell的神启，不如说是老逍受到神启。我想老逍一看Supercell的搞法，肯定会觉得太对胃口。只要搞“大中台”，美其名曰大家不要重复造轮子，25个事业部就变成了“小前台”，这不就把诸侯的问题解决了吗。中台的负责人，正是老逍多年的好战友行颠。

我想阿朱讲这个故事的用意可能不是说中台不行，反而是给各位老大提个醒，如果你想削各路诸侯的权的话，可以搞中台啊。

有句著名的伪名言叫“历史是个任人打扮的小姑娘”，阿里中台的正史和野史，都有真实的故事，但对背后动机的解读就完全不同了。我个人觉得，抱着兼听则明的原则，姑且两边都信一点为好。

二、阿里的花式中台打法

虽然钟华老师在书里很低调的说中台并不是阿里首先提出的词语，但一般都认可是阿里首先把中台概念发扬光大的，我们先来看阿里的中台都是哪些。

我们先看阿里刚提出中台时的样子，往往这个时候的中台最能反映初心和精髓。阿里最初提出的中台架构是双中台：业务中台+数据中台，分别对应两本书，都在2017年出版。

第一本是《企业IT架构转型之道：阿里巴巴中台战略思想与架构实践》，这本书应该算是阿里第一次正式提出中台的概念，不过只介绍了业务中台，没有任何一个地方提及数据中台。这本书并没有给中台下过一个明确定义，但通观全书基本可以理解阿里的业务中台就是共享业务事业部及其所构建的如下图所示的共享服务体系，包括会员、商品、交易等20多个公共的、通用的业务服务，前者是中台的组织层面，后者是中台的系统层面。

第二本是《大数据之路：阿里巴巴大数据实践》。这本书明确给出了阿里集团数据中台的概念，即“阿里巴巴数据技术及产品部定位于阿里集团数据中台”，书中主要介绍了阿里集团内部进行数据整合及管理的方法论，也就是OneData、OneID、OneService，这套体系的主要应用是构建了阿里集团的数据公共层。

由此可见，阿里一开始提出的“双中台”的概念是很清楚、很好理解的。双中台都涉及组织和系统两个维度，组织维度都有负责的部门，系统维度业务中台就是共享的业务中心，数据中台的就是数据公共层。

但是后来阿里好像就有点放飞自我了，各种花式运用层出不穷，对中台的运用达到了出神入化的状态。

比如去年说上了用户行为分析、CDP就叫中台，3年要帮客户建100万中台。当时我写过一篇我已经不能理解阿里说的中台是啥了，表示不解。今年又说要云钉一体，做厚中台，又说这个中台是个操作系统，钉钉是操作系统的核心。一般理解操作系统是个软件概念，阿里号称自己是商业操作系统，把操作系统的概念泛化了，这也好理解，但说中台也是个操作系统，就不太好理解了。这个操作系统是阿里商业操作系统里面的一个子操作系统？

另一方面，据说阿里已经在拆中台，要把中台做薄。一边做厚，一边做薄？自己拆中台了却要帮客户建100万个中台？不是我不明白，这世界变化快！我相信很多人都是这样的感觉吧。实事求是的说这些说法也不一定冲突，比如做厚中台指的是做厚阿里云的中台，做薄中台指的是做薄阿里集团的中台。但说法多了，确实容易把大家搞晕。

我觉得对咱们普罗大众来说，要学习阿里的中台还是看最初的双中台比较好。

三、网易杭研的中台实践

网易有两套比较成熟的中台体系，一是游戏中台，二是杭州研究院所构建或参与的系列中台。游戏中台我没参与不熟悉，大家大致可以理解为类似Supercell的做法，杭研相关的系列中台则是我的主要工作。

1. 创新中台

网易杭研成立于2006年，核心职责是为集团孵化创新业务，今天很多人知道的云音乐、严选、云课堂、Lofter、考拉海购，早一些的网易相册、网易博客，To B的智慧企业、网易数帆等都来自杭研的孵化。为了更好的支撑创新业务发展，杭研从一开始就逐步构建各类专业能力部门（内部称为公技部门）提供大量公共的技术平台或专业服务。

整个杭研构建的这些专业能力部门，可以认为共同形成了一个创新中台。两年前我曾写过一篇文章介绍杭研的这段往事，有兴趣深入了解的可以看看。大致而言，我们围绕互联网类创新业务发展所需的市场研究、用户研究、用户体验、敏捷项目管理、移动开发、个性化推荐、商业智能、内容安全等都设置了专项的部门。这些部门一方面提供专业的人力服务，另一方面也积极研发相应领域的系统和方法论。

大家可能认为这些部门和阿里的双中台大相径庭，不能算做中台，但整体来看，它们共同构成了一个强大的支撑互联网业务创新发展的公共能力，这些能力很大程度上以软件的方式提供，而这些部门又和业务贴的很紧，具备互联网行业特征，因此称为面向互联网业务的创新中台是很恰当的。王健老师在《白话中台战略2：中台到底长啥样？》一文中提到“组织中台很像企业中的内部风投和创新孵化机构”，杭研创新中台可以说是组织中台。

当然，我也认为杭研的创新中台确实不算最典型的中台，这些专项部门往往都只在一个阶段存在，一般几年之后在一个专项上的能力建设达到比较高的水平后，我们往往选择将这些部门的专业服务人员分拆到各对口业务，而只留下产品化的成果。这样一个中台部门就“转化”成为一个技术平台，这样的转化在我们看来实属平常。

最近两三年，我给多家企业做过创新中台的分享，很多企业都表示我们的机制挺不错，很值得研究和学习。可能因为毕竟如我们这样十多年通过研究院在创新中台的支撑下不断的探索创新业务（还挺跨界）也还算有些成绩的公司极少，大量的是创新乏力的企业，和我们类似搞过面向创新的研究院或创新院的要么没搞成（如曾经轰轰烈烈的盛大创新院）或因为太成功但把研究院搞没了（如做出微信的腾讯广州研究院）。但我知道绝大多数企业也只能说说而已，真的要搞好一个面向创新的研究院和创新中台谈和容易。

2. 数据中台

我们构建的最多的是数据中台，包括集团级的数据中台，也包括严选和云音乐等事业部级的数据中台。

我们从2015年开始构建集团的数据中台。我们的做法和阿里是类似的，也是定位于建设集团的数据公共层。但因为我们的业务形态五花八门，不像阿里很多事业部都聚集电商领域，所以我们的数据公共层就比较薄，主要就聚焦在用户标识、用户画像和用户关系层面。经过6年的建设，当前非游戏业务已经完全依赖于我们建设的数据公共层，大量的广告投放和推广都依赖我们提供的更为全面的精准的用户标签。

严选和云音乐也构建了数据中台，这些数据中台比集团的做的更厚，不但包含事业部级别的数据公共层，还包含了很多子业务的数据集市，数据中台团队也比集团数据中台团队规模更大。指标、模型、治理等数据中台的典型实践在这些事业部级的数据中台中体现的更为充分，这些中台对数据的获取效率、使用成本、质量和安全性起到的价值更为显著。严选的数据中台建设开始于2017年，是事业部里启动最早的，也最成熟，整体架构见下图，细节可关注严选技术团队2019年底的介绍（数据中台-企业的数据化引擎）。

3. 业务中台

我们从去年开始着力构建视频中台，因为集团有很多视频内容业务，如音乐、新闻、有道、Lofter等，还包括可通过内容带货的电商业务严选。视频中台的主要职责是视频的统一采买、统一加工处理和多渠道分发。

事业部里面，严选和音乐在业务中台上投入比较多。严选虽然体量不大，但链路上从研发生产直到销售配送，营销体系上除了主站还有淘系、京东等分销和企业内购等不同形态，业务复杂性其实非常高。为了提供可复用的业务场景解决方案，以较低的成本快速满足多个前台业务需求，严选自从2018年开始探索和构建中台能力，当前在库存、采购、品控、仓配、供应商等板块都实现了比较好的中台化。严选的中台建设有一个特点是并非整体成立了一个中台部门，而是在库存、采购等各个业务板块内部建设多个“小中台”。

音乐比较有意思的是App中台和曲库中台。音乐的App中台沉淀了大量音乐社区和社交类App的共性能力，使得我们在孵化和云音乐同类的声波、心遇等App时快了很多，有个突出例子是Clubhouse火了后两天就做出了类似功能。曲库中台负责源源不断的新歌入库，并针对歌曲内容进行深入的分析和挖掘，为各业务提供完整、准确的曲库信息，包括歌词、翻唱跟关联关系等，还提供听歌识曲等专业能力。

总的来说，我们的中台有几个特色。一是都是因地制宜逐步建设，投入较少，但效益比较扎实；二是创新中台；三是大部分中台不是集团级，而是事业部甚至是子业务内部的。其中后面两个特色比较适合我们横跨社交娱乐、电商、教育的多元化业务特征。

四、业界中台盘点

在阿里之外业务最常提到的中台可能是字节。字节在业界被称为App工厂，旗下头条、抖音、西瓜、懂车帝等多个内容型App都很牛，所以业界早就盛传字节有一套面向内容产品研发和运营的中台能力。关于字节中台的分享都不怎么深入，不过今天我们可以从字节开放的火山引擎一窥究竟。如下图所示，火山引擎开放的技术中台包括AI中台、多媒体中台、数据中台、研发中台和移动中台五大模块，其中能力最丰富的是AI中台和多媒体中台。这些能力大概率尚且只是字节中台能力的一部分而非全部。

一般情况下我都不认为一大堆技术组件的汇集能称为中台，因为在这些技术里面往往找不到和业务相关的字眼，字节的中台是我觉得极少的可称为技术中台的，因为字节的核心业务就是内容型业务，所以这些能力很多和业务就比较相关。但我觉得仍可以说字节的“中台味”不太纯，因为其中大多数都是业界比较通用的技术组件。

滴滴从2015年开始做中台，到2016年做了出行中台，很多出行业务都基于这个中台。基于出行中台孵化出了订单、计价、支付、passport、用户、触达等六大中台能力，这些能力2019年也开始支持非出行业务，演进为公司级的业务中台。除业务中台，滴滴还有比较庞大的团队做了数据中台。

京东2018年开启中台战略，主要通过组件化和平台化，面向“黄金交易流程”，涉及购物车、结算页、收银台、订单等核心交易模块。除了这一高层面的中台，一些子业务内部也有中台，购物车中台、结算页中台、订单中台等。以购物车为例，中台和前台是独立的两个部门，中台除了支持主站购物车外，还支持医药等垂直业务的中台。

以上都是互联网领域的案例，因为中台几年热度很高，一些非互联网行业也进行了中台建设，如美的和农业银行。

美的董事长方洪波在一次采访中介绍了美的的中台。以前美的是事业部制，高度分权，效率非常好。但随着数据时代的变化，变化越来越快，美的需要高度快速反应、敏捷性、韧性、灵活性，为此美的向互联网企业学习，开始转型，思路就是大平台、小组织、小团体、小单元、小业务、小分队。在后台之上建了两个核心，一个业务中台、一个技术部门，前方全是小的团队，区域的、产品的或以某一个业务板块划分。

农业银行提出了“薄前台、厚中台、强后台”的 IT 架构体系，其业务中台包括流程、服务和产品三个维度，流程维度包括风控、信用评价、反洗钱等4个模块，服务维度包括客户、员工、运营、渠道等8个模块，产品维度包括存款、信贷、支付结算等8个模块。看起来农行的中台建设已经蔚为大观。但从资料和对银行业的了解看，农行的以上中台大可能还是一种设想而非实际。不过农行的信贷中台看起来是实际落地了的，由于行业场景贷款和全局授信等需求，农行构建了如下图所示的信贷中台，支撑供应链金融、个人、对公等多个业务。

五、中台是什么

在看了阿里、我们及业界很多公司的中台实践案例后，为中台给出一个正式定义就比较容易了。

我两年前给中台下过一个定义（见[[什么是中台，什么不是中台]]）：中台是支持多个前台业务且具备业务属性的共性能力组织。参考这两年的实践经验和专家观点，我想对这个定义进行小幅修正，新的定义是：中台是以软件服务的形式提供共性业务能力的组织。

新的定义删除了“支持多个前台业务”不是因为这一点不重要，而是因为“共性”一词已经表达了这层含义。

这个定义有三个关键词：

• 中台必须是个组织：这一点是中台区别于其他能力复用形式的首要特点。阿里的双中台都有强大的组织（共享业务事业部和数据技术及产品部）来建设和运营；我们的中台也都有对应的组织建设，集团级的中台由杭研承担，部门级的中台也都有相应的组织负责建设；钟华老师认为“中台必须是值得企业投入独立团队进行运营的单元”；王健老师认为“组织可能不是中台建设的阻碍，而恰恰是中台建设的本质”。这都说明中台必须和组织相配套已经是行业共识。另一方面，中台是组织这点和和也提供共性能力的软件平台和技术平台（特别是和中台听起来有点像的中间件）好区分。业界有不少专家认为中台和中间件没什么两样（刘润老师似乎就是这么认为的），这是不对的。这并非我一个人的观点，王健老师在专栏中就指出技术中台和中间件是两回事，何况业务中台和数据中台；钟华老师明确的把中间件归属于后台。

• 中台提供的能力必须有业务属性：这是中台区别于其他能力复用形式的另一显著特点。从业界的典型实践看，业务中台提供的能力都是和业务领域相关的，数据中台提供的服务和指标也都是和业务特征相关的，中台的业务属性很浓。钟华老师认为“仅在纯技术层面进行沉淀和改进，其工作效率的提升还是有限的”，只有在业务层面做了沉淀，才可能为新建系统提供帮助，“采用这种方式的效率一定远超前一种”。虽然这一点并未形成高度共识（有些专家的定义比较泛），但我认为有没有业务属性会导致建设和运营方式显著不同（比方说有业务属性的你就买不到，否则你很可能可以买到现成的；有业务属性必须运营，没有业务属性可以只是运维），所以我还是坚持中台必须要有业务属性。另一方面，坚持这一标准有助于将中台和很多没有业务属性的技术平台（再次点名中间件）和典型的财法税等没有业务属性的后台部门区分开。

• 中台的能力必须要以软件服务的形式提供：这一点比较微妙，也可能挺有争议，但我认为是值得强调的。这涉及几个方面的考虑。首先，如果不强调这一点，某些提供人力外包服务，但又认为自己也蛮懂业务的部门，如研发中心、测试中心、客服中心等也都可以堂而皇之的称自己为中台，这样中台的概念岂不是太泛？其次，一个软件服务的形式的能力和一个以包人头形式提供的能力，所需要的支撑技术未免相差太大，前者可能是微服务，后者可能是个工单系统，这样中台的建设方法岂不是也太泛？所以我认为我们规定中台必须提供软件服务为好。钟华老师也在书中强调中台“仅以服务方式对外提供访问”。

这个定义可以拿最典型（业界落地最多）的数据中台来测试一下，因为数据中台的样子大家比较清楚，可以发现数据中台完全符合上述的中台定义：

• 数据中台是个组织：数据中台都有专职的建设团队，有很多数据工程师，做很多数据加工工作。即便是通过甲乙方项目制来做，也是需要实施团队比较重的投入的。

• 数据中台提供的能力有业务属性：数据工程师是需要比较懂业务的，数据中台提供的指标、模型和数据服务都是业务术语。

• 数据中台的能力是以软件服务的形式提供的：这就是阿里提出的OneService，今天这已经成为所有数据中台服务商的共识。

我们的中台，阿里最初的双中台，还有业务比较认可的字节App工厂中台，也都很好的符合我给出的这个中台定义。

我的定义和业界我认为真正懂中台的专家的定义也是类似的。钟华老师作为业界第一个出书的专家，在新书中给中台下的定义是“将企业的核心能力以服务化形式沉淀到平台…”；王健老师定义中台是“企业级能力复用平台”。我的定义和钟华老师和王健老师没有根本差异，主要是侧重点的不同。

当然了，中台仍是新生事物，仍没有严谨的方法论，正如我现在给的定义和两年前略有不同一样，我们所有人对中台的认知也都在逐步提升的过程中。钟华老师的新书和原书相比对中台的理解就有了很大的发展，王健老师的专栏相比19年的系列文章也有很大提升。

我曾经跟付晓岩老师开玩笑说现在业界就等您来给中台搞个严谨的方法论了，因为付老师之前没去IBM的时候曾说中台没有严谨的方法论，就缺IBM来整个方法论，而今年付老师跑到IBM去了。不过付老师天天写“中台之上”的企业架构，似乎对中台并不太感兴趣。

六、国际顶级研究机构怎么看中台

中台在国内搞的声势浩大（当然也有说中台烂大街的），那么Gartner等国际顶级机构怎么看中台呢。

Gartner

Gartner每年发布一次《Hype Cycle for ICT in China》报告，中台（Middle Platform）在去年的报告中首次出现，但今年又消失了，数据中台（Data Middle Office）也是去年首次出现，在今年不但得以保留，且在Hype Cycle曲线上明显前移。印象中Gartner还出过一篇很长的介绍数据中台的文章，可视作Gartner对数据中台的官方解释（可惜的是没找到这篇文章）。很有意思的是Gartner对数据中台和中台用的是两个词，一个是Office一个是Platform，我为此甚是困惑，还专程向Gartner请教过。

Forrester

Forrester的态度比较微妙，出过一个专门的讲数据中台的报告，但除此之外对中台似乎只字未提。该报告是2019年6月出的，看似是比Gartner更早认可数据中台，但细看可以发现这个报告其实是产商（数澜）赞助报告，而在此之后Forrester似乎又再也没提过数据中台。这点蛮奇怪，所以我稍微深挖了一下，发现原来Forrester后来认为数据中台就是自己说的“企业洞察平台”，就不再单独说数据中台概念了。

IDC

IDC去年底曾经出过一个《CIO视角：企业数据智能实施部署指南》报告提及数据中台，但这个报告的主题还是数据智能，对数据中台是什么似乎也没有很明确的解释，感觉IDC似乎把数据中台当作数字化平台也就是数据智能整体解决方案的别称。IDC也曾经在一份报告中提及AI中台的概念，但后续没有持续关注。IDC对中台没有给过任何评价，对数据中台和AI中台的提及也是局部和短期的，IDC似乎也更中意自己的数据智能概念，不清楚怎么摆数据中台这个概念。

总的来说，Gartner、Forrester、IDC这三个最主要的国际IT研究机构对中台概念还在观望，但其中最具权威性的Gartner鲜明的支持数据中台，其他两家虽然名义上没有，但在自己的术语体系内也是认可数据中台的。因此可以说，数据中台概念已经获得国际顶级研究机构的一致认可。

作为分析机构，都尽可能的希望把业界实践纳入自己的话语体系，似乎这样才显得自己的领导地位。我觉得完全没必要，像Gartner那样大大方方认可数据中台才是高明的。

七、业务中台的简明方法

为业务中台提出一套标准的建设方法和支撑技术很难。之前已经介绍过，业务中台的概念目前还未获得Gartner等顶级研究机构的认可，说明这些分析机构对业务中台还没有达成共识。业界的案例分享也主要介绍中台的建设背景和内容，但对怎么建讲的很少。

以下是我小结的业务中台简明方法，包括方法论和技术两方面。这个简明方法主要是参考了我们自身经验、钟华老师的书和钟华老师创业担任CEO的比升科技的介绍、ThoughtWorks王健老师的文章和极客时间专栏《说透中台》及滴滴等案例。目前业界系统性的介绍业务中台建设方法的还是首推钟华老师和王健老师，其中钟华老师的书（第一本）更侧重技术，王健老师的专栏更侧重方法论。

方法论层面，目前看来最具体系的应该是王健老师在专栏中提出的D4模型，即把中台的建设分为Discovery、Define、Design和Delivery四个阶段，对每个阶段，王健老师还进一步给出了一些具体方法，如：

• Discovery阶段：采用Portfolio Discovery（PD）方法（一种头脑风暴工作坊），自上而下和自下而上结合，建立对企业和行业的“全面视野”。

• Define阶段：采用领域驱动设计（DDD）和事件风暴方法对业务流程背后的问题域进行分析。

• Design阶段：确定中台产品的愿景和业务范围，然后借助设计思维、用户旅程图、服务蓝图等方法进行设计和梳理，并从MVP起步进行迭代。

• Delivery阶段：采用精益产品研发流程，做好中台的运营、治理和演进。对用户分级，头部用户提供专家级服务，快速响应，尾部用户提供自助式服务，降低服务成本。

王健老师的D4模型很全面，但不是说所有中台的建设都必须完整的应用这些方法，特别是非企业级的“小中台”，可以进一步简化。从我们的经验和业界的一般观点看，业务中台最核心的方法论是D4中的以下两点：

1. 采用DDD或事件风暴方法梳理中台板块的边界；

1. 采用精益产品研发流程，从MVP开始，做好中台的运营、治理和演进。

技术层面主要是SOA和微服务、DevOps、流程与规则、API网关。

SOA和微服务一并来说。中台的能力以软件服务的形式提供，因此必须有某种SOA技术支持，微服务则是最典型的SOA实现。不过中台未必微服务，这是我、钟华老师和王健老师的共同观点。中台解决的是业务领域的业务复用问题，微服务解决的是技术领域的“组件编译时依赖”问题（王健语），因此中台未必基于微服务，其他SOA技术也可以。采用哪种SOA主要取决于需求和基础，互联网企业自然会选择微服务，但非互联网行业存在大量的传统SOA架构，基于已有的SOA架构资产建设中台也并非不可行，性价比有时也更高。不过有条件的情况下我还是会建议优先采用微服务架构，包括服务网格，因为毕竟这才顺应技术的演进方向。

中台采用精益产品研发流程，需要快速响应多个前台的需求，因此DevOps技术对中台至关重要。如果没有成熟的DevOps技术支持，中台要么响应慢，要么乱糟糟的仓促上线经常出事，这两种情况都可能导致前台对中台怨声载道，导致中台建设的失败。

前台使用中台能力典型有两种方式：组合和配置。组合通过微服务等SOA方式实现，配置则主要通过流程和规则引擎支持。我们在建设严选中台时发现，仅靠微服务机制并不能很好的实现中台，流程和规则引擎也很重要；滴滴的分享中也提到中台实现的一个核心点是配置化，很多业务都是配置出来的；钟华老师的比升科技也重点提到业务可配置、能力可扩展。因此，流程与规则引擎也是中台的常见支撑技术。

最后是API网关。中台的能力都以服务的形式提供，大量的服务需要的治理能力，可以借助API网关。当然，像阿里这样的超大规模的中台需要更专业的中台能力治理平台，但不复杂的中台，采用API网关是比较方便的做法。

我在两年前的文章[[怎么建设中台]]里还提到云原生技术和分布式事务技术，今天没提分布式事务是因为它应该是微服务技术栈的一部分，没提云原生技术是因为它和中台的距离又远了一层。和两年前相比我增加了流程与规则和API网关。我没有提统一的登陆和权限等内容，这些更基础的能力当然也是需要的，只是和中台的特色不是太相关。

小结一下，业务中台的简明方法包括方法论层面的DDD和事件风暴、精益产品研发和技术层面的SOA和微服务、DevOps、流程与规则、API网关。

八、中台与组织

组织是中台的核心，因此业界有很多关于中台组织的观点，如最常听到的说法是中台必须是企业级的，必须是一把手工程，另一方面业界对中台组织本身的特点和管理方式又很少谈。我在两年前的文章里提到中台未必是企业级的，也可以是事业部级的。中台的组织形态有多种，有“胖中台组织”、“标准中台组织”，也可能退化成平台。这两年来很高兴不少业界同仁也持有类似观点。

1. 中台未必企业级和一把手工程

大量的实践表明，大多数中台并非企业级，我们的中台绝大部分都是事业部甚至是子业务级，滴滴的中台也是从出行业务一步一步发展而来，京东有不少子业务内部的中台（如购物车中台），至于农行那样的中台规划则实际上很可能没落地。即便阿里的中台也主要局限于电商业务，支持不了云业务，而且后来阿里也拆了大一统的中台，变为“互为中台”。

中台必须是一把手工程多数情况没错，但不能狭隘的理解，更不是必要条件。

不能狭隘理解一把手必须是CEO，甚至不能理解为必须是事业部总经理，而应该理解为中台涉及范围的一把手。我们严选的数据中台做的很不错，但其实在很长时间里，严选的CEO并不关注，但严选数据中台确实得到严选CTO的大力支持，严选的CTO就是这个环境下的“一把手”。乙方往往喜欢宣扬中台必须是一把手工程，我感觉其实也带着筛选客户的考虑，因为一把手重视单子才能做大也容易交付，一把手不重视则单子小、风险高。但对于甲方自己想建中台，从更低层级的中台起步往往是更好的做法。

中台也未必是一把手工程，优势部门做中台再推广也是一条路。我们的数据中台是集团级的，但并不需要老板下指令，而是基于杭研业务数据基础，再和其他业务互惠共赢不断做大的。滴滴的中台也是出行业务做了后再推广到其他业务的，企业业务是否接入中台并不强制。这样的做法也有优势，这样的中台肯定是创造价值的，肯定是有利于创新而非阻碍创新的。

所以，我认为非企业级的中台并非中台还未建成的表现，而是中台的未来发展方向。中台的发展方向是分布式中台，也就是组织内部存在不同层次的多个中台。老K在《中台彻底搞砸了？下一站，小中台大前台》中提出中台的演进方向是小中台和碎片化中台，如安全中台、财务中台、物流中台等等，我说的分布式中台和老K说的碎片化中台是一样的概念，只是感觉碎片化比较负面，称分布式更好。

分布式中台是趋势除了以上原因，还因为中台作为一种组织形态和权力分配息息相关，而企业组织的大趋势一定是分权而非集权。阿朱介绍的阿里中台的诞生历史就充满权斗的意味，老逍是通过大搞中台削诸侯的权。我们不要把阿朱的话当作细说，我观察我们中台的建设，很多或多或少也存在权力的争抢，中台部门当然希望争取更大的业务范围，而前台部门也经常以中台支持不力为由把权限抢回去。北京大学光华管理学院教授、光华创新中心主任张一驰教授更是认为“企业中台化浪潮实际上是以横向水平分割的方式来解决集权和分权平衡的问题的，其目最终目的是实现责任和权利在各个组织层级之间的长期动态平衡”。从组织管理的角度，张教授可能说出了中台的本质。

2. 中台的组织形态

我在两年前的文章曾提出，“标准中台组织”只应该包含共享的能力，但为了解决和前台业务结合不够深，合作不够顺畅，可以把相关前台的部分团队也整合到中台，从而形成“胖中台组织”。阶段性的可以让中台组织长的过胖一些，让中台和前台的边界在一个组织内磨合，过两年在看哪些是属于中台的骨骼，哪些是属于前台的肉，搞清楚了再把肉重新分到前台去。

这两年我看到业界也提出一些相近的组织方法，一是王健老师在极客时间的《讲透中台》专栏中提到中台的运营和治理可以给用户分级，对最重要的用户可以提供专家级服务，对一般用户则提供自助式服务，此真乃老到之言。字节跳动在分享中提到“数据中台”有“BP团队”，对“前端”业务进行专门的支撑，这类似王健老师说的针对重要用户提供的专家级服务。

我说的“胖中台组织”、王健老师说的“专家级服务”还是字节的“BP团队”，都是在中台组织内除了共性团队，还部署专职面向某些前台业务的定向服务团队。这些团队从我们和一些业界的经验看，应该采取“专人就位”的模式，“专人”指的是支撑一个前台业务的团队是专职的，即便只有一个人；“就位”指的是这些专职人员一定要坐到业务团队中间去。

中台需要给予业务一定的考核权限。我们的经验是最简单且有效的做法是给业务“满意度”考核权，占组织绩效的10%以上即可大概率确保中台组织有志于提供高质量的服务。当然，如果你搞中台的目的是控制权力而非提供服务，那就不要搞这样的考核了。

九、结束语

中台涉及的方面很杂，我无法给出一个要点小结，这个结束语主要是一些整体感受。

首先，通用的中台（即业务中台）在这两年的发展并没有继续爆发。没有获得Gartner等顶级研究机构的认可（曾经在报告中出现过，但都是昙花一现）。方法论上只有王健老师在专栏中提出的D4模型。钟华老师作为第一个面向业界系统性阐释业务中台概念的专家，在其新书和创办的毕升技术公司的介绍中已经不再把中台放在核心位置。业界已经在说中台不行了，但另一方面如果去招标网看看业务中台的招标仍有不少。对此，我认同王健老师的观点，“个体中台可能会死，但中台背后的趋势不会变”。

另一方面，数据中台发展的如火如荼。Gartner已经连续两年为数据中台正名，仅杭州就发展出所谓“杭州五虎”五家代表性数据中台厂商，招标网上今年数据中台方面的标是业务中台的四倍，方法论层面有好几本书（虽然我觉得这些书的内容有点飘），技术方面也在不断进步，如实时数仓、湖仓一体。

中台涉及的组织因素是相当复杂的，即便是数据中台。我们看到阿里中台的起起落落，似乎都和权力分配有关，张一驰教授更是鲜明的提出中台乃是“以横向水平分割的方式来解决集权和分权平衡”。这有时是中台建立的动力，有时给中台建设带来阻力，总之为中台建设带来不确定性。从组织层面，这两年我看业界有更多人认识到两点，一是中台的趋势是分布式中台，二是中台组织内部要有定向服务的团队。