一、背景故事

说去中台，不得不提一下我最近看的关于中台的两个小故事，相信这俩小故事对于我们认识中台的由来有一个更为立体的观念。
正史版本：正史来自于钟华老师的《企业IT架构转型之道—阿里巴巴中台战略思想与架构实践》。说是2015年中的时候，马老师带领一众高管芬兰游戏公司Supercell，惊呼原来世界上还有这么高效的公司，回来后学习Supercell就提出中台战略。
Supercell是一家游戏公司，2010年中成立，马老师去看的时候才五年，但营收已经超过200亿美金，更神奇的是只有不到200人。2015年的阿里则是成立已经17年，马老师都熬不牢半退休了，营收才943亿人民币，员工数却高达34985，还正值马老师交棒给老陆（陆兆禧）后狂推来往而失败，正处于战略上的焦虑期。两厢对照，肯定会觉得Supercell真的是神，不服不行。
马老师应该特别喜欢琢磨公司的组织模式（你看阿里经常调组织架构），所以自然就发现Supercell这家公司很特别。Supercell的搞法是所谓的“细胞-部落”式，细胞是工作室，每个工作室就几个人，负责一个游戏，部落是共享的职能，负责公共、通用的游戏素材、算法等，为各工作室提供高效的支撑。这样的模式让Supercell特别善于创新试错，据说一个小团队几周时间就可以研发出一款新游戏推向市场，如果这个游戏失败了，公司甚至会举办仪式来庆祝从失败中学到了东西。
当然，阿里能全面搞中台战略，除了Supercell的神启，也是要有事实基础的。这个基础就是2009年成立的共享业务事业部，这个事业部在2015年的时候，已经搞了用户中心、商品中心、交易中心等十几个中心。也就是说当时阿里最具特征的业务中台已经相当有雏形了。
野史版本：话说2013年5月10日晚，数万阿里人相聚黄龙体育中心，参加淘宝十周年的纪念晚会。但大家知道这个晚会不仅是纪念淘宝十周年的，更重要的是马老师要在会上宣布退休，交棒给老陆（陆兆禧）。为了安全退休，阿里被拆分为25个事业部，并且实行了合伙人制。25个事业部各自为政，老陆上台后，根本搞不定这25路诸侯，无奈之下只能剑走偏锋，拼命做来往（阿里的社交梦）。老陆的算盘是要是来往做大，每个事业部都得求着来往要流量，那时我还不是让谁干嘛就干嘛？可惜来往没成，25个诸侯群起而轰之。马老师把老陆悄悄换下来，悄咪咪换上老逍（逍遥子：张勇）。
逍遥子上台，也得想办法解决这个诸侯的问题啊，不然干不了两年也得下台（甚至更严重，老陆后来不久连合伙人的资格都被剥夺了）。2015年5月老逍上任，年中马老师带高管拜访Supercell，大概率老逍是一起去了的。我觉得说是马老师受到了Supercell的神启，不如说是老逍受到神启。我想老逍一看Supercell的搞法，肯定会觉得太对胃口。只要搞“大中台”，美其名曰大家不要重复造轮子，25个事业部就变成了“小前台”，这不就把诸侯的问题解决了吗。中台的负责人，正是老逍多年的好战友行颠（张建锋）。
有句著名的伪名言叫“历史是个任人打扮的小姑娘”，阿里中台的正史和野史，都有真实的故事，但对背后动机的解读就完全不同了。我个人觉得，抱着兼听则明的原则，姑且两边都信一点为好。

二、什么是中台？什么不是中台

想要区分是否是中台，不如先聊聊通常生活中几个常见的错误观点：

  1. 大数据BI分析工具=数据中台。数据中台的价值在于可以利用数据展示业务的进展及方向，用数据推动业务的发展、产品的创新、管理的提效。总结为一句话：将数据渗透到企业业务以及产品闭环中。而大数据BI分析工具只是用数据展示业务内容，是一种总结性的业务数据分析。
  2. 大数据集群=数据中台。大数据集群仅仅是在建立数据中台底层数据存储和运算时用到的一部分技术架构。而数据中台是业务部门和技术部门经过资源整合、能力沉淀后形成的。
  3. 业务报表=数据中台。在企业日常运营中，成本报表、费用报表、财务预算、财务分析、进销存等一系列业务报表发挥着重要作用。但在企业管理中，业务报表仅限于对企业内部进行管理和监控，在企业外部维护用户、跟踪需求、更新业务和产品等方面发挥的作用有限。数据中台不仅能打通企业内部资源，实现资源共享，还可以助力产品持续创新、快速满足用户需求。相比之下，业务报表只体现了数据中台一小部分的价值。
  4. 某个应用=中台。
  5. 管理系统和数据分析工具的迭代=（数据）中台。很多企业期盼着这种“中台”给企业提供更多的管理建议。但这种并不是真正意义上的中台，这样的叠加无法将各个部门的数据打通，没有优化，没有总结共有资源。（数据）中台应该不是一套软件系统，也不是一个标准化的产品。而是一个能够支撑企业实现业务目标，沉淀业务的体系。
  6. 数据仓库=数据中台。有些人认为数据中台是搭建ETL（ETL 是指将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程）但其实并不太相同。数据中台是数据和存储分离的。数据中台本身没有数据，数据来源于各类文件和业务系统的API。数据中台拥有这些数据源的适配器，相当于建立了通向不同数据源的互联管道。数仓也是中台的重要组成部分。

结合上面六点典型认识差异，要定义中台，重要的是要能比较明确的区分中台和平台。中台和平台都是某种共性能力，区分两者的重点一是看是否具备业务属性，二是看是否是一种组织。即中台是支持多个前台业务且具备业务属性的共性能力组织，而平台没有相应的能力。

为什么要强调中台必须具备业务属性？可以来看一个例子。我们可以分析什么叫数据中台。如果一个企业把所有业务的数据都存储在Oracle里，我们能说这个Oracle数据库是数据中台吗？显然大家都会说不是（否则中台不是几十年的老古董了？）。那么现在很多企业换成了Hadoop，所有业务数据都在一个Hadoop集群里，能说是数据中台吗？显然也不是，这个Hadoop无非跟原来的Oracle一样存了一堆数据而已。有人说这是因为这个Hadoop集群只是一个系统，中台必须是一个组织。那么我们再加上建设和维护这个Hadoop集群的团队，整个加起来就是中台了吗？

仍然不是，因为这个团队是不需要为业务负责的，不具备业务属性。而现在大家比较公认的数据中台，指的是确保OneID、OneData得以实现的组织，使得数据不再是各前端业务独立管理，而是通过统一的团队在数据标识、指标、数据仓库等方面实现了跨业务的整合。之所以这样大家会认为是名符其实的数据中台，是因为指标一定是面向业务的，数据仓库的建设一定也包含了一些业务逻辑。所以那个大大的Hadoop并不是数据中台，而是大数据平台。

总结：
中台的定义：
1. 中台是一种共性能力组织，支持了多个业务。
2. 中台支持的是多个前台业务，并且具备业务属性。

三、典型的中台

广义上说业务中台包含了所有中台，不同的XX中台都是业务中台的细分方向（这取决于公司的定位以及发展方向），反映的是该中台在业务领域或者技术上的某些特征。但大家受阿里的影响，往往只用业务中台来指称在线业务中台。基于这个假定，当前典型的真正的中台大致只有以下几个：
1. （狭义的）业务中台：一般指在线业务为典型特征的中台。在OLDI（Online Data-Intensive）时代，越来越多的企业的核心业务都是在线业务，因此把在线业务中台简称为业务中台。但对那些不是以在线业务为主的企业，它需要的业务中台可能就不是在线业务中台了，而是数据中台或别的什么中台。

  1. 数据中台：在上一个环节介绍中，提到很多次数据中台与别的比较。那是因为数据中台是现在落地场景最多的一种。一般指以数据采集、数据集成、数据治理，指标体系和数据仓库统一建设等数据管理活动为典型特征的中台。同样，在OLDI时代，数据中台越来越重要。狭义的业务中台也就是在线业务中台负责OLDI中的OL（Online），数据中台负责OLDI中的DI（Data-Intensive）。

  2. 用户中台：用户中台可以认为是一种特殊的数据中台，一般以用户ID统一、全域用户画像建设、全域会员体系建设等为典型特征。用户中台很通用，比更广义的数据中台往往更常见。很多企业没能力建设更全面的数据中台，但建设了会员中心等用户中台。

  3. 内容中台：内容中台往往也可以认为是一种特殊的数据中台，一般以内容的采买、内容爬取、内容的加工处理、内容安全保障等为典型特征。

  4. 搜索推荐中台：这两个中台比较像，因为搜索和推荐的技术比较相似。这两个中台一般是为推荐和搜索系统提供一套相对标准的工作流程，同时支持流程各环节的可定制能力，从而支持多个前端推荐搜索业务的快速开发。

当然还有很多其他根据业务需要建设的中台，比方说对美团/饿了吗来说，本地配送体系可以建设为中台，前提是这个体系不仅用于送餐。

四、中台支撑技术

为啥在本文中还要介绍中台的的支撑技术，一是希望让中台这个形象更加饱满真实，二是为下一环节要不要建中台打下一定的铺垫。
中台的技术层面主要是SOA和微服务、DevOps、流程和规则、API网关等几个维度组成。
SOA和微服务：中台的能力以软件服务的形式提供，因此必须有某种SOA技术支持，微服务则是最典型的SOA实现。不过中台未必非要用微服务，只不过微服务更为顺应技术的演进方向
DevOps：中台采用精益产品研发流程，需要快速响应多个前台的需求，因此DevOps技术对中台至关重要。如果没有成熟的DevOps技术支持，中台要么响应慢，要么乱糟糟的仓促上线经常出事，这两种情况都可能导致前台对中台怨声载道，导致中台建设的失败。值得一提的是DevOps技术和中台一样，不是纯粹一种技术，一个平台或工具的事情，最重要的是该服务理念与思想进入参与的每一个人员的脑海中。
前台使用中台能力典型有两种方式：组合和配置。组合通过微服务等SOA方式实现，配置则主要通过流程和规则引擎支持。我们在建设严选中台时发现，仅靠微服务机制并不能很好的实现中台，流程和规则引擎也很重要；滴滴的分享中也提到中台实现的一个核心点是配置化，很多业务都是配置出来的；钟华老师的比升科技也重点提到业务可配置、能力可扩展。因此，流程与规则引擎也是中台的常见支撑技术。
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理、流量控制、日志、重试、熔断等。

五 、中台的组织

中台作为一种有业务属性的共性能力，中台作为一种有业务属性的共性能力，首先就需要一个懂业务、承担业务职责的专职的组织机构来负责。要不要建中台，首先要看领导有没有魄力去整合建立一个中台组织。因为原来的平台部通常不懂技术，懂业务的人各自分散在前台业务部门，所以建立中台组织往往涉及人员、组织架构和部门职责的调整。正因为如此，中台的建设往往需要作为一把手工程才能成功，这一点非常关键，否则中台就成 为劳民伤财的一件事了。
中台组织关键要懂业务和承担业务职责。举一个书上看到的例子：一个大数据平台的建设运维团队不是一个中台组织。一个团队如果做了非常完善的中台产品（如开发了数据中台所需要的指标管理系统、数据仓库开发系统、数据质量管理系统等等），但只是把产品提供给业务方使用，这个团队仍然不能说是中台组织。只有当这个团队承担起指标体系的建设和管理、数据仓库的设计和实施、数据质量的保障等工作时，才可以说是中台组织。而要做到这一点，这个组织肯定是比较了解业务的，它的目标和考核也一定与业务有相关性（肯定不只是平台稳定性这样的非业务指标）。

六、要不要建中台

结合前几个环节的介绍，可以看出中台背后的一些必要条件。比如

  1. 公司线上业务线是单一的，还是拥有庞大业务线呢，如果是单一业务线，搭建中台就有点劳民伤财；
  2. 根据微服务在大型互联网公司的不断实践，可以看出，微服务适合有一定规模的团队，具备规模效应，团队划分一般8人为一组对应一个微服务。有一点非常的关键：即服务的拆分带来的效益一定得大于服务之间调用的复杂性的
  3. DevOps的技术的使用：市面上拥有无数各种各样的相关软件平台，但是真正用好这门技术的公司屈指可数，因为DevOps是一组过程，方法与系统的统称，用于促进开发，技术运营，质量保证团队部门之间的良好配合和沟通的。
  4. 并不是数据量大就要建数据中台，主要还是取决对数据的依赖以及使用程度。电商为典型例子，大电商平台各个部门以及数据产品较为分散，指标，数据较为混乱，脏数据较多，那这样数据中台基本没跑了

总结：要建设中台，需要考虑组织，支撑技术，方法论等多方面才能去实施的，否则落地非常困难。

七、中台与产品经理

作为中台产品经理或者中台中某个微服务的产品线的产品经理，需要什么技能或者方法论呢？我认为有以下这些点：

  1. 流程方面：敏捷项目管理，DevOps需要有一定的理解和参与感
  2. 技术与业务架构方面：领域驱动设计（DDD）、微服务的思想都可以进行一定的涉及和消化
  3. 思想以及业务方面：业务的抽象能力，即在不拘泥于过于具体的业务形态，更多锻炼自己的构建模型的能力，是否能不仅仅关注自己手头的服务，是否能够取得和其他服务产品之间联系以及互动，是否能真正做到“one ID one data”的数据敏感程度，给前台提供标准，一致、高质量高效率低成本的数据业务服务。

八、总结

目前像字节跳动，这家号称APP工厂的公司，旗下头条、抖音、西瓜、懂车帝等多个内容型App，也有属于自己的大中台。火山引擎开放的技术中台包括AI中台、多媒体中台、数据中台、研发中台和移动中台五大模块，其中能力最丰富的是AI中台和多媒体中台。这些能力大概率尚且只是字节中台能力的一部分而非全部。
滴滴从2015年开始做中台，到2016年做了出行中台，很多出行业务都基于这个中台。基于出行中台孵化出了订单、计价、支付、passport、用户、触达等六大中台能力，这些能力2019年也开始支持非出行业务，演进为公司级的业务中台。除业务中台，滴滴还有比较庞大的团队做了数据中台。
京东2018年开启中台战略，主要通过组件化和平台化，面向“黄金交易流程”，涉及购物车、结算页、收银台、订单等核心交易模块。
以上都是互联网领域的案例，因为中台几年热度很高，一些非互联网行业也进行了中台建设，如美的和农业银行。关于中台的建设方向和详细理解每家公司可能都有自己的想法，但是本质不会偏差太多，保持一个开放和学习的心理在历史推进的进程中尤为可贵。