中台亡了，问题到底出在哪里？( 二 ) _中台

提高资源利用率，这也是必然的，服务、数据、组件等形成统一复用，各资源也不再分散，只需通过一套服务来做支撑，并且可以通过各业务线的忙闲情况，做资源的调控、比如某个业务线使用交易中台服务，高峰时期是在早上8点到晚上12点，凌晨以后基本没有业务量，则可以考虑把针对这个业务线的资源配置降低，从而实现降本增效。

提高系统稳定性和可靠性

一般来说系统的故障由三个方面引起，系统 bug、变更配置、并发流量变化。而技术中台避免了各个部门为解决自身技术问题而随意修改系统设置和配置的情况，这样做有助于防止整个系统因为随意修改而出现不稳定和安全问题。
二、拆分中台并非全盘否定中台
前面我主要介绍了中台能解决哪些问题，但其实很多企业在实际引入中台的过程中，也遇到了很多问题：

中台与前台的边界模糊

很多前台的业务让中台接管开发，到底是接还是不接？中台的角色和范围缺乏明确界定，导致中台与业务之间的责任划分模糊不清，引发了重复建设、资源浪费和沟通成本等问题。

稳定性与灵活性的冲突

稳定与灵活一直是个矛盾体，中台接入的业务线非常多，一旦出问题影响面巨大，代码质量如何把控、上线流程如何稳定、业务如何做好隔离，都需要考虑清楚。

沟通障碍与目标差异

协调中台团队和业务团队之间的沟通和合作，平衡双方的需求和利益，以及处理中台和业务之间的依赖和变更，都是一项复杂的管理任务。

中台规划与业务需求之间的平衡

中台的服务需求和响应之间存在不匹配，这导致中台无法满足业务的多样化和个性化需求。有时中台过度迎合业务的短期需求，却牺牲了其长期规划和可持续发展。

利益分配

距离业务近的地方，比距离业务远的地方更能得到公司增长的成果，中台看似业务，其实只是沉淀，追求的是稳定和灵活。还有业务下沉的时候，会涉及到与中台的业务交接，前台业务必定会减少。如果是部门划到中台，是否会有人员变动？当中台的服务价值和收益缺乏清晰界定，将难以有效衡量自身的贡献和影响。
综上，中台看似很美好，但很多企业在实际落地的时候却因为遇到这些问题，导致陷入困境，中台建设越建越复杂，甚至有些企业对中台也逐渐失去了信心，反而成了阻碍企业发展的瓶颈。
近两年业界开始风行“拆中台”策略——将中台变“薄”，拆分到多个独立的业务单元。这使得很多企业又开始认为中台已成明日黄花，引进中台并不是一个好选择，甚至有些企业将自身发展不顺的原因也归在了中台上面，一时间中台被全盘否定了。
我个人则认为拆分中台并非全盘否定中台，而是基于自身发展阶段和市场环境的变化进行战略调整和优化。“天下大事，合久必分，分久必合”，这就意味着在中台的管理和战略中，必须根据具体情况来做出分合的决策。有时候，将中台进行分散管理或者分解成更小的部分可能更为合适，因为这样有助于更好地满足各个业务单位的需求，提高灵活性和适应性。互联网大厂们将庞大而僵化的共享中台重新组织为灵活的业务域中台，可以更好适应具体业务场景和用户需求，既能保留中台提供通用能力和协同效率的优势，又能增加中台的灵活性和个性化。
三、企业应该因地制宜选择是否需要中台
首先，我想强调的是，“中台”本身并不是一个新的架构思想，这个架构思想早在若干年以前就已经有了，很多企业已经是这么做了，就像面向对象编程语言中（JAVA）高内聚，低耦合，便是这种思想。
当企业处在初创期，随着业务发展产生多条业务线或产品线的时候，就会面临协同方面的挑战，如果每条业务线都要自己成立技术、运维、数据等部门，这样显然是非常浪费人力和资源的。为了适应快速发展的业务，就需要成立中台部门，来抽取、复用共性的东西，形成统一，这样既能满足“小前台，大中台”策略，让业务快跑抢占市场，中台提供稳定的炮火支援，又能提高协同和研发效率。参考示意图如下：

文章插图
当企业已经渡过初创期，发展已经具有较大规模时，各条业务线人员和业务场景也比初创时更加庞大和复杂，企业了将面临更加多样化的市场，以及强大的响应能力，甚至每条业务线都要独立去创新，这样统一的中台部门就会变成瓶颈，人员、响应时间、需求变化和沟通等都会成为阻碍多样化需求的绊脚石。这时候企业就需要根据市场需要，将庞大而僵化的大共享中台，拆分到各业务单元中，将中台下沉到各业务单元中，这样既能保留中台的通用和协同能力，又能针对具体业务和场景不断增加灵活性和定制性。参考示意图如下：