为什么建中台

一、前言

离数学越远代码，价值越低！

代码编程是对数学逻辑的具体实现，就相当于用砖头盖个厕所、码个猪圈、砌出个砖墙等是一样，砖还是那批5毛钱的砖，但盖在哪里盖出了啥价值就不一样了！

程序员也一样，你码的砖是公司里的；核心组件、通用模块、高并发业务还是一些ERP查询、接口包壳、屎山寻宝呢？通常那些复杂的业务逻辑或者具备一定技术深入的核心组件，才是最让人程序员快速成长的地方。

当然有些时候没有办法，不是不想做而是没得机会，或是因为初入职场、或是由于部门较差、也可能更多的是当前自身能力不足等等。但终究成长是自己事情，有了方向快是最大的障碍，脚踏实地把自己武装起来，才有谈判的机会！

二、为什么建中台？

1. 什么时候热的

通过百度指数搜索中台关键词，发现它是从19年5月21日突然热起来的，如下图；

2. 怎么就热了呢

说来奇怪怎么中台就热了呢，发生了啥？

• 啊！怪不得，是流量大佬腾讯于 19年5月21日召开了全球数字生态大会，会议上腾讯高级副总裁 汤道生提出"开放中台能力，助力产业升级"。
• 原文：腾讯汤道生：腾讯开放中台能力 助力产业升级

3. 中台从哪来的

你玩过《海盗奇兵》吗？那《部落冲突》、《皇室战争》呢？咋滴，玩游戏还和中台有关系？

• supercell（超级细胞），芬兰移动游戏巨头。拥有《部落冲突》、《卡通农场》、《海岛奇兵》、《皇室战争》和《荒野乱斗》 [1] 等全球热门游戏。
• 芬兰移动游戏巨头supercell在2016年3月宣布，公司旗下游戏每日活跃用户（DAU）人数已经突破1亿。这家公司的CEO埃卡·潘纳宁（Ilkka Paananen）在推特上分享了这个消息，并向全球玩家表示感谢。
• 在Supercell，每个独立游戏开发团队，称为"细胞"团队，核心人员通常只有5人，最多也不会超过7人。员工虽然少，但都是行业顶尖人才，还有充分的自由度。
• 团队自己决定做什么样的产品，然后最快时间推出产品公测版，看看游戏是否受用户欢迎。如果用户不欢迎，迅速放弃这个产品，再进行新的尝试，期间几乎没有管理角色的介入。
• 团队研发的产品失败后，不但不会受到惩罚，甚至还会举办庆祝仪式，以庆祝他们从失败中学到了东西。
• 2015年年中，马云带领阿里巴巴集团高管，拜访了位于芬兰赫尔辛基的移动游戏公司Supercell。
• 腾讯控股与其他参与财团已于2016年6月21日下午6点左右（北京时间）发布最新消息，确认已同意透过买方（财团的全资附属公司）收购Supercell的大部分股权。

综上，一个马老板收购了大部分股权，另一个马老板从 Supercell 团队开发模式，闻到中台的味道，细胞和部落 对应 小前台和大中台，至此半年后每一个程序员都被中台洗礼了。

三、建了哪些中台？

1. 技术中台

• 难度：⭐⭐⭐⭐
• 描述：技术中台提供了建设系统所需的基础设施、开发环境、数据服务、分布式能力等各类底层技术问题，同时技术中台有时也涵盖了研发中台的概念，主要是为了帮助工程的快速搭建、测试、集成、交付、运维、监控等。
• 备注：技术中台基本是每个公司必备的，但可能每个公司会有多套测试环境、预发环境、上线环境，以及各类技术组件存在多套。建设中台的时候需要把这些能力进行整合，统一建设，统一维护。

2. 数据中台

• 难度：⭐⭐⭐⭐
• 描述：数据中台提供数据采集、运算、分析、算法等数据动作，并提供相应的数据服务；量化指标、人群标签、知识图谱、业务报表等。

3. 业务中台

• 难度：⭐⭐⭐⭐⭐
• 描述：业务中台提供可复用的服务能力，例如：交易、支付、活动、用户、订单等，这些服务可以标准化、简单化、统一化。
• 备注：中台最想也最难的就是对业务中台的处理，支持浅了满足不了业务诉求、支持深了又太个性化满足不了所有需求。同时每一块业务拆分时可不只是系统，还有相应的业务、产品、运营，他们该如何提需求又提给谁。提的太复杂中台做不了，给后台做，做多了又想着平台化了。所以这也是最难的一块！

四、刚建好又要拆？

原来是建中台火，现在突然变成拆中台了。如果不是阿里自己说要拆中台，可能其他人也不敢说！

拆中台的起因是阿里内网说中台太厚了，影响到业务发展和敏捷响应能力。为啥这么说呢？

说白了，中台、低代码这些概念的指导结果，都是为了通用性服务的组装和编排。对于创新型颠覆式的需要快速试错的业务场景，就不太容易使用中台搭建。

但中台很适合类似盒马这样的场景诞生，有用户、有订单、有支付、有营销一整套的服务在中台都可以支撑，对于快速建设同类服务就变得非常容易。

可一些创新性，中台不具备或者不完全具备的服务，在通过前台、中台、后台，就变得非常困难，所有的需求没得把中台击穿就已经错过了市场。所以说中台太厚了，要拆中台。

1. 新需求响应难度增加

当中台为了通用性、共用性、平台性的原则建设新需求的时候，实际对业务响应的敏捷度就是下降的。

这包括一个新需求，不需要你的流程太长、也不需要你的通用性、甚至可能不需要你做完整的分库分表、数据采集、接口通用等等，如果你都按照中台的方式建设，那么这一个小需求的整体时间成本都将翻倍。

所以当这样的需求越来越多以后，你会发现建设的中台并没有沉淀下可复用的服务，这些服务最终后被前台系统沉淀下来。本来希望是中台做的厚一些，现在看是前台变得更厚了，前台对中台的依赖也越来越小了。这主要是因为前台离需求变化最近，敏锐度最高

2. 服务集成复杂度增加

中台提供了大量可复用的接口，但一个需求的实现会需要很多中台的接口集成，最终因为这些接口串联、组合、调试都过于冗长，使得效率不增反降。

原本一个需求由一个组可以实现，现在依赖中台需要很多组开会、协同、排期，严重拖慢了交付的进度，同时也不一定能提高交付质量。

3. 可复用实现难度增加

如果为了可复用则需要把一个需求放大，考虑它会发展成什么样，将来要扩展出哪些功能，留出什么样的口子，打哪种地基建设。基于各项的考虑把各类支撑需求的服务抽象化、去业务化，提取共性支撑业务组装。

这就像中间件的建设是为了屏蔽底层差异化一样，而你屏蔽的时候各类业务的差异化，而一个业务需求的变更都可能会影响到实际抽离出的业务组件该如何支撑。如果因为中台的通用性不能支持差异化需求，那么这类需求就会被建设在前台。

所以一个公司原本就没有很深、很广、很足的业务场景覆盖度，那么中台的建设会成为需求的绊脚石，投入的人力也将增大，每一次需要构建和完善时也会成为中台建设的灾难。