我的一年中台实战录：都在谈中台，究竟什么是中台？

其次，各条业务线里烟囱式的教学系统已经分开跑了很久了，在这个基础上搭建中台，就好像在给飞行中的飞机换引擎（当然，并不是每条业务跑得同样快，这也是中台能够在各个业务产品间周旋的基础）。

17 年阿里出版的那本书「阿里中台战略」是我们当时唯一找到的理论基础，阿里大中台几年的实践，以及 17 年我们通过一支几个人的别动队在内部对可行性的探索，最终让我们在申请立项时说明这事可以做成。

中台项目正式立项，我成为立项后第一个产品经理，Sunner 是负责人和产品架构师。我们计划用两年时间把中台搭建好，让爱多思能够支撑各条业务线的发展，并且能快速孵化出新的业务。然而一年过后，2019 年 2 月底，因为公司战略和组织架构调整，中台项目被停止了。

我依然清晰的记得那天，大家在会议室里讨论已经在线上跑的中台服务未来何去何从，想想在云端本地无数的代码库中有一套打着那天的 tag，然后就没有再更新过，让人唏嘘不已。

这一年的收获

回顾这一年，我们做成了这几件事儿：

当然我们也还有一些没做完的事儿，包括：

假如我们能有两年时间，不知道能否达成最初的目标，也不知道未来是否还有机会继续？但我几乎肯定的是：中台会在接下来互联网和传统产业深度结合时，变得越来越重要。名字除了叫中台外，还可能会被称为平台、中间件、共享服务等等。

此外对于我个人而言，应该说我这一年的收获良多：

都在谈中台，究竟什么是中台？

中台的概念

中台是近年来 IT 行业非常火的概念（这里最好加上一个”IT 行业“的限定，因为曾经有商务同事以为我是研究两岸关系的，哈哈），有很多的文章从产品、技术、组织等多个角度来解释什么是中台。对于一个快速变化的新概念而言，很难有标准定义，阿里中台某高管都提到过现在阿里所做到的离他所定义的中台还有一段距离。

给定义是非常谨慎的事情，但很多时候不给定义又没办法继续聊，所以我也曾经在一个内部分享上给中台做了定义「服务于某个垂直领域的工具平台」。在做这个定义时，我是参考了云计算的概念的。云计算是一种通用服务，那么中台和云计算有什么差别呢？按照 IaaS/PaaS/SaaS 来划分，服务的领域越来越垂直。参考这种方式，我会定义中台在 PaaS 和 SaaS 之间，主要原因如下：

中台 vs 第一性原理

很多资料在介绍中台概念时都会引用这样两个例子：

同时我想要对比的是另一个概念「第一性原理」。第一性原理也是近几年很火的一个词，基本已经成为完成颠覆式创新的大杀器。最典型的例子之一就是 Elon Musk 了。这个同时掌管 Solar、SpaceX 和 Tesla 的硅谷钢铁侠，从最基础的物理学原理出发，重新设计和制造的猎鹰火箭，正带领着人类飞向火星。

在上述例子中，第一性原理和中台都带来了创新和成功，但其实这两者在某种程度上是矛盾的。第一性原理往往是打破原有的经验，跳出舒适圈，从最底层逻辑去进行思考。而中台是将通用的能力进行抽象和共享，将成功的经验固化下来，将有限的人力投入到创新中去。

第一性原理是物理世界运转的本质，在没有时间条件的约束下，可以推导出整个世界。假如地球要灭亡了，只有一张纸上的信息能够保留下来，写在这张纸上的就是地球文明的第一性原理。基于这些可以重塑地球文明，但可能需要几千万年。

但人类社会的运转往往是有明确时间约束的，如果我只知道 1+1=2 时就要完成微积分，可能要穷尽一生。因此，依靠前人和自己的经验做事才是人类社会能够高效运转的基本要素，放在 IT 行业，这些经验就叫中台。经验往往能带来效率提升、成本提升、质量提高，同时也能带来偏见、惯性思维模式，中台也一样。

我们为什么要做中台？

随着「阿里中台服务」那本书在 17 年的出版，中台开始走进更多人的视野，并且在 18 年逐渐热门起来。但那时网上介绍中台的文章和分享还不多，记得我在准备公司内中台分享时，没有花多大功夫就看完了几乎所有相关内容。

而到了 2019 年，中台的热度迅速攀升，火爆程度有点类似 16 年的 VR、18 年的区块链。同时我也听说有创业公司连核心业务的商业模式还没摸清楚，上来就要搞中台。这其实是没搞清楚为什么要建中台、中台要解决什么问题：

首先，中台是支撑公司多个业务产品的共享服务，如果你的公司只有一个业务产品，能做的最多只能是良好的架构设计，没有多个业务产品的实际场景输入，是难以直接做出中台的。

其次，中台的目标是提高业务产品的研发效率，但为了达到这个目的，在一段时间内是需要以降低「效率」为代价的，时间长短取决于系统复杂度和团队能力的差距。

当公司随着业务发展，需要研发第二个、第三个产品时，在这种情况下可能会有两种方式来构建中台：

我所在的事业部发展了多年，有五条业务产品线。这五条产品线就是从一条产品线开始，随着时间的推移逐步发展起来的。和大部分研发团队的情况一样，在应对快速变化的市场环境时，我们没有能够做好系统的底层积累，而是选择了一条在当时看来是更简单的路径：从一套代码 copy 出了另一套代码来支撑新的产品。

多年后我们就有了五个独立的系统来支撑五个业务产品。我无法判断如果当时做好了底层系统架构，整个部门实际会发展成什么样。只知道当五个产品要在五套系统上快速往前跑时，研发的复杂程度和成本都太高了。为了解决这个问题，我们决定做中台。

当然我们也可以有另外的选择——砍掉大部分产品，只专注做到一、两个。但大家都知道，其实真正困难的不是决定做什么，而是决定不做什么，这种决策其实比做中台更加困难。此外，作为一家成熟的公司，一定是需要有能够形成合力的产品矩阵来支撑整个公司战略推进的，所以多产品并行是公司发展到一定阶段的必然选择，而做中台也绝不是站在其中某一个产品的角度来解决问题，而是站在多产品协同的角度来看公司的战略发展。

从公司战略来看，阿里巴巴的曾鸣在「智能商业」一书中提出了看十年、做一年的观点。在日益复杂而又快速变化的市场环境中，公司已经无法做到一个五年的准确的规划，并执行下去。而需要通过看十年的终局思维来看到行业最终会成为什么样子，从而制定公司愿景和方向。

通过做一年的方法来制定计划，快速落地一些事情，然后根据效果来迅速调整方向、更新计划，朝着终局推进。要想做到这点，基础能力的积累就非常重要，而中台也是其中非常重要的部分。

站在产品团队的角度来看，一个搭建完成的中台基础框架，能够带来的直接价值就是：

我们是怎么做中台的？

产品设计层面

随着中台的日益火爆，如何做一个中台产品经理也成了一个新的职业发展热点，最近也看到有了线上的中台产品经理课程。中台产品经理是 B 端产品经理的一种类型，有 B 端通用的能力要求，比如擅长做抽象建模、具备一定的研发技术功底、懂 UML 等，我在这里就不一一展开了。但就中台服务多个内部业务产品为主的特点来说，会对中台产品经理有些不一样的要求。在我个人的经历里，我认为有三点非常重要：

1. 中台产品经理如何设计出用户体验好的功能？由于教育中台对其服务的要求是从前端到后端的完整服务（具体原因在技术部分介绍），因此教育中台的产品经理所设计的功能需要直接面对最终用户，也需要保有良好的用户体验。

   

   在上图中，业务产品经理的能力要求偏向市场侧，中台产品经理的能力要求偏向研发侧，绿色部分是两类产品经理都需要掌握的。教育中台对产品经理一直有要求，必须走到需求的源头不能只接二手需求。抛开个人能力而言，这对其提出的难度在于：必须花大量的精力去熟知不同的场景。

   中台产品经理是按照功能模块来划分职责的（如题库、直播），但实际的使用场景是用户使用整体产品的全流程，并不会只看某个功能模块，因此每个模块的产品经理需要了解所支持的所有业务的全部场景，才能做好相关模块的设计。同时教育行业是碎片化的，不同业务之前的场景差异性比较大，某模块的中台产品经理如何才能快速的熟知所有业务的全部场景？这是一个难题。

   技术层面

   在中台架构的设计之初，我们就定位了教育中台需要提供的不仅仅只是后端服务，一方面纯后端服务和 PaaS 服务就没太多区别；另一方面由于教育中台所希望提供的服务的业务属性非常强，提供的服务复杂程度远高于常见的 IM、视频云等常见 PaaS 服务，如果完全通过后端开放接口来使用，接口的数量会非常多，调用的逻辑关系也会很复杂，使用成本会远高于常见的 PaaS 服务。

   因此我们希望教育中台提供的是前后端一体的服务，最终展现给用户的是前端模块 / 组件。理想的情况下，业务产品的前台页面只要嵌入中台某功能服务的前端模块，就可以使用该模块的完整功能。这种方式最大限度地拓展了中台服务的价值，但也给中台服务在设计中带来巨大的难度。经过一年反复的煎熬，我们也整理出了几条设计原则：

   理想情况下，教育中台搭建完一个模块，各个业务产品一接入就能完美的用起来。但实际情况下没有产品经理和研发具备这样的能力，反复是一定要的，甚至于有时候教育中台需要去做一个需求还不明确的功能（我通常反对中台新做功能来完成业务产品的需求验证，ROI 太低了）。当面对这样的情况时，一定要坚守的底线是数据结构的统一。研发同学都知道数据迁移是一个大坑，所以只要数据结构是统一的，任何逻辑和交互的变化都是可以接受的。

   数据结构的统一、后端服务的共享，是容易在思想上达成一致的，难的部分只是在执行。但前端界面统一的观点自始至终都在激烈的辩论中。对于一个 ToC 产品的产品经理和设计师来说，往往对交互、视觉都非常敏感，这也是 ToC 产品能够在第一眼就留住用户的最重要原因。

   但中台服务为了做到重用，往往很难在一些细节的交互上和视觉层上，百分之百的满足每个业务的需求。并且在这种用户体验的层面，往往没有谁能够说服谁。对于设计型的产品经理而言，不能把控自己产品界面里的设计，简直就是被亵渎，因此在前端界面统一这件事情上的争论有多激烈，可想而知，我自己在这件事情的立场上也有摇摆。在多个 case 的纠葛后，我们推动了几件事情，不敢说解决了这个冲突，至少是改善了问题：

   教育中台的用户是部门其他业务产品线的程序员，虽然都是内部用户，但降低用户的使用成本是非常重要的，我在组织架构部分会详细介绍。要想推动教育中台在内部业务的使用，必须要最大程度的降低用户的使用成本。

   第一年我们教育中台的别动队在搭建服务验证可行性时，服务的架构设计是这样的：

   
   业务产品的后端从教育中台的后端获取数据后，通过业务产品的前端拼装好再传给教育中台的前端模块进行显示。这种方案其实等同于把一个模块的开发按照人头分工到两个团队来开发，理论上来说可以满足任何业务的需求。早期在需求还不那么确定、业务也比较少的时候，这样去进行探索是可行的。但当接入的业务产品多起来，这种架构会带来几个很麻烦的问题：

   为了解决上述问题，我们改成了前后端直连的架构设计：

   
   在这种方式下：

   直连的架构在某些特定情况下会增加功能实现的难度，比如要在教育中台前端模块里去显示其后端服务没有的数据时，会面临拿数据困难的问题。但总体来讲带来的好处远远大于增加的难度，我们也基本确定了前后端直连的架构是教育中台服务首选的方式。

   中台策略对组织架构的挑战

   高层的支持重要吗？

   看过一篇文章「重新理解中台—中台的战略和困境」，对中台在组织架构层面的需求做了比较好的介绍，其中最关键的就是：中台是自顶向下的，中台一定需要得到高层的支持。

   和绝大多数商业化的事业部一样，我所在事业部的 KPI 一直是可量化的营收数据。而中台项目在启动运转的相当长一段时间内，我们所做的很难对 KPI 有直接帮助，甚至于在局部较短时间内是阻碍当年 KPI 达成的。

   大部分员工是很难站在一定的高度去做一个”看十年、做一年“的规划，特别是当一件事和眼前的 KPI 难以达成平衡时，中台的工作会受到各个方面的挑战。因此高层的坚定支持是中台战略的第一必要条件。中台的价值是有条件的，搭建完成后还得有机会来享受成果，这个判断也需要高层来完成。

   此外高层还需要推动一些规范的建设，如交互规范、视觉规范、视觉配套的前端组件规范等，在这些规范的约束下，中台服务搭建的难度会大大降低。

   各业务产品的支持重要吗？

   高层的支持是基础，但在中台和业务产品实际工作中，无数次的碰撞都需要靠中台自己的影响力来推进。因此中台如何在各业务中获得影响力，并推动各业务接入服务也是至关重要的。那么如何推动业务产品接入中台服务呢？

   保留力量，去做重要不紧急的事情

   由于互联网公司多年来信奉的就是「唯快不破」，团队在做优先级排序时，往往会倾向于去做业务价值最明显的事情。有很多重要不紧急的工作就被压在后面，永远没有再被提起过。但对中台产品团队需要有不同的要求，中台产品一定要保留力量始终去做一些基础的、重要不紧急的事情。

   就好像公司如果想要做得长久，除了在商业上的持续投入外，一定要保留足够的人力来做基础性的研究，近期华为的海思芯片和鸿蒙操作系统就是最好的例子。

   我们在做中台时，无论外部各个业务需求的压力有多大，都应该始终保持有一个小队在做基础组件和规范建设。比如在各套业务产品里的权限体系都还能跑、但某些功能始终无法完美支撑时，我们按照 RBAC 的方式进行一个新的角色权限系统的设计，并提供了数据迁移方法，也最后为新的业务模块功能开发打下了基础。

   中台价值的量化

   即使我们都认为一件事情是正确的，价值量化依然是最重要的事情之一。中台是一个 ToB 服务本质上是成本的节省和效率的提升，但由于中台的客户是内部业务产品的程序员，这个价值的量化就变得比一个给销售用的 CRM 系统要复杂了。

   中台是提供给多个业务服务的共享服务，任意一个中台服务都可以为业务节省成本，因此被越多的接入，整体节省的成本越大。同时由于每个业务在整个事业部里都有不同的优先级，被高优先级业务接入的中台服务，能够产生的价值就更越大。这是符合直觉的，但如何去量化这样的价值呢？提供以下的计算方法：

   假设：

   可以推导出每个服务开发出来后对整个部门节省的成本是：

   由于中台团队要同时面对多个业务的需求，根据以上公式，我们也可以得出一些判断需求优先级的基本规则：

   青山绿水，江湖再见

   从教育中台组的解散到今天，已经过去差不多五个月了。在写此文时回忆起中台这一年，感慨万千。

   感谢两位主管 Sunner 和 Genify，Sunner 作为中台业务负责人和产品架构师，亲手搭建了整个教育中台的底层基础和业务抽象，包括「爱多思」在内的很多特有的名字都是他取的。他是我直接的老师，他对爱多思能够成功的信念、是我在多次迷惑中能坚持到最后的最主要原因。Genify 是研发负责人和技术架构师，从抽象的业务模型到实际可执行的技术方案，再到技术规范的形成，中间依然需要有一条靠经验和想象力来架设的桥梁，而他就是这座桥梁。

   感谢一起战斗过的和没来得及深入合作的同事，这些思考和追忆属于我们每一个人。感谢部门老大，没有他的支持，中台根本不可能立项。青山不改，绿水长流，他日江湖再见，自当把酒言欢，就此别过。何少甫，网易有道中国大学 MOOC 资深产品经理，所关注领域主要为在线教育和企业服务。