从阿里提出的拆中台，聊聊中台战略是否过时？

　　最近一段时间有个热点经常被大家转发，就是阿里拆中台。起因是阿里张勇在内网发文谈到中台太厚，反而影响到了阿里业务发展和敏捷响应能力。从15年张勇提出大中台，小前台战略，到今天又自我否定提出了拆中台，那么是否真正中台战略思想已经过时？如何理解拆中台这个概念？
　　对于这里的拆实际应该从两个方面理解。
　　其一是分拆，即原来的中台太大了需要进行分拆，从谈到最多的业务中台和数据中台，包括业务中台能力也进一步分拆为独立的中台，比如人力服务中台，供应链中台，知识和搜索中台。而对于数据中台独立分拆AI中台等。
　　这个实际和我前面谈到的中台构建中本身即微服务化思路是一致的。中台能力本身就是多个微服务中心或能力中心去支撑的，而不可能说构建在一个大系统里面。
　　既然原来已经微服务拆分，那么为何还存在分拆的概念？
　　简单来说就是中台大了后，不同业务域的中台服务能力本身，在向前台提供服务能力支撑，服务运营的时候是存在差异化的，包括后期的服务治理。因此你会看到不同类型的中台，中台业务团队，运营团队，服务团队都需要进一步进行拆分，才能够更好的满足前台应用需求。
　　其二是抛弃中台，这里主要是指进行全新业务域IT能力建设的时候，一开始往往并不是以中台+服务+应用的思路去规划。而仍然是传统纵向模式，这和网上谈到的中台基因更多是应对组合式创新，而不是颠覆式创新类似。
　　这里可以参考网上的一段论述如下：
　　为什么这么说呢？因为，组合式创新，是把现有几个能力进行组合，形成新的能力，它强调能力的标准化，这个恰恰是中台所擅长的。以＂盒马鲜生＂为例，它复用了中台的商品、库存、用户、支付、AI、安全等多个服务能力，经过重新组合，形成了＂零售新物种＂。但是，颠覆式创新，是从根上做创新，它要打烂前台、中台、后台，颠覆现有模式和能力。比如智能制造颠覆传统制造、智能手机颠覆传统手机，你没法在现有生产线上去创造，只有打破原有模式。所以，中台不支持颠覆式创新，这是中台的基因所决定的。
　　再简单来说，拿腾讯来说，腾讯可能已经构建了自己的游戏中台能力，但是自己又有为微众银行，那么微众银行要借鉴和使用游戏中台能力显然是不可能。
　　那么微众银行在业务和IT构建的时候是否就一定按中台思路构建呢？
　　一般来说往往并不会，即当面对一个新的业务领域和颠覆式创新场景的时候，实际上你并不清楚你应该有哪些可复用能力沉淀到中台，因此自然也谈不上按中台+服务+前台应用思路来构建IT。
　　这也是我原来强调过的一个关键点，即：
　　中台是企业信息化建设中逐步演进和演变出来的，而不是规划出来的。中台是否过时？
　　当接触到中台和微服务概念的时候，我们经常就听到的是SOA思想过时，组件化思想过时。而实际上你可以看到中台和微服务正是原来SOA架构思想，组件化思想的演进和发展。
　　中台这个词炒作的太多，可能大家都不再愿意提中台概念。但是SOA架构思想，微服务思想不存在过时的说法。可能以后还会冒出新词汇，但是这些思想本身都是一样的。
　　传统企业信息化和互联网信息化基因是不同的。
　　在前面我就谈到互联网企业信息化和传统企业信息化很多规划思路，系统建设思路，业务系统的复杂度，面对的用户受众各个方面都有差别。
　　如果简单的照搬互联网构建中台的思路来建设企业内中台，基本都是死路。
　　大部分企业更多的应该是基于当前遗留IT架构和IT系统能力，采用逐步演进的思路来构建自己的中台。这个中台也不一定一开始就要微服务化，要独立构建。而是以能够提供共享服务能力给上层应用使用为核心指导原则。
　　中台核心是共性业务能力的抽象下沉，并统一对外提供。
　　很多企业没有大张旗鼓的去规划构建中台，但是经过多年建设形成了自己的服务共享平台和服务资产库，这个服务资产有效的支撑了新的业务应用的开发，那么这个服务共享平台就是对企业有价值的中台。
　　这个服务共享平台可能仍然大量适配和接入了遗留IT系统的可复用能力，而不是全新构建新能力，但是这恰好是企业中台构建和平滑演进中的最佳方式。
　　简单来说很多企业连服务共享平台都做不好，如何有能力做好中台？我们实施了大量的SOA和ESB服务总线项目，大量的企业仍然将ESB作为一个接口集成平台在使用，在这种管控治理水平下，实际上是很难去规划建设中台的。传统企业什么时候需要构建中台？
　　大家可以看下，除了互联网企业外，中台规划建设实践最多的是哪些企业？
　　简单来说主要包括了金融服务，电信行业，快消品行业等。这些企业中台实践的多最大的原因就是本身的商业模式变化，互联网转型需求，即在直接面对C端消费者的时候，需要能够更加敏捷的为客户提供各种服务能力，能够快速的衍生新的商业或服务模式。
　　而对于其它大部分传统企业来说，实际上并没有这种需求。比如很多下游的制造类企业，往往并不直接面对C端客户。这类企业的信息化和IT系统建设，更多的是为了满足内部业务高效运作，满足内部员工的使用需求。
　　基于这类企业信息化建设的供应链，财务，ERP等业务系统，绝对是很少出现类似互联网企业应用一样天天都在变更，都在发布版本，随时都在衍生新的APP应用等场景。
　　简单来讲：对于本身就是做C端消费类产品的企业，本身又希望实现对终端用户的端到端触达能力，同时营销价值链本身又是完全自建的情况。这种企业往往对中台建设的需求最强烈。
　　我们也看到当前很多上中台的企业更多就是属于上面场景的企业，而且中台的构建更多的是面向自己的电商平台，CRM营销网络，面向C端的前台应用需求。
　　在这种情况下，企业需要去构建一个中台来满足前台应用敏捷化的需求。
　　也就是说这个企业中台已经不再是简单的满足内部业务系统，内部用户的使用，而是更多的打破了企业边界，面向外部的消费者用户，或者产业链上的生态合作伙伴的需求。
　　在这种场景下，我们就需要对企业内部已有的业务能力进一步包装和抽取共性，然后将共性能力以API接口服务的方式提供给前台应用。
　　其次，就是一个大的集团性企业，本身在进行业务重组，将共性业务能力形成共享中心的方式进行统一的情况下，需要去构建一个中台。这个也和我们中台产生背景思路一致。
　　比如前面谈到的，一个生产制造企业，本身有很多子公司或工厂，但是你可以看到企业的供应链能力，营销服务能力，售后服务能力完全是可以共享和复用的，这些业务能力应该进行整合和统一。真正差异化的仅仅是制造各类产品不同的制造单元。
　　在这种明确的业务驱动和业务整合背景下，往往也是最佳的构建中台场景。
　　其次，对于中台适用场景网上一个说法也可参考：
　　https://www.sohu.com/a/440065246_355140
　　如上的四象限图。这四个象限的横轴代表技术演化稳定性，竖轴代表功能的通用性。中台的优势领域在第三象限，这个象限技术具有高确定性，业务功能通用。第二象限属于比较稳定但是不通用的小众行业。第四象限属于普遍流行但是高速变化的领域，比如说内容和服饰或者端上的交互。而第一象限属于创新业务，不但定制化程度高且快速演化，比如说面向垂直行业或者初创技术。
　　也就是说： 中台的使用范围是有限的，仅仅限于技术演化相对慢且功能通用性高的场景中。这是我们得出的第一个结论。
　　过往中台的失败案例也往往集中在把中台强推到创新业务中的情况。中台为何笨重？
　　在这里我还是想展开谈下中台为何会越来越笨重。假设一个企业的中台已经是按照微服务架构思想拆分为了多个能力中心进行构建，比如订单中心，商品中心，支付中心等。在这种构建模式下各个中心都可以对应到独立的开发团队进行独立自治的设计，开发，实现和能力交付工作。
　　新需求响应难度增加
　　当在构建一个新的前台应用的时候，如果当前中台提供的API接口服务能力有现成可用的，那么通过快速复用自然是可以加快前端应用构建速度。
　　但是如果前台需要支付中心提供一个能力接口，这个接口原来支付中心并没有。
　　在这种场景下支付中心就需要全新去实现一个接口，并将接口暴露给前台使用。在规划设计这个接口的时候，整个过程实际是变复杂了。
　　即支付中心在实现这个接口的时候，还需要分析和考虑如何将接口做到通用化和标准化，后续还可能存在哪些业务场景同样需要使用类似的API接口。即接口虽然是前台A应用提出的需求，但是中台去设计实现的时候必须考虑通用性，可复用度，接口治理管控多方面的内容。这些都考虑清楚了才能够去实现。
　　其次，如果是由前台自己去实现这个接口，那么这属于前台模块内部的接口集成，相对来说更加容易进行集成和联调测试。但是接口转到由中台提供的时候，这个原来内部的集成变成了跨团队，跨应用的外部集成，整个集成度本身也提高。
　　因此当需要中台新增能力的时候，实际对业务响应的敏捷度是下降的。
　　但是好处就是，如果后续还有新应用也需要这个可复用能力，那么敏捷度就能提升。
　　当我们在谈中台敏捷性的时候，往往都在说中台能力已经足够完整，前台应用构建需要的东西都能够从中台找到。但是却忽视了存在新的需求需要不断下沉到中台的场景。如果这个场景存在，那么敏捷度是降低的。
　　但是如果后续新可复用能力不沉淀，那么中台本身就失去了价值和活性。
　　企业一开始规划建设的中台很好，但是运行一段时间你会发现又出现大量可复用能力没有下沉到中台，仍然是在前台来实现。本来希望前台越做越薄，但是实际情况往往是前台应用越来越厚。前台对中台依赖逐渐变小，那么中台本身价值也逐步丧失。
　　集成复杂度增加
　　在传统的业务系统和应用开发中，往往所有业务功能和逻辑都在自己内部实现，虽然存在重复，但是好处就是完全属于内部可控，协同和集成难度也小。
　　但是当采用中台分层架构思路后，一个前台应用往往会依赖多个中台能力提供中心的能力，一个前台应用要跑通设计到多个接口集成和联调，需要协同多个研发团队，出现了问题后又需要等待中台研发团队变更和修复。
　　即虽然用现成可复用接口服务提升了效率，但大量的接口集成或变更依赖往往降低效率。
　　本来自己一个项目组能搞定的事情，发现中台化后需要协同和依赖3个项目组，整体交付进度和质量反而完全不受自己控制。
　　再举个例子：一个本身很小的业务系统设计开发，实施了微服务架构和前后端分离，后端人员不会前端技术，前端人员本身不care业务，导致一个简单系统实现都要多人协同和集成才完成，而且质量难以稳定。对于这类小业务系统开发，个人是强烈反对微服务化和前后端分离。
　　可复用带来实现复杂度增加
　　共性业务能力下沉实际包括两个方面。其一是完全相同的接口服务能力，其二是需要进行业务需求差异后抽象和参数化，在抽象化后才能够提取共性的服务能力。
　　当中台能力构建出现第二种情况的时候，你会发现中台能力的设计和实现复杂度一定增加，正如我们在软件开发时候，如果数据库只支持mysql，跟需要支持多数据库，在实现复杂度上完全是两个层面。多数据库支持不仅仅提升了实现复杂度，同时还降低了接口服务能力的性能。
　　同时当后续中台某个接口服务能力进行变更的时候，同样出现大量前台应用依赖，一变动往往上层应用也要配套变更的情况。如果不变动，再新增加新的服务能力接口，那么后续中台提供过的接口服务本身的版本管理，服务本身的生命周期管控又出现问题。
　　当一个企业原来IT建设以及相对完善，但是企业战略调整需要逐步对外上下游协同，或者直接触达C端客户的时候，这个时候构建中台相对容易。即基于已有的IT系统建设经验，已经足够提取出一套稳定的中台能力服务层，同时这些能力接口相对稳定。
　　但是一开始你按中台思路去构建，没有足够的业务沉淀和业务场景覆盖，那么后续中台就出现大量的能力新增和变更，这种不稳定的中台对前台构建往往才是大灾难。
　　中台服务治理管控能力跟不上
　　中台建设完成后，API接口服务能力提供给上层使用，这些API接口如何使用，应该遵循什么样的规范流程，如何进行接口订购消费，如何监控接口运行，接口变更时候如何处理？
　　这些都是很现实的服务治理管控问题。
　　这些治理规范和管控流程没有跟上，那么中台能力的使用就处于一种混乱和不可控的状态，中台提供能力被前台大量随意使用不仅仅是数据安全的问题，更大的问题是前台和中台之间耦合性逐渐增强，任何变更牵一发而动全身。
　　我们希望引入中台和服务去实现解耦，但是发现接口乱使用反而更加耦合。中台首先是一个业务概念
　　在谈中台的时候我始终强调中台是一个业务概念，首先要做的是共性业务能力整合。
　　这个实际在中台概念出来前，很多企业就在做这个事，比如构建的统一财务共享中心，人力资源中心，供应链采购中心，售后服务中心等。也就是说在中台能力没有出路前，很多大企业已经在构建自己面向不同业务域的共享服务中心，实现共性业务能力的整合。
　　共性业务能力整合后，自然就有配套的中台IT能力中心实现，这个过程本身是很顺的。是业务推动了IT，而不是IT去构建中台中心反向推动业务变化。
　　中台首先是一个业务概念，其次才是为之配套的IT技术实现。
　　中台本身就是需要很好的衔接业务和IT，才能够真正规划和建设成功。如果业务组织和团队本身没有变化，业务构建方式没有变化，仅仅是期望IT系统中台化后来支撑业务，显然是不现实的。这也是很多企业最终中台建设失败的一个关键原因。
　　中台价值始终体现在对业务的敏捷和快速响应能力上，如果这个关键的KPI指标都没有达到，就脱离了中台建设的初衷。
　　包括现在的中台建设和IT解决方案厂商也是同样道理，能够提供技术解决方案的很多，而真正垂直在一个业务领域，能够提供完整的业务梳理，中台规划的少之又少。这也是导致最终的中台类系统无法匹配业务目标实现的一个关键原因。
　　中台思想本身没有错，关键点还是在于业务如何变革，业务和IT如何协同去推动中台规划和建设。如果这个没有想清楚，完全没有上中台的必要。业务和中台去中心化
　　在大中台小前台整体思路下，可以看到中台越做越厚，能力越来越强，前台逐渐变成仅仅是中台能力的组装和编排。正如前面我谈到的，一个前台应用的完成就必然会依赖大量的中台能力中心提供的服务接口，这种依赖越多，那么前台的自治能力越弱。
　　其次，前台依赖中台，很多前台之间的应用协同交互则需要通过中台中转才能够完成，这本身也是加长了业务和数据流的流转链条。
　　在微服务架构里面经常会强调去中心化，去中心化架构下强调尽量不要去引入一个大的集成点，这个集成点可以是类似ESB总线这种集成平台，也可能是共性依赖的中台能力层。
　　前面拆中台，里面有个重点就是中台本身拆分小，每个中台能力中心都独立自治，也不需要再通过能力开放平台进行能力聚合和开放。
　　前台应用和中台能力之间应该逐步形成一种去中心化的架构，前台节点和中台节点之间可以去中心化交互，同时前台和前台间，中台和中台间同样也可以去中心化集成和交互。在这种模式下往往更加容易扩展单个节点能力，同时降低对整体中台层的依赖。
　　对于拆中台，我们完全可以参考类似ServiceMesh服务网格思路，对于企业的业务能力组件化后也形成业务能力网格交互，彻底的将业务去中心化，管控流和业务数据流分离。因此，拆中台并不是说中台没有了，而是中台这个很厚的共性订座不再存在，中台能力变成了一个个可以独立提供服务接口的能力单元，并去中心化协同。