关于公司中台服务发展的一些思考

我们的讨论先从定义中台这个概念开始。

（一）中台的定义

定义中台我认为可以有两个角度：

 （1）从中台本身的价值和出发点来：中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合；

（2）从中台的相对定位来：前台是面向终端用户的一组业务能力，业务中台是对前台应用的抽象，提供多个前台业务之间共享的业务逻辑、数据和计算能力。

中台本质上是一个对业务能力的抽象和共享的过程，中台和前台的定义差别在于前台服务单个业务，目标是就是这个业务的增长；前台必须紧贴业务做好差异化；前台的定位要考虑到竞争环境、目标客群、业务成长阶段、运营人员能力、人才供给、监管环境等因素；前台要有自己的技术内容、定制流程、流程对接和个性化数据应用。中台服务整个集团，目标往往是降低成本、加强管控，或者是扩大规模优势；中台的定位在以集团利益最大化的前提下最大化服务前台业务的需求；中台有自己的技术实现、研发流程和数据标准。而后台是不具备任何业务语义的基础计算能力。下图就是对这种定位的一个示意：

（二）中台所解决的问题仍未过时

当前对中台的看法主要有两种极端，一种是认为中台是一个完全错误的方向，要紧急刹车；另一种是认为中台就是技术终局，是业务增长的不二法门。我们先分别讨论一下这两种观点。

不论是甲骨文还是后来的阿里， 其实本质动因是一个大公司内部的大业务呈军阀割据现象，导致多条业务线重复造轮子。由此而衍生出其他的问题， 比如说团队之间内耗严重；小业务无资源， 增长乏力；整个公司数字资产不统一， 损失机会成本；业务线也不能对核心系统做打磨，业务线不稳定。因为这些原因， 所以阿里的高管们就以美国海军陆战队和 Supercell 的组织形式为启发， 做了“大 (业务) 中台， 小 (业务) 前台”的策略。这里先不谈中台是否能解决这些问题， 或者是说战略启发是否正确， 但是毫无疑问的是， 中台想解决的问题既没有过时， 也依然正在不同的公司里发生， 所以这些问题还是必须解决。也就是说从问题定义角度来说， 中台是个完全正确的方向。

（二）中台本身的局限性

中台的解决方案至少有以下几个缺陷：

1、对创新的遏制：一个被完全中台化的业务导致集团内部过分分工， 任何前台业务都被认为是中台能力的线性组合。举个例子， 有的公司会有接近或超过千人的供应链中台、搜索广告中台、内容中台等等， 而多数业务前台少则几个人，多不过几十人。前台团队任何一个人哪怕是全职和一个中台域对接， 也无法理解该域的全貌或者跟上这个中台的演变。这意味着前台业务完全无法在这些中台相关的领域做创新。本来的创新业务变成无从创新， 当初的动力变成了中台最大的诅咒。有说法说，一个业务靠拖拉拽就能编排出来了， 这不是创新是什么？事实证明这种创新完全无用。没有任何一个投资人会把自己的钱投到一个可以被大公司拖拉拽出来的商业模式。真正的创新不是现有能力的线性组合。

2、反人性：中台自身的场景往往缺乏前瞻设计 ，是对现有场景的抽象。而当某个创新在一个前线业务线孵化出来之后，中台团队会通过强制收编该能力来扩大自己的能力， 同时强迫前台团队下线一个他们研发了很久的创新。这种行为往往造成精英人才的流失， 使得本来就受到遏制的前台创新变得更为匮乏。

3、过度设计：中台经常以最全的最复杂的实现来应对任何一个简单的应用场景。大量成熟行业和强监管环境下的需求被带入到了创新业务中。在带来大量运营复杂性的同时增加了用户（买家、卖家、本地运营）的学习难度。这就是我们常讲的膨胀软件（Bloatware）：巨大、复杂、缓慢、低效。

4、丧失对客户心智的追求：中台团队的产品和研发的核心技能在于抽象和降本。前台业务的核心能力在于对商业机会的捕捉和新商业机会的创造。这是两种完全不同的技能，往往对应着完全不同类型的人才。一个长期在多个业务中间找共性来降本的人是不会专注在最大化前台业务增长的。

之前做中台的公司往往被以上一个或者多个问题所困扰。也就是说中台事实上不是完美的。为什么呢？

（三）原因

我们先思考一下中台的本质。中台本质是把一些分散的重复的开发工作集中起来， 通过共享同一个研发团队来提升不同业务线之间的共性， 也就是通过抽象和统一来获取增量价值。具体的增量可以分成以下几类：

1、以零成本研发加速上线：对完全可以复用的标准化功能集中开发，未来以低研发成本上线，比如说一些无状态的计算能力，类似 SDK。

2、提升业务稳定性：对产品差异不大的领域，通过集中研发运维而获取更高的业务稳定性。这样一个团队开发的底层服务能够同时服务多个业务场景， 聚合所有的流量来加速积累。同时研发同学也通过更多的场景来加速打磨设计。常见的领域是会员、营销、交易、资金等服务。

3、加速技术和业务能力扩散：把整个集团的能力尽量跨 BU 复制。这包括两种类型，一种是类似 SaaS 服务的场景，比如说 Chatbot、直播、内容等领域；另一种是类似 ISV 的场景，由一个中央的团队同时提供研发，对内服务和运营，比如说安全、风控、财务、人力资源等。

4、统一数据资产：在集团内部统一数据标准，最大化数据复用， 把一个场景积累的数据优势应用到其他的业务场景中去，逐渐建设企业的数据壁垒。

5、集团层次的资源高效利用：把部分资源中央化，变成全集团资源， 比如说商品中台不但包括商品库，也包括商品质量控制体系、背后的货源、相关货源的价格以及服务竞争力。而商家中台，不仅仅是包含商家的信息，还包括商家的合作意愿和对集团品牌的信任，从而使得商家更愿意和一个新孵化的初创业务合作。集团真正想跨 BU 复用的是从一个大业务孵化而来的竞争力，而不是信息本身。

从研发和管理难度来说从１到５逐渐变难，而带来的增量价值也依次变得更大。

从这个本质来看， 那么中台似乎就是完美的， 那么之前提到的不完美又从哪里来的呢？我们有必要更深度的思考一下。

我们把这些要求归类成六类， 其中第一种场景细分成低成本上线和加速上线两个类别，那么这些类别有以下共同特征：

0、低成本上线：同一个功能模块在多个场景中被使用， 要求该能力的接口确定性高。

1、加速上线：同一个基础能力不需修改或者简单修改即可上线， 也就是模块化支持，要求高 API 确定性和好的功能通用性。

2、提升稳定性：同一个业务能力持续打磨， 要求需求同时具备高的接口稳定性和好的跨业务线通用性。

3、加速能力扩散：基础业务能力可以跨业务线模式， 要求该能力具备比较好的通用性，可以在多个业务线之间共享。

4、统一数据资产：数据模型可以在多个业务线之间统一， 对功能的通用性要求高， 且业务需求相对稳定。

5、集团资源高效利用：业务能力共享， 不仅仅是技术资源， 其实是业务能力有高通用性且需求稳定。

下图把这几个特征分别放在一个四象限图里面。这四个象限的横轴代表技术演化稳定性，竖轴代表功能的通用性。中台的优势领域在第三象限，这个象限技术具有高确定性，业务功能通用。第二象限属于比较稳定但是不通用的小众行业。第四象限属于普遍流行但是高速变化的领域，比如说内容和服饰或者端上的交互。而第一象限属于创新业务，不但定制化程度高且快速演化，比如说面向垂直行业或者初创技术。这是我们得出的第一个结论，也就是说：中台的使用范围是有限的，仅仅限于技术演化相对慢且功能通用性高的场景中。过往中台的失败案例也往往集中在把中台强推到创新业务中的情况。

第二条重要结论： 中台的建设要有与之匹配的组织文化机制。

寻找中台的合理组织机制（此处场景为大中台，小前台，本人所在公司为小中台，服务各业务线）

那么什么样的机制才是一个合理的组织文化机制呢？很遗憾我自己也不知道正确答案。但是我们或多或少可以从过去的失败中寻求教训，从历史中寻找启发。

先来思考一下过去的失败。我归纳下来大致有这么几个根因：

1、对哪个团队做中台或者哪个人来设计中台的决策是个自顶而下的中央决策过程。做中台的人没有所必须的抽象能力和业务理解，类似过去封建王朝的分封的过程。受封的仅仅是生在帝王家， 有没有治理和决策能力不重要。

2、中台的推行机制往往是个掠夺的过程。对业务线的创新直接复制， 不尊重发明者的知识产权和劳动。中台所到处，寸草不生。

3、中台能力一旦发布， 独家专供， 哪怕功能不完善， 设计不合理也不允许业务团队复制或分支。

4、中台为了做规模强制向业务线推行，业务线被迫削足适履，消耗严重。每次中台升级，小的 BU 更是叫苦不迭，故障频发。

其实这几个问题并非中台所独有。上面的四个问题其实和封建社会的分封机制类似，本来应该有市场选择、良性竞争和创新来完成的事情变成了强权。其实这个问题是有解决方案的。

伴随工业革命带来的人类劳动力巨大释放（具体见 Berkley 大学 De Long 教授对人类文明史的人均 GDP 分析）背后也有完整的机制，这些机制就是我们可以借鉴的出路：

1、机会配置由市场决定。

2、尊重知识产权和创新， 保护参与者的创新意愿。

3、通过自由准入维持市场活力。

4、最终由规模效应形成统一的事实标准。

虽然我还不能确定这是不是完整且合理的中台机制， 但是我们的思想实验至少给了我们避免过去的失败的一些希望：

1、谁来做中台、谁的设计才是真正合理的中台设计，由市场决定。

2、尊重原创，通过溯源和产权机制保护创新。

3、自由准入， 不做独家专供。

4、不强制推行， 设计统一是演化的结果， 而不是行政命令。

然而，这些思想指导下的中台演进，中台服务也出现了一些对应的问题。例如，受限于传统金融企业的组织架构，只要业务系统有需求，且存在复用可能的系统功能，业务系统均会要求中台服务进行功能的开发，中台的主管方此时也没有一个明确的标准来对业务（市场）需求进行甄别和过滤，这样会出现以下一些问题：

（1）在实现业务需求变为现实模块的过程中，对后续业务流程的改动越来越大，软件的概念完整性遭到了破坏。架构逐渐“腐化”了。 中台的各个模块建造了原先属于业务系统的一部分定制功能，对业务系统和中台服务的整体架构造成了一定的相互侵入，同时部分中台微服务如果没有后续复用，还会重新归还给业务系统维护，整体上影响了系统的健壮性和业务流程的简单性。

（2）任何一个微小的可能复用的功能都会建设成微服务模块，微服务的模块越来越多 ，最终需要进行多个小的微服务向大的微服务模块进行聚合。

（3）在中台服务的健设过程中，面临一些服务的拆分和聚合，需要在建设过程中有一个整体的规划。

（4）和业务系统的界限上下文经常会处理不好，导致中台服务承接了业务系统其中一部分流程，各种数据链路中均已中台服务模块的参与，各种环形和双向数据流向依赖存在，导致出现问题联合排查链路过长，需要考虑服务治理。

四、中台的演进机制探索

综上，中台本质上是一个对业务能力的抽象和共享的过程，中台服务整个集团，目标往往是降低成本、加强管控，或者是扩大规模优势。针对以上出现的问题，一些指导性的意见也要在系统建设中提出：

（1）单一职责，对新模块的建设以降成本为导向，而不是盲目的对复用的功能进行抽象和提取；  

（2）服务粒度适中，对于过小的或过多的需求尽可能考虑不进行建设； 

（3）演进式拆分和聚合，对需要建设的大的需求，拆分成多个微服务模块，对于小的需求，进行适当的聚合；           

（4）避免和前台系统在架构和数据流层面环形依赖和双向依赖

不过哪怕有这个机制， 我们还是要认识到中台天然的局限性。中台不是万能的， 它仅仅合适在高确定性和高通用性场景下创造增量价值。没有合理的期望设定，后续的迭代过程会变得漫长而艰苦，运行维护这样一套中台服务将变得异常艰难。