我看互联网技术的中（后）台架构

Question

中台最近又成了比较热的话题，结合我对中台的认知，试图跟你回答下这些问题：

1. 互联网公司的中台到底是什么？
2. 中台有哪些类型？
3. 中台有哪些困境？
4. 互联网公司中台的现状
5. 关于中台的建议

1、互联网公司的中台到底是什么？

中台化据说是马云参观 Supercell 后在阿里巴巴提出的，要求 大中台、小前台 的模式。目标也很明确：小前台距离一线更近，便于快速决策、敏捷行动；剩下的交给支撑部门做。

Supercell 的中台化究竟是什么呢？

首先，Supercell 一直倡导 Less is more 的组织文化，整体公司员工数量保持在极度精简的水平，在去年底也没有超过 400 人，而 2018 年营业利润大约是 5.1 亿欧元（39 亿人民币）。在这样精英文化的氛围下，CEO Ilkka Paananen 力求员工不要被流程和管理机制束缚，给每个小团队足够的决策权。而且由于资源稀缺，每个小团队可以更加聚焦手中的资源，选择做最重要的事情。（Supercell 中的 cell 也是表达这个意思。）

（Supercell 的中台理念示意图）

这是组织中台化。

组织中台化对游戏的价值显而易见。游戏本来是创意行业，把决策权给业务前台、中台结构放权、CEO 主要来完成大家资源的支撑和整合，是合理的。

其次，据说 Supercell 是一定程度上实现了技术中台化，即前台业务团队可以利用现有的各种技术模块，快速敏捷地试错。（这点待求证，毕竟游戏的复杂度很高，不知能中台化到什么程度。）

这是技术中台化。

技术中台化的核心目的是成本。成本可以从两个维度看，一个是资源浪费方面的成本，即公司有三四个业务线都在做同样的事情了，那技术上实现能不能融合可复用的部分？另一个则是时间成本，即新业务能够足够敏捷地去使用既有的技术模块去做探索。

实际上，实现中台化的环境是相当苛刻的。连 Paananen 自己都说，他认为Supercell 的经验不是对所有公司都有效，有它自己的特殊性。他觉得 Supercell 的每个员工，都是能在外面成立公司自己当老板的，因此这种精英文化和中台化在公司得以保持。

2、中台有哪些类型？

反观国内的互联网公司，这几年都陆续提到了、或者在践行中台化。我了解到的许多中小企业，也在追随大公司的脚步，搭建中台能力。

不过中台化显然不是万能的提效方案，也不是适用于各种公司各种领域的。夸张点说，很多人口中所说的中台化，每个字儿看起来都一样，但压根都不是一件事情。

除了刚刚提到了组织中台和技术中台，还存在数据中台和业务中台。我们按照难易程度倒序逐一论述。

其一，技术中台（基础服务中台）。

技术中台指的是将大家都通用的技术能力聚合到一起，由同一个团队负责，防止重复造轮子，是最容易实现的中台化。核心价值是降成本，刚刚提到了。

各公司的基础服务，以账号体系为代表，都已经是中台化的了。淘宝、天猫、飞猪等业务之间，快车、专车、顺风车等业务之间，美团外卖、酒旅、团购之间，必然要做打通。

其二，数据中台。

顾名思义，表面上数据中台是各业务的数据能够打通。不过在实际运用中，又分为多种。

基本的数据采集、数据仓库建立和数据分析能力的共享，其实是数据技术中台的范畴，是将做数据相关工作的技术团队整合，来支持各业务。核心价值是降成本。

各业务线的数据打通、数据共享和协同运用，则属于业务中台的范畴，是以业务目标牵头的（比如阿里的88VIP会员的前提就是用户数据打通）。

有时这两者是耦合在一起的，既有技术能力的共享，又有业务支撑。不过在国内数据分析的认知还比较浅（认为数据都是拉报表的），后者往往效果不佳。前者在不少互联网公司倒是确实落地了。

在有些公司，数据中台只是很粗浅地把数据整合到一起，并没有解决任何问题，或者让整合产生什么价值。阿里云中间件架构总监谢纯良曾经说过，许多公司的数据中台就是把数据加工成“大屏”，搞一个展示用的“大屏”就以为实现了中台。意思就是，数据中台如果不为业务服务，或者说为业务中台服务，那就没有价值。

其三，业务中台。

既然技术模块可以抽象出来复用，那业务模块是不是也可以？在淘宝时用过的营销策略，能不能直接挪到飞猪用？专车的策略能不能直接给快车用？这就是业务中台的概念。

很显然的，由于业务存在更高复杂度，因此难度更大。

业务中台是各大公司追求的最终效果：前台业务敏捷推进，后台业务稳固支持。不过真实情况往往事与愿违，难尽人意，真正做到业务中台运转良好的，很少见。

其四，组织中台。

组织中台刚刚讲 Supercell 时提到了，是嫁接在前三种中台基础上，再加入“放权机制”的中台结构。

阿里的中台业务支撑能力可以支持新的电商相关业务快速创新；字节跳动把增长能力中台化，头条的增长部队可以快速投入到抖音中去，甚至可以投入到海外各个国家各个产品；美团有试错小团队，会利用既有的技术能力、用户流量等资源快速试错，找到新的方向，包括外卖在内都是这样来的。

这些都是组织中台的体现。组织中台与其说是中台能力，倒不如说是内部创业的空间。它的核心价值应该在于“旧业务能否帮到新业务”，很考验组织能力。有的公司内部创业，封闭隔离，跟这个公司自己投资了个新团队，没啥区别。

3、中台有哪些困境？

中台的难点有几个关键矛盾：

• 中台团队离业务远
• 中台需求的优先级难排序

先说中台团队离业务远。

为什么中台化的难度是：技术-数据-业务-组织？因为越往后，越需要业务团队的介入，越要有业务认知才能做到中台。而中台团队，天然就是离业务远的。

各公司跟中台团队的协作，都存在很大的低效问题，一线的前台业务团队，要反复与中台沟通，才能讲清楚业务需求的背景，在大公司，跨部门协作都会徒增成本。另外对于中台业务团队来说，长期离业务很远，没有成长性，在判断需求时也不准确，很难获得前台业务团队的信任。

久而久之，就变成了中台团队纯支撑、被动接需求的状态，成为“鸡肋中台”。更大的问题在于，中台团队的价值就是整合需求、抽象能力的，在对用户和业务不够了解的前提下，这块就会做得特别吃力。如果是多个前台业务的需求有了冲突，中台团队未必能做好协调，多方要反复沟通扯皮。

针对这个问题，通常有两个解决方案：

第一，中台职责直接由最大业务方来担任。

像贝壳的中台模块，就是由二手房先行推进的；而大多数通用的乘客司机产品流程，在滴滴也都是快车先发起的。最大的业务方离业务足够近，能自己决策判断大多数需求，更加高效。

这样以来，就从“硬找一个中台团队来收集大家需求”变成了“老大哥发挥余热，把自己的能力共享出来”，具体要怎么用，仍然是各自团队来决策和执行。

第二，让中台团队做业务闭环。

这只适用于少部分情况，即中台业务本身可以自闭环。常见的比如各公司的账号体系（包括注册登录）、阿里的支付和订单流程、滴滴的地图和导航。这些业务与其它业务的关联度不大，可以解耦，可以自己完成从用户到业务的认知和决策，那就可以独立出来自己做，其它业务希望使用的时候，对接通用接口就可以了。

而大多数中台团队负责的业务不太容易自闭环。比如滴滴不同业务线的接单流程，就很难抽象出来让中台团队直接闭环自己做；或者像阿里不同业务线的商品部分、订单流程部分和支付部分可以抽象，但用户体验方面，不同前台业务差异太大，则很难抽象。

再说，中台需求的优先级难排序。

很现实的问题是，中台团队会面临无数的需求，要处理优先级问题。怎样处理，很难有标准。

你可以说，用业务指标即可，比如哪个前台业务方的需求能创造更大业务价值。这当然可以，但这有悖于前面提到的“中台化是为了前台业务更高效，尤其辅助创新业务”的作用。因为很简单，你的创新业务没几个用户的时候，就永远得不到中台支持，那还做个毛线。

结果往往就是，若严格按照量化收益来排序，小业务和创新业务的个性化需求永远排不上，最后就只能自己完成，又是在“去中台化”了。

这个问题暂时没有什么太好的解法。跟每个公司的人聊，几乎都会碰到，小业务或者边缘业务对中台业务部门的诟病，认为不够支持，需求都被堵死。除了自己做，只能寄希望于，自己需要的，中台部门恰好已经提供了。

4、互联网公司中台的现状

各公司的中台化现状，基于我的访谈和了解，可以做一个简单的描述。

腾讯从大半年前提出中台化之后，已经由 TEG 牵头陆续实现底层技术的一些整合，以账户体系为主。数据的整合也在做了，不过应该更多类似数据仓库的建设这种底层整合。从业务中台来说，搜索、广告、信息流都在陆续整合，基本是钦定某家的方式，分别是浏览器、广点通、FCC（信息流与内容社区业务线） 牵头做。微信仍然是飞地，不受任何中台化影响，自给自足。

腾讯的难度应该是最大的，因为众所周知，山头林立，遍地赛马。一些新业务，无数团队都在做，而且是完全“去中台化”的方式在做。我有个朋友所在的团队，对内部严格保密地做新项目，怕被发现成了靶子，对外反倒是没有那么保密，很是魔幻。

阿里的业务中台化应当是做得最好的。网传的这张示意图较好地描述了阿里中台架构的情况。

中间的“业务平台”中，各中心（Center）承担自闭环的业务，是我前文中提到的对“离业务远”的第二个解决方案。由于电商环境下各环节的用户需求和体验都有较高相似度，且阿里的组织文化建设得足够高效，在阿里的中台部门不会存在太多“中台鸡肋”的情况，能够深入参与业务。

比如，阿里的用户中心（ User Center ）就是统一账户管理部门，负责用户画像、用户标签等一系列基础能力建设，同时也会负责前端体验（比如“我的淘宝”）。商品中心（Item Center）会负责商品详情页，既有后端的信息逻辑，也有前端的体验。不管是“我的淘宝”还是“商品详情”，中台部门都是提供一套完整的基础能力，由淘宝、天猫以及各种前台业务部门自己去个性化使用（可以简单理解成换皮）。

贝壳的中台刚刚提到了，是由二手部门牵头做，把二手和其他业务都面临的业务模块（房源管理、CRM系统、经纪人带看/跟进能力、合同签约等）抽象出来，提供给大家使用。中台部门没有单独拿出来，而是跟业务部门强耦合。

滴滴除了基础服务会有平台产品部和一些支持部门（基础信息、风控等），快车的不少业务模块就是实际上的中台（例如提供接单流程、营销工具）。网约车虽是核心业务，但与其它业务相对解耦（单车、代驾、顺风车、国际化、车服），对外中台化的模块不多，主要还是一些基础服务。

字节跳动的中台以用户增长（投放拉新为主）、技术（算法为主）和商业化（广告为主）三个部门为主，近期新增了直播中台。很明显的，这几块业务在各个方向业务上复用性比较强，业务独立性也足够。这样就能与阿里的中台类似，可以深入业务的同时保持中台的独立。头条的组织化极其看中效率，因此统一支持，效果俱佳。举个例子，用户增长团队是手握预算、以bp身份介入许多业务、有许多产品功能上的决策权的，这跟有的公司的用户增长其实就是市场投放而已，截然不同。

美团很少提到自己的中台战略或者能力。内部在搭建的主要也是基础服务中台和数据中台。对于业务中台来说，美团业务模式之间的差异性导致不太容易抽象（团购-外卖-酒旅-物流-新零售-单车-网约车）。不过美团的组织建设对新业务非常友好，每个新业务都是得到了老业务支持（当然前提是数据本身做得足够好）后生长出来的，无论是底层技术业务的支持，还是人力资源的支持，又或者是流量的支持。因此可以说美团具备一定的组织中台文化。

京东提出中台化后，也搭建了技术中台、数据中台，以及部分业务中台（比如搜索中台、营销中台）。从结构上跟阿里比较类似，不过相对低效一些，业务方与中台的协作不够顺畅，会出现前文提到的各种问题。

整体来说，各司的中台存在几个特征：

• 基础服务（账号、支付、安全、风控等）能力的中台，相对都很完备。技术中台基本多多少少都在搭建了，渗透业务的程度各有不同。
• 数据中台也大都在搭建中，不过还是侧重提供“采集、存储、取数”的能力，虽说降低了研发成本，但跨部门协作通常会增加协作成本；这样的中台，距离能提供业务决策洞察的数据中台，恐怕还比较远。真正一般数据分析的工作都是各业务内自己闭环，自己完成。
• 业务中台视情况而定，有的公司业务之间天然不适合做中台化。对于适合的公司，最常见的方式，一种是难以解耦闭环的情况，就采用“老大哥”式的方法，由核心业务来提供支持，比如贝壳、滴滴；另一种是中台有机会掌握自己的业务，比如阿里的电商中台、字节跳动的增长中台。

5、关于中台的建议

最后，对于中台化的问题，说几个总结。

• 中台化还是要遵循“具体问题，具体分析”的道理。没有放之四海而皆准的中台化策略，有的业务就不需要中台化，有的中台化反而会适得其反。有的公司压根就只有一个业务，或者有几个业务都没有重复造轮子的现象，那硬去学习阿里的中台，一定是东施效颦了。看阿里谢纯良的采访，包括我跟阿里的朋友了解到的，阿里的中台也是“痛极思变”的过程，在跌跌撞撞中成长的，不是老板一声令下就全部到位的。
• 中台化的目标都是降低成本，分两种：第一，现存业务之间重复造的轮子合并，降低成本；第二，为某些业务尤其新业务提供能力，可以低成本快速试错。
• 对于有的大公司，中台化不是个技术问题，反而变成了组织问题，就是各业务线要不要接受别人提供的东西，还是我就要自己做；以及对于新业务来说，能否得到老业务既有能力的支持。
• 对产品经理和运营来说，一定要加入可以业务自闭环的团队，不要加入纯支撑的中台团队。离业务远会很容易成为“鸡肋中台”。比如在许多公司，基础服务的中台，压根是没有产品和运营这样的业务岗的，都是技术。

希望能帮到你。