中台都在忽悠吗？都被忽悠瘸了？我们都在悄悄淘汰中台，你们还在建？最近网上充斥大量文章和观点，都在说中台过时。为什么会这样说？是因为成本与复杂性？技术限制与业务变化？还是因为组织变化？为什么会这样呢？且听我一一分析。

众所周知，中台是指企业内部的中间层平台，负责连接上下游系统，提供数据和功能服务。而在过去几年中台概念曾经风靡一时，甚至被认为是企业数字化转型的关键。然而，近年来，一些企业确实出现了对中台战略的重新评估，不再像之前那样盲目地追求中台建设。

其实，中台的概念兴起于企业数字化转型的浪潮中，企业开始意识到传统的前台系统（如客户端应用）与后台系统（如企业资源规划系统）之间的断层，而中台则被认为是弥合这种断层的理想方式。

值得一提的是，关于中台的定义，业内大佬也曾经发表过一些观点：

提炼各个业务条线的共性需求，并将这些打造成组件化的资源/能力包，然后以接口的形式提供给前台各业务部门使用，这样就可以最大限度地避免“重复造轮子”的问题，也让每一个新的前台业务创新能够真正意义上“站在巨人的肩膀上”，而不用每次开辟一个新业务都像新建一家创业公司那么艰难，甚或更为艰难。

——某企业资深架构师 钟华

总结而言，中台的核心点主要有以下三个：

2015年，业界首次提出“大中台、小前台”战略，是想打造统一技术架构、产品支撑体系、数据共享平台、安全体系等等，把整个组织“横”过来，支撑多种多样的业务形态。中台似乎已经成为行业标配，稍有规模的公司都建设了自己的中台，掀起了一股强劲的中台风。

中台能够解决哪些问题呢？在我看来，主要有以下四种：

中台提供了一种在企业内部建立统一的技术平台或者服务平台的模式。这个平台可以被不同部门或者项目共享和复用，从而减少了重复开发的情况。随着新业务的不断接入，共享服务也从仅能提供单一的业务功能，不断的自我进化成更健壮更强大的服务，不断适应各种业务线的新需求。同时在数据积累方面，通过数据中台将各业务的数据都沉淀下来，不断地积累数据，发挥数据的最大威力。

很多企业开发响应慢，其实大部分都是因为数据问题，没有做到实时、准确和统一。比如一家公司的订单，分为 C 端订单，B 端订单，共享单车订单等等，这些订单分管在不同部门中，想要做订单统计、预测等就比较困难，各类型订单彼此割裂，而如果企业只有一个订单中心的话，数据就能够在不同场景下感知到业务的变化和联动。

说起如何提高资源利用率和研发效率，我总结为中台建设五步法：插件化、服务化、配置化、异步化和数据化。这五步环环相扣，其中插件化就是提高研发效率的关键点，我们将对核心交易流程进行抽象建模设计，并通过流程引擎的改造，实现增加多个插件和扩展点。这样，不同的业务场景可以根据需求自定义其个性化逻辑，将整个交易环节抽象为一个流程框架，并在其基础上引入一系列业务扩展。这种设计使得各业务间互不干扰，更灵活地满足各自需求。

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

一般来说系统的故障由三个方面引起，系统 bug、变更配置、并发流量变化。而技术中台避免了各个部门为解决自身技术问题而随意修改系统设置和配置的情况，这样做有助于防止整个系统因为随意修改而出现不稳定和安全问题。 

前面我主要介绍了中台能解决哪些问题，但其实很多企业在实际引入中台的过程中，也遇到了很多问题：

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

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

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

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

距离业务近的地方，比距离业务远的地方更能得到公司增长的成果，中台看似业务，其实只是沉淀，追求的是稳定和灵活。还有业务下沉的时候，会涉及到与中台的业务交接，前台业务必定会减少。如果是部门划到中台，是否会有人员变动？当中台的服务价值和收益缺乏清晰界定，将难以有效衡量自身的贡献和影响。

综上，中台看似很美好，但很多企业在实际落地的时候却因为遇到这些问题，导致陷入困境，中台建设越建越复杂，甚至有些企业对中台也逐渐失去了信心，反而成了阻碍企业发展的瓶颈。

近两年业界开始风行“拆中台”策略——将中台变“薄”，拆分到多个独立的业务单元。这使得很多企业又开始认为中台已成明日黄花，引进中台并不是一个好选择，甚至有些企业将自身发展不顺的原因也归在了中台上面，一时间中台被全盘否定了。

我个人则认为拆分中台并非全盘否定中台，而是基于自身发展阶段和市场环境的变化进行战略调整和优化。“天下大事，合久必分，分久必合”，这就意味着在中台的管理和战略中，必须根据具体情况来做出分合的决策。有时候，将中台进行分散管理或者分解成更小的部分可能更为合适，因为这样有助于更好地满足各个业务单位的需求，提高灵活性和适应性。互联网大厂们将庞大而僵化的共享中台重新组织为灵活的业务域中台，可以更好适应具体业务场景和用户需求，既能保留中台提供通用能力和协同效率的优势，又能增加中台的灵活性和个性化。

首先，我想强调的是，“中台”本身并不是一个新的架构思想，这个架构思想早在若干年以前就已经有了，很多企业已经是这么做了，就像面向对象编程语言中（Java）高内聚，低耦合，便是这种思想。

当企业处在初创期，随着业务发展产生多条业务线或产品线的时候，就会面临协同方面的挑战，如果每条业务线都要自己成立技术、运维、数据等部门，这样显然是非常浪费人力和资源的。为了适应快速发展的业务，就需要成立中台部门，来抽取、复用共性的东西，形成统一，这样既能满足“小前台，大中台”策略，让业务快跑抢占市场，中台提供稳定的炮火支援，又能提高协同和研发效率。参考示意图如下：

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

总而言之，中台不是一直不变的，它需要根据市场需求不断进化，演变成能够满足当前企业市场需要的形态。中台不是万能的，它只是企业数字化转型的一种重要实现路径，我们不能对中台有过高的期望，而是应该理性地回归到企业数字化转型的价值上来。