我看互联网技术的中（后）台架构
中台最近又成了比较热的话题，结合我对中台的认知，试图跟你回答下这些问题：
- 互联网公司的中台到底是什么？
- 中台有哪些类型？
- 中台有哪些困境？
- 互联网公司中台的现状
- 关于中台的建议
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、关于中台的建议
最后，对于中台化的问题，说几个总结。
- 中台化还是要遵循“具体问题，具体分析”的道理。没有放之四海而皆准的中台化策略，有的业务就不需要中台化，有的中台化反而会适得其反。有的公司压根就只有一个业务，或者有几个业务都没有重复造轮子的现象，那硬去学习阿里的中台，一定是东施效颦了。看阿里谢纯良的采访，包括我跟阿里的朋友了解到的，阿里的中台也是“痛极思变”的过程，在跌跌撞撞中成长的，不是老板一声令下就全部到位的。
- 中台化的目标都是降低成本，分两种：第一，现存业务之间重复造的轮子合并，降低成本；第二，为某些业务尤其新业务提供能力，可以低成本快速试错。
- 对于有的大公司，中台化不是个技术问题，反而变成了组织问题，就是各业务线要不要接受别人提供的东西，还是我就要自己做；以及对于新业务来说，能否得到老业务既有能力的支持。
- 对产品经理和运营来说，一定要加入可以业务自闭环的团队，不要加入纯支撑的中台团队。离业务远会很容易成为“鸡肋中台”。比如在许多公司，基础服务的中台，压根是没有产品和运营这样的业务岗的，都是技术。
希望能帮到你。
以上是 我看互联网技术的中（后）台架构 的全部内容， 来源链接： utcz.com/z/264113.html
