中台是什么

在不同行业、不同部门，有不同的中台定义。对于技术领域，中台大致有以下功能：

• 沉淀能力
• 节约资源
• 业务研发的效能提升

再叠加业务属性，电商团队可能有订单中台，直播平台可能有AI中台等等。 虽然形式不一样，成立中台总是为了解决以上几个问题为目的。

中台什么样

除了大厂，各类中厂也在广泛的尝试做中台。 一般来说，中台会有两种分类方式：

• 按技术分类：技术中台、业务中台、数据中台等
• 按业务分类：订单中台、营销中台、产品中台等

具体分类方式跟公司战略管理有关，公司技术驱动，更倾向按技术分类来建立中台。如果是业务驱动，更倾向按照业务分类来建立中台。当然也有霸气企业直接建立中台bu（事业部），统管一众中台。 听上去就是个烧钱的事情。既然都叫中台了肯定不会直接参与业务，也就意味着不赚钱，不直接接触客户。 所以有很多声音觉得中台就是个看上去美好的概念，因为离客户远，“听不到前线炮火”，产出容易不切实际。 对于老板来说，一帮人不对项目负责，也不知道在干嘛，光是嘴上说的好听，实际看不到什么产出。

小团队就不需要中台吗？

中台看上去就是个昂贵且无用的东西，是不是小团队应该避而远之？

成立中台的初心就是为了节省成本，如果有方法能够避免这些问题，对于小团队来说，中台就是刚需。

小团队第一考虑活下来，只要有快速、便宜、容易的方法就是好的方法，只要能符合这些特点的就是小团队正确的选择。

所以为什么选java而不是scala，选spring mvc而不是webflux，选mysql而不是postgre，这些都符合快速、便宜、容易的选择。

如果中台也能符合这样的特质，就是最适合小团队方法论。

小团队怎样做中台

这就需要从组织架构和技术架构两个方向描述这个问题。

组织架构：

单独成立一个部门或组？太贵了！

由管理者或者单独指定某个成员成立一个虚拟中台部门，如果团队稍大，可以按照技术或业务进行分类，团队小的情况下直接有一个虚拟的中台部门就够了。

部门有了，成员也是虚拟的，工作成功由大家平时的贡献而来，类似开源社区的组织形态。

小团队也不需要多重型的中台建设，因此“业余”时间的成果是能够满足绝大多数需求的。

在这里可以使用绩效引导，这就是为什么得有个人兼职中台的负责人，他要负责统计贡献好计算绩效。在日常、年终绩效或者晋级的时候体现。

技术架构：

部门有了，人有了，绩效安排也有了，具体做什么呢？ 非业务层面，重点封装中间件及业务无关抽象SDK，例如：权限、操作日志、日志、缓存、请求和链路、metrics、id生成、retry、context、异常 业务无关基础服务，例如：网关（附加了公司特殊业务需求）、sso、事件中心、定时任务、模型抽象、分布式事务、错误、静态资源、异步任务管理、下载和导出、支付、消息通知、审批和流程 业务相关基础服务，例如：订单抽象、客户抽象、商品抽象、线索抽象。对象划分逻辑可以参考我的另一篇文章《什么是ddd？一文读懂领域驱动设计 》这些内容不用刻意去做。假如现在要接入外部短信api，可以设计一个消息中心服务做抽象管理，再叠加一个短信对接。功能上可以比较简单，将来假如要增加延时消息，模版消息管理等功能，完全可以在抽象服务中完善此类功能，不需要对上下游代码做任何改动。（适配器模式的使用）

慢慢的，能力沉淀下来了，研发效能也提升了，开发能力也上升了，头也不那么秃了。

往期内容：

什么是ddd？一文读懂领域驱动设计

更多精彩预先知道：

技术人如何做管理：小技术团队的hrbp

技术人如何做管理：怎么产生技术“味道”