中台战略实施：架构图很漂亮，可那张接口契约谁签？

凌晨一点，南京南站旁边那栋写字楼还亮着三层。订单中台要改一个字段，前台三个团队在群里吵。A说你先发版，B说我的对账脚本会崩，C直接甩了一句：当初谁让你们把接口定成这样的？没人接话。因为那张接口契约，压根没人签过。

这就是中台战略实施里很常见的翻车现场。架构图画得挺漂亮。微服务、领域驱动、数据湖，词儿一个比一个响。可一落到变更，全靠吼。

中台不是一堆微服务，它是一份可执行的契约

很多人一提中台，脑子里就是一堆服务。商品中心、订单中心、用户中心。再配个数据湖。看着挺唬人。说实话，那些只是壳。

中台是把多个前台都要用的能力抽出来共享，并且用契约保证它可被稳定复用。业务中台管交易和商品这类共享能力，数据中台管指标、标签和数据服务。技术选型只是实现方式。真正决定成败的，是契约写没写清楚：接口字段什么语义，版本怎么兼容，错误码怎么定义，限流阈值多少，变更提前几天通知，回滚方案有没有。别写“尽量兼容”。那等于没写。

我见过一个项目，商品中心被三个前台复用。听起来不错吧？结果商品中心没有明确Owner。前台提需求，谁接？排期听谁的？字段变更谁拍板？没人。于是每个前台都在自己库里留一张商品表。中台服务在那儿跑着，前台绕过去用影子表。架构图上是共享，代码里是各过各的。

中央厨房这个比喻挺老，但好用。中台像中央厨房，切配、腌制、半成品统一做。前台是门店，负责现炒和摆盘。可中央厨房得有时刻表、有菜单、有质检。没有这些，门店只能自己买菜。中台战略实施也一样。服务目录就是菜单，SLA就是时刻表，接口契约就是质检标准。缺一个，前台就会用脚投票。

先算复用账，再画架构图

实施中台，别一上来就搞全量接入。真的。先找复用频次高、变化相对慢、口径相对统一的领域。订单、商品、用户、库存，这些通常值得抽。营销活动呢？变化太快。硬抽进中台，前台会被拖死。今天加个玩法，明天改个规则。中台排期两周，活动早凉了。

复用账怎么算？看三个数。几个前台真的会用；一年能省多少重复建设的人天；故障和口径冲突能不能收敛。三个数都难看，就先别做。为了“中台”而中台，结局通常是多了一层转发，多了一堆会议。

有个零售客户，要求所有系统都接中台。创新业务也不例外。结果一个新业务上线，本来两周能跑，被中台排期拖成两个月。后来他们划了边界：成熟业务走共享服务，创新业务允许自治，只强制接用户和支付。哎，这就对了。中台不是集权。它是共享服务加自治边界。边界不划，中台团队迟早变成收费站。

指标口径打架，才是数据中台的日常

数据中台更典型。很多老板以为买套湖仓、接一堆源系统就叫数据中台。差得远。数据中台实施的核心工作，是指标字典、口径仲裁和血缘追踪。听着不性感。可它决定报表能不能信。

一个GMV，销售部门算含税，财务算不含税，运营把未支付订单也塞进去。三张报表三个数。开会先吵半小时。你说这是技术问题？不，是组织问题。得有人当指标Owner。这个角色不是官，是背锅位。口径变更要发公告，像列车时刻表调整。下游谁受影响，得提前知道。

数据中台不是把所有数据搬到一个地方，而是让同一个指标只有一个被认可的口径。技术上的湖仓、调度、血缘工具，都是支撑。没有口径治理，湖仓只是更贵的数据堆放点。

风险也在这儿。中台团队如果响应慢，前台就会绕过中台建影子表。影子表一多，口径又散了。所以服务目录要可见，成本要可见，SLA要可考核。别让中台变成黑箱。黑箱没人爱用。

组织账本不解决，中台迟早变成本中心

中台战略实施，技术只占一半。另一半是组织账本。前台要快，中台要稳。这两个目标天然打架。你不解决考核，中台团队就会变成成本中心。干得好是应该的，出问题背锅。

怎么办？几个土办法。中台服务设产品经理，别只设技术负责人。服务目录公开，像菜单一样能点。内部结算可以轻，但成本要看得见。变更流程双模：成熟服务走严格评审，创新服务走沙箱和灰度。中台团队的考核里，加一条“前台复用满意度”。别只考核系统可用性。可用性99.9%，前台就是不想用，那也白搭。

常见误解得说清楚。中台不等于微服务。中台也不等于数据湖。中台更不等于组织集权。中台战略实施，说到底是把“共享”从口号变成一张张有人签字的契约。契约背后是责任、排期和变更规则。没有这些，架构图越漂亮，夜里吵架的声音越大。

修地铁都知道先通一段。中台实施也一样。别全城开挖。先找一个高频复用场景，把契约、Owner、SLA跑通。跑通了再扩。跑不通，至少知道坑在哪儿。对吧？