系统一定要做成中台吗？

结论是：肯定没有必要。

但是我们可以借鉴中台的思路去谈系统的设计与演进。

系统的演进本质是对于业务在技术上的映射，所以合适很重要。我之前的文章也多次提到过一个系统大致的业务演进脉络，以及所映射的技术实现方式。

• 早期为追求快，all in one可能是很好的选择。
• 业务发展快了，基于DDD或SOA的服务划分与团队组织可能是最有交付效率的方式。
• 随着业务规模的爆发增长，我们需要过渡到服务化、分布式阶段，做开发一些独立的服务沉淀通用能力，比如中间件去做分布式的一些通用实现。
• 发展到后期业务规模庞大且相对稳定，这个阶段需要投入到技术方向的工作是不同业务的打通问题。

很多时候我们做一件事情的出发点往往决定了最终的走向和结果。所以如果考虑的是能力复用的需求，那么中台更适合沉淀已有的能力，对于全新业务如果和之前沉淀的业务关联不大，中台支持并不好。

还有就是中台团队对于前台业务支持的资源有限，中台团队和前台团队有不同的KPI，比如前台业务是快速交付业务的，如果老板不能很好的做好前台业务的快速迭代，而想过分依赖于中台团队资源支持往往不太现实。

上面提了几点打造中台或使用中台过程中的一些感受，但是对于中台肯定不是完全否定的。中台体现了很强的技术属性（抽象、沉淀、复用、打通），某种程度上说是将这些技术属性进一步延伸到业务上，当业务体量达到一定规模后就会实现利大于弊。

如果说技术属性沉淀的是技术组件，那么中台沉淀的是业务组件。但是我们需要意识到企业数字化需求是千差万别的，难以一招鲜吃遍天。能不能做出技术中台很大程度上受限于业务形态、业务发展阶段的影响。如果业务阶段和业务规模没有发展到这个阶段，大张旗鼓搞中台ROI其实可能非常低。

那么中台对于系统演进是否有借鉴意义呢？

意义肯定是有的，比如我们对系统的演进转移到关注于抽象和共性的沉淀，尽可能保持系统灵活多支撑相似的业务形态。

所以如果想要搞中台可以先从一个系统入手，不要直接想着把所有的中台都往系统里面放，如果一个中台系统又大、又厚、响应又慢，其实没什么存在的价值。

如果你的系统实现了对于多品类业务的灵活支持，叫不叫中台有什么关系呢？