TL;DR(too long don't read)
1、业务中台就是流程模板+扩展点
2、没法很好抽象就别做中台，没那么多需求和业务线就别做中台。
很多同学都会问，啥叫中台，做到怎么样的程度才算中台?我们可以用一小批一小批精英海空陆战队来说明这个例子。
我们都知道海空陆战队很厉害，但是他们不就区区 3-7 人小组，强在哪里?
原来背后有个强大的中台体系，正在海上待命，随时输送弹药。一旦3人小组侦查到地方精确位置，直接派空军或者导弹往目标上送，作战能力max。
我们从系统上，也可以创造这样的一些中台。
业务中台，提供重用服务，例如用户中心、订单中心之类的开箱即用可重用能力。算法中台，提供算法能力，帮助提供更加个性化的服务，增强用户体验。数据中台，为公司内外提供行业决策基础服务，增强数据的应用能力。技术中台，提供自建系统部分的技术支撑能力，帮助解决基础设施，分布式数据库等底层技术问题。研发中台，提供自建系统部分的管理和技术实践支撑能力，帮助快速搭建项目、管理进度、测试、持续集成、持续交付。
总之，我们把这些能够保证前台需求绝大部分能力开箱即用，但又能快速响应前台需求迭代的服务，我们称为中台。
什么叫快速响应需求迭代呢?为什么要有中台呢?是否需要搭建中台呢?我们今天只从业务中台的理念上，来梳理一下一个中台的定位。接下来我们通过一个登录服务实例，从大家熟知的构建一个登录服务平台到构建登录服务中台，比较平台与中台的差异，看看怎么做到快速响应需求迭代。
根据我们的设计一个登录服务平台，大体需要提供发送验证码，注册，登录，登出，身份/权限验证 等服务。
开始总是分分钟都妙不可言，我们设计的平台总能非常好地满足业务的诉求，对于一些需要扩展平台能力的地方，也响应得比较及时。但是，慢慢的，事情好像出了一些变化。在平台的发展过程中，业务方越来越多，需求也越来越复杂。
A业务系统想指定特定的校验码平台，而这个校验码模式我们是没有对接过的。平台开发人员和业务只好扑腾扑腾派两个人去对接。B业务系统来了，说想在登录失败N次后，给用户发送短信提醒，发送邮件提醒，平台开发人员和业务只好扑腾扑腾派两个人去接这些需求。C业务也来了。D业务也来了。慢慢的，这个所谓的平台，已经没有任何人在做平台了。
本来我们设计拆分前台与后台，是为了让前台来满足用户需求的快速迭代，期望后台趋于稳定。当我们平台开发人员并不能确保我们能搞清楚业务人员的需求是产品经理拍脑袋，还是实际需求时，大量频繁地平台开发，甚至规则变更。无论对平台的稳定性和业务团队来说，都是灾难性的。很爆炸。
那怎么解呢?中台就能解?怎么解?
为了解决这样的问题，我们把上述登录服务抽象成一个标准的 模板流程：
输入账密 -> 验证码校验(默认为平台实现，可在平台选择或下载SDK扩展)-> 账密校验 -> 账密校验后身份校验(默认为平台实现，可在平台选择或者下载SDK扩展)-> 登录失败次数后续动作扩展(下载SDK，每次登录都会调用该用户自定义扩展)。
三个扩展点，验证码校验，身份校验，登录失败后续动作。这三个动作，平台可以提供几种默认的实现，也支持业务系统自定义。当业务系统有相应的需求时，可以自行开发，生成SDK，嵌入到平台运行时上，根据请求内容指定执行扩展动作。这样就确保了服务的稳定，释放了服务团队的压力。
我们再把场景回到A系统，他不是想要一个自己的验证码吗?行，丢一份文档，让A系统团队自行进行实现验证码校验的扩展，然后再以插件的形式部署到中台上。
我们继续场景回到B系统，他不是想要登录失败3次后发送短信通知吗。行，丢一份文档，让A系统团队自行进行实现登录失败后续动作的扩展，然后再以插件的形式部署到中台上。
看看，就这简单的 模板流程+扩展点 的实现，把中台的开发人员从繁杂的业务系统里解救出来了。如果某个扩展点的实现，使用方非常多使用频率非常高，那么这个扩展点实现可以直接作为平台的默认扩展选项出现。
怎么理解这个扩展呢?假设我们是一个厨房，我这里有桂皮，八角，糖。然后某一天我要卤蛋，我要怎么做呢?我要调料，按配方慢慢称出桂皮1小块，八角3个，糖5克。然后第二天，我又要重新一个一个配调料。而且还有三十个小伙伴也想自己开卤蛋摊。我就把之前那个配方，直接卤成一大桶酱汁，命名为卤蛋1号酱汁。然后过两天，一个高人告诉我，糖再加2g，颜色可以更深一点，但是只用一次，所以我没对这个配方进行命名。又过了两天，大家都更喜欢这个高人的配方，说特别好吃，所以三十个小伙伴都找这个配方，我作为中台当然察觉到这种趋势，我就把这个配方命令为卤蛋2号酱汁，并直接把这一大桶2号酱汁打包出售，这样卤蛋摊主又可以继续开箱即用了。
你看，效率多高?不需要每个卤蛋摊主都会调酱汁，而且一旦卤蛋摊主有自己的配方，也可以非常方便地把之前的配方改一下。
是否有众多好的标准流程模板，是衡量一个模板+扩展点是不是一个业务中台的标准。
说了这么多是否需要搭建中台呢?从例子中我们可以了解到，1、中台需要将实际的业务或技术沉淀抽象，想做好就需要有扎实的业务技术抽象能力。2、当产品条线很多，业务扩展需求很多时，搭建中台才更有价值，而产品条线少，业务扩展需求少时，中台并不经济。
