中台能解决一些问题，但是中台能解决一切问题吗?很显然不可能，中台也只在小范围内适用前面一直在说中台是为了解决效率问题，但是效率提升还离不开一个因素:成本对互联网业务来说，仅从开发效率角度来看，当规模还没大到一定程度时，可以简单地通过增加投人提升开发效率。比如滴滴，从最早的出租车业务到专车、快车、代驾租车和顺风车，每个业务线系统基本都独立，尽管这些业务的重合度非常高，但是为了能快速开发，把它们分开反而效率会更高。
不过，随着业务越来越庞大，复杂度越来越高，再这样发展下去，不论从成本(浪费会比较大)还是技术(不利于技术沉淀)来看，都是不利的、因此在这样的场景下非常适合使用中台。那么中台适合什么场景呢?最典型的场景就是公司多个业务线业务场景相似、在技术实现上非常类似，像电商和出行这类业务。
那么，即使是在非常适合使用中台的场景下、是否一用上中台就一切都万事大吉了呢?很显然也不是。就拿前面提到的交易场景来说，我们对交易场景做了很多的抽象，进而根据抽象的结果建模，试图在一定的确定场景下灵活化处理，使建模后的结果更灵活，但是建模的前提仍然是针对特定场景的，所以这种场景的使用仍然会受限。
例如当前在第一版交易系统重构后，O20模式出现了，此前重构的模式就很难在原有的交易模型上良好运转了。
总结
一般一个业务系统会经历单系统、分布式系统、产品化、平台化以及最终中台化的发展历程。不同阶段的区别如下。
(1)单系统，就是单个系统，业务形态比较单一，所有业务逻辑在一个系统中实现、对应的开发协作一般在10个人左右。这种结构一般是在业务发展初期为了应对快速开发产生的，不用太多考虑稳定性和扩展性，唯一的刚性要求就是快速实现需求。
(2)分布式系统，当开发人员达到100人左右时，就必须拆分系统了，按照业务单元进行角色划分，要考虑好稳定性和扩展性，因为此时别人可能会依赖你的服务。
(3)产品化，就是更多地把系统当成一个产品来提供。当客户使用产品时要考虑他的学习成本、要考虑是否能够定制客户的需求、对用户的问题反馈是否能及时响应(售后服务)以及产品是否稳定可靠…这些都需要由产品的提供者来保障，也就是要尽量保证产品的标准化、规范化和可靠性。
(4)平台化，就是在产品化基础上，你不仅希望更多的人使用你的产品，而且还愿意邀请客户、合作伙伴一起建设和完善系统，给他们提供一整套的服务；你也不仅仅满足固定的需求，还会主动替客户着想，挖掘他的潜在需求。平台化比较适合团队
(5)中台。其实我们大部分的业务场景中只要做到业务的平台化就很好了，在业务边界比较清晰的情况下，只要把基础的业务平台建设好，就可以非常快速地组装新业务系统。但是当团队达到上万人规模时，信息获取成本高、互联互通成本高、服务能力不确定……这会带来非常高的协调成本，当协调成本达到一定程度时就不会再有协同了一每个系统都会倾向于自己实现需求而不是依赖别人一这就会导致每个业务要形成自己的闭环并产生很多的重复建设，成为恶性循环。中台就是用来打破恶性循环，建立便于协同的业务标准和机制的。