编辑导语：中台到底是什么？要怎么做呢？本篇作者以真实的案例和个人经历的方式跟我们分享了作者自己对中台的理解，讲讲中台是怎么落地实施的，怎么将一个业务需求转化成中台需求的，好让大家对中台有个非常具象的认知，一起来看一下。

中台概念大家已经很熟悉了，各种定义满天飞，但是中台到底是什么，怎么做，还是需要做了才知道。我现在以实实在在的案例让大家明白中台。当然了，毕竟接触中台时间还是不够长，免不了出现一些有偏差的观点，有看到的中台大佬可以指出。

一、中台的定义和角色

中台的定义可以从很多公开资料找到，我这里不再做赘述和解释。我在这里期望以更白话、真实的案例和个人经历的方式讲讲对中台的理解，讲讲中台是怎么落地实施的，怎么将一个业务需求转化成中台需求的，好让大家对中台有个非常具象的认知。

谈起角色就要有对象，中台对于前端业务来说，是业务后端。前台业务不是很关心你怎么实现，也不关心是中台实现还是业务系统自己实现，只关心你能否实现我想要的前端展示、交互、逻辑等等。

中台对于前端业务的后端系统来说，类似一个有强大能力的第三方服务商，这个第三方服务商有某个模块的各种接口和能力，我按照这个第三方规范的接口文档给信息，对方就能够实现我这边业务的这个模块想要的底层结果，不需要我针对这个模块再做一次开发。

所以，如果从业务角度看中台，他承担了一部分业务后端系统的角色，也承担了一个第三方服务商的角色。

二、什么样的人适合做中台

我们都知道，业务系统如果做的不合理可以等以后重构，也可以为了应付紧急需求而做很多阉割版功能，甚至可以让产品新人和技术新人操刀，只要实现业务需求就可以。

而对于中台来说，不管多小的中台，都需要有非常清晰的产品规划，产品要知道业务以后可能做什么，会怎么玩，落地下来就是业务某个功能点以后可能怎么做，我中台底层模型如何搭建，才能让中台的扩展性很强很灵活很好支持多变的业务。

中台的重构成本相比于业务侧，是翻倍的，越灵活重构成本越高，对接的业务侧越多，重构成本也越高。

那么问题来了，你如果不懂业务，能做中台的产品吗？

答案肯定是否定的。

所以做中台的人一定是对业务很了解的人，无论是产品还是研发，请记住懂业务是前提条件，不仅仅懂自己的业务，还要懂与自己相关的上下游业务。

由于中台的搭建往往是围绕一个需求考虑具体的产品实现方案和技术实现方案，所以中台产品**还要对技术有一定的了解，了解越多越容易切入角色，越容易产出更符合中台定位的产品方案。

另外，搭建中台大部分是从零到一，搭建好基础后期比较好维护，而且是多个团队协作，涉及到模块拆分和能力域边界的划分，所以**要有经历过从零到一的项目的经验，能够知道如何跨团队协作。

如果产品或者研发只懂业务，没做过中台，能做中台吗？

也不是不能，要组一个低成本的高潜力团队。

如果产品没有做过中台，就要求产品具备较强的抽象能力，搭配做过中台的研发。

如果研发没有做过中台，就要求研发有较强的抽象能力，搭配一个懂中台的产品。

以上都是相对好且低成本的团队组合，在配合时保证大家能够在预知未来业务走向的情况下，合理设计中台的产品方案和技术实现方案。

前面说的是技能方面，那从个人追求上面，你适合做中台吗？

答案是看个人方向了。

有的小中台配备的产研人员是既负责业务需求又负责中台需求的，所以离业务可能比较近，对业务侧产品实现方案是有一定决策性的。

但是相对纯粹的中台人员面向的需求方是业务侧产研，会导致离业务较远，此时中台往往无法决策业务该怎么做，只要业务有场景，有一定的合理性，中台就应该可以支持或提前支持，不能让中台成为业务的瓶颈。

在决策过程中最多也就是在讨论或者接收需求的时候，质疑一下业务对问题本质的挖掘深度，质疑问题的解决方案和优先级，进而提出更优的解决方案和建议，但是最终的决策权并不在中台。

或者说，因为一个业务流程的完成可能被多个中台配合或分割，如果你对业务有建议和想法，只能在和你中台能力相关的问题上你有一定的影响力（因为你可以不推进需求），而和你中台不相关的内容你是无法干预的。

所以中台有时候会离实际业务比较远，决策性和影响力较小。

根据上面的情况，中台适合非常熟悉业务，抽象能力很强，且在业务上面没有过多奢求的人去做。如果你还想干预业务，还想让业务按照你的想法落地和排期，那么你目前不适合做中台产品，可以过几年再试试。

但是貌似所有研发同学都对中台非常感兴趣，因为中台的实施无论是从性能还是从技术实现方案来说，对研发同学都是一次挑战，是自己能力的体现。

三、中台的划分和交互框架

在日常业务系统规划中，我们会将业务系统划分为多个模块，由不同的团队分工负责，模块划分的颗粒度取决于业务的发展程度，如果一个模块要做重做细做好，这个模块就会被划分的很细，有专人负责做深做强。

日常业务可能会被划分为：用户会员模块、商家模块、商品模块、营促销模块、交易订单履约模块、售后模块、支付结算模块等。

同理中台也会像业务系统一样，按照业务域被分割为多个中台。按照上面的举例，中台会划分成用户会员中台、商家中台、商品中台、营促销中台、交易中台、订单中台、履约中台、支付中台等。

中台的划分在各个公司不是绝对相同的，除了按照业务域划分之外，还有较大的公司特性和团队平衡问题，这里就不再深说。

中台自身又会按照能力域被划分为多个子域，每个子域都有不同的能力。

比如：

1. 用户会员中台会被划分为：用户域、会员域、卡券域等。
2. 商家中台可能会被划分为：商家域、组织架构域、权限域等。
3. 商品中台可能会被划分为：商品域、价格域、库存域等。

上面的中台和能力域说完，大家可能也很清楚了，其实各个中台组合起来就可以支撑一些基本的业务诉求了。

所以一个中台存在，如果要发挥价值，他必须要和业务系统，和各个中台之间共同协作，才能完成一个完整的业务流程。

和中台交互的系统包括各个模块的业务系统和各个中台，由于公司和公司之间的技术约束不同、业务范畴不同，还会有些其他平台用于支持中台和业务系统间的交互，比如一个低代码定义平台等。这里我们不讲交互细节，就从框架上讲一下交互的规范类别。

从大类上来说有两种：直接交互与通过公共平台交互。

1. 直接交互会造成的问题是，一个业务系统要对接多个中台时，需要做多次对接，成本较高。优势是对接自由，往往适合团队比较小，业务不是非常复杂的小型中台，流程和约束不那么多。
2. 通过公共平台交互的问题是，前期实施成本较高，实施前就要做好相应的规划，每个系统的定位要清晰，公共平台不仅仅用于中台和系统间的对接，还可能承担低代码产品融合的责任。每个业务中台需要将自己的中台能力和接口注册到公共平台上，业务系统按照统一规范进行对接。优势就是即使一个系统要对接多个中台，也可以在公共平台上通过配置的方式完成，对接成本较低，而且容易塑造规范性和标准化。