大讲堂
技术中台的真实边界：不是什么都能塞的收纳箱
很多人对技术中台的误解，从名字就开始了。 有人觉得中台就是把所有系统的服务器堆到一个机房，有人觉得是搞个统一的登录入口，甚至有乙方给客户介绍的时候，说中台就是”企业的IT大管家”——这都是扯淡。 技术中台的核心是”可复用的技术能力原子化”。 最早把这个概念跑通的是阿里。2015年前后，淘宝和天猫各自搞了一套用户管理系统、一套订单系统、一套支付接口，双十一的时候两套系统同时扛流量，重复投入不说，还经常因为接口不兼容出故障。阿里当时干的事，就是把这些重复的技术能力拆出来，做成标准化的、可以给所有业务线调用的公共服务——比如用户身份校验、订单状态同步、大流量削峰的中间件，这才是技术中台的原型。 划个重点：技术中台管的是”技术能力”，不是”业务规则”。 比如连锁咖啡的会员积分规则变了，那是业务中台要管的事；但不管你积分是100分抵1块还是200分抵1块，底层的用户身份识别、积分数据的存储和调用，是技术中台要提供的公共能力。 别把业务逻辑硬塞到技术中台里，最后只会变成谁都改不动的黑箱。
现在的行业现状：一半是泡沫，一半是真需求
2021年是中台的风口，也是泡沫的顶点。 那时候只要是个科技公司，对外宣讲不说自己有中台，都不好意思拿融资。传统企业更慌，看互联网公司都搞中台，觉得自己不搞就要落后，不管自身规模多大、业务多杂，先砸钱把中台搭起来再说。 结果呢？ 2023年之后，我见过太多企业的中台项目被砍。某生鲜电商原来花了近亿搭的全链路技术中台，因为业务收缩到只剩几个城市，原来的公共能力根本没人用，干脆拆成了各个业务线自己的小系统，省了每年近两千万的运维成本。 但也不是所有中台都是泡沫。 国内某头部连锁咖啡品牌的技术中台，把点单、会员、库存的公共技术能力抽出来，新开门店的系统部署时间从原来的21天压缩到3天，逢年过节做促销的时候，不用再给每个门店单独改接口，直接在中台层统一配置就行，一年光IT运维的成本就省了近千万。 说真的，我见过最离谱的乙方案例，某公司给传统制造企业做的”技术中台”，核心功能就是把OA、ERP、CRM的登录页整合到了一个网页上，收了800万——这不是卖中台，这是抢钱。
踩过的坑：90%的企业死在了第一步
为什么大部分中台项目都成了摆设？ 我总结了两个最核心的坑，没有之一。 第一个坑：一开始就想搞大而全。 很多企业搭中台的第一步，就是把所有现有系统全部推翻重构，要求所有业务线半年之内全部迁到中台上来。结果半年过去，新系统还没原来的好用，业务部门怨声载道，最后要么偷偷绕开中台自己搞开发，要么干脆让项目烂尾。 第二个坑：中台团队和业务团队的权责边界，是落地的核心矛盾。 我之前接触的某互联网公司，中台团队的KPI是”能力复用率”，所以他们拼命搞统一标准，不管业务线的个性化需求，哪怕业务线要做一个只跑一周的临时促销活动，申请个接口也要走三周的审批流程。最后业务部门干脆自己搭了一套小系统，中台变成了没人用的摆设。 还有个容易被忽略的风险：数据安全。 技术中台把企业所有的核心数据——用户信息、交易数据、生产数据，都集中到了同一个池子里，一旦出漏洞，就是全公司级别的事故。去年某头部车企的中台系统被入侵，几十万车主的个人信息和行驶数据被泄露，光罚款就交了几千万，还赔上了品牌口碑。 对了，还有个很现实的问题：很多企业的规模，根本不配拥有中台。 如果你一年的IT投入不到500万，或者业务线只有两三个，重复开发的成本还不到中台运维成本的十分之一，那你搞中台干什么？给IT部门涨工资吗？未来3-5年：从“大而全”到“小而精”的转向
风口过了，泡沫破了，技术中台不会死，但会彻底变样。 我接触的几个云厂商，现在已经不推那种”全链路大中台”的解决方案了，转而去做按场景拆分的标准化PaaS产品——比如针对制造企业的设备数据中台，针对连锁零售的会员管理中台，针对内容平台的视频转码中台。这些产品都是把已经跑通的公共能力做成标准化的模块，企业不用自己从零搭，直接买过来就能用，成本只有原来自建中台的十分之一不到。 未来的技术中台，不会是统一的庞然大物，而是按场景拆分的轻量化能力模块。 也就是说，以后不会有”某企业的技术中台”这种说法，而是会有”某企业的设备数据中台”、”某企业的用户服务中台”，每个中台只解决一个具体的问题，和业务场景深度绑定，而不是放在机房里吃灰的摆设。 还有个很重要的变化：中台的考核标准，会从”复用了多少能力”，变成”帮业务省了多少钱”。 之前很多中台团队的KPI是”接口调用量”，现在企业更看重的是，这个中台能不能帮一线的车间工人少填两个表，能不能帮门店快速上一个新的促销活动，能不能帮IT部门少加几次班。
作者|大讲堂
排版|大讲堂
审核|小北