中台现在已经凉了吗

1、业务中台就是流程模板+扩展点
2、没法很好抽象就别做中台，没那么多需求和业务线就别做中台。

很多同学都会问，啥叫中台，做到怎么样的程度才算中台？我们可以用一小批一小批精英海空陆战队来说明这个例子。

我们都知道海空陆战队很厉害，但是他们不就区区 3-7 人小组，强在哪里？

原来背后有个强大的中台体系，正在海上待命，随时输送弹药。一旦3人小组侦查到地方精确位置，直接派空军或者导弹往目标上送，作战能力max。

我们从系统上，也可以创造这样的一些中台。

• 业务中台，提供重用服务，例如用户中心、订单中心之类的开箱即用可重用能力。
• 算法中台，提供算法能力，帮助提供更加个性化的服务，增强用户体验。
• 数据中台，为公司内外提供行业决策基础服务，增强数据的应用能力。
• 技术中台，提供自建系统部分的技术支撑能力，帮助解决基础设施，分布式数据库等底层技术问题。
• 研发中台，提供自建系统部分的管理和技术实践支撑能力，帮助快速搭建项目、管理进度、测试、持续集成、持续交付。

总之，我们把这些能够保证前台需求绝大部分能力开箱即用，但又能快速响应前台需求迭代的服务，我们称为中台。

什么叫快速响应需求迭代呢？为什么要有中台呢？是否需要搭建中台呢？我们今天只从业务中台的理念上，来梳理一下一个中台的定位。接下来我们通过一个登录服务实例，从大家熟知的构建一个登录服务平台到构建登录服务中台，比较平台与中台的差异，看看怎么做到快速响应需求迭代。

根据我们的设计一个登录服务平台，大体需要提供发送验证码，注册，登录，登出，身份/权限验证 等服务。

开始总是分分钟都妙不可言，我们设计的平台总能非常好地满足业务的诉求，对于一些需要扩展平台能力的地方，也响应得比较及时。但是，慢慢的，事情好像出了一些变化。在平台的发展过程中，业务方越来越多，需求也越来越复杂。

A业务系统想指定特定的校验码平台，而这个校验码模式我们是没有对接过的。平台开发人员和业务只好扑腾扑腾派两个人去对接。B业务系统来了，说想在登录失败N次后，给用户发送短信提醒，发送邮件提醒，平台开发人员和业务只好扑腾扑腾派两个人去接这些需求。C业务也来了。D业务也来了。慢慢的，这个所谓的平台，已经没有任何人在做平台了。

本来我们设计拆分前台与后台，是为了让前台来满足用户需求的快速迭代，期望后台趋于稳定。当我们平台开发人员并不能确保我们能搞清楚业务人员的需求是产品经理拍脑袋，还是实际需求时，大量频繁地平台开发，甚至规则变更。无论对平台的稳定性和业务团队来说，都是灾难性的。很爆炸。

说了这么多是否需要搭建中台呢？从例子中我们可以了解到：

1. 中台需要将实际的业务或技术沉淀抽象，想做好就需要有扎实的业务技术抽象能力。
2. 当产品条线很多，业务扩展需求很多时，搭建中台才更有价值，而产品条线少，业务扩展需求少时，中台并不经济。