近年，中台这个概念不断地在行业中得到宣传和应用，也在我朋友圈中被争论和口诛笔伐，今年，中台的原创者阿里宣布放弃中台，引发了对中台新一轮的热议。我理解中台的概率应该是企业架构中的一个方案，但由于概念并没有被清晰的定义，不断的被套用甚至乱用，导致争议不断。

当前市场上的中台概念中，有软件中台、数据中台、应用中台、业务中台、组织中台等，总之很多维度上的结构都可以用中台来包装。梳理了一下，目前业界关于“中台”的概念很混乱，在不同的语境下，有各自的含义，简单分类一下：

​ 系统的中台：应用系统的三层技术架构分为前端展示层、中间应用逻辑层、后端数据层，很多沟通场景的中台是指这个中间应用逻辑层。

​ 云架构的中台：云技术架构分为SaaS、PaaS、DaaS、IaaS层，谈及云的中台，往往指PaaS、DaaS层。

​ 应用的中台：应用功能抽象出来后封装的典型应用，如报表、工单、支付、发票、凭证等封装好的应用服务，可以组合形成应用功能，这是类似典型的SOA服务。

​ 数据的中台，也有把数据后面的主数据、数据模型算法等隐藏在呈现数据背后的数据叫数据中台。

​ 业务的中台，把业务活动进行高度抽象后，形成业务背后的基本的、共性的业务活动，特别是在互联网架构中，如新零售的IT面前，统一会员、统一营销、统一订单、统一库存、统一支付、统一信用。

​ 组织的中台，有别于直接面对客户和市场的前端面团队，将前端团队需要的共性资源、能力集中起来，为前端团队提供更专业、更集中有效的支撑，有一些业务共享中心组织的意思，例如阿里的共享业务事业部。

“中台”这个概念来自互联网公司，应该最初来自阿里的电商平台，在阿里钟华的书中，阐述了阿里巴巴中台的来源及其架构演变，并分享了中台架构产生的共享服务中心的技术和发展应用。总的来看，阿里的中台是从SOA理念中逐步衍生出来的，是一个从应用中台到业务中台到组织中台的过程，本质上是从SOA理念中在应用架构中的体现，将需要重用的业务功能封装为服务，以期被重用，避免架构复杂和重复功能建设。

我的观点是：首先应用中台不是新概念，其次应用中台是理想的好架构，第三，关键是实现的代价巨大，非互联网的传统企业是否有必要，必须慎重深思。

１、中台的概念本质上就是SOA的思想，将可以重用的业务功能封装为服务，以期被重用，避免架构复杂和重复功能建设。这是一个应用中台的概念。

２、应用中台在服务提炼中，其实是对业务进行抽象，将同类的业务划分到一个层级上进行分类、按照一定颗粒度进行定义，形成业务中台的概念。

３、既然业务中台有了，本着“前面是突击队、后面炮火群支援”现代战争理念，把业务中台这些共用的业务团队放在一起，就是组织中台的概念。

无论是应用中台、业务中台还是组织中台，本质是SOA和企业共享中心的理念，并不是一个全新的概念，应用中台和业务中台其实在十五年前或更早的金融核心业务系统中都已经作为了标配。我在2008年参与国家电网公司中国电力财务公司核心系统建设咨询中，与电财公司CIO侯文捷先生共同研究并撰写的论文《金融行业应用系统体系架构对电力企业的启示》（获得中国电机工程学会电力信息化专委会2008电力行业信息化年会优秀论文），也曾经提出基于业务服务的应用系统架构，将电网企业的核心业务抽象出来，建立 “核心业务管理系统”和“核心业务处理系统”，从而消除“烟囱式”信息孤岛，其实就是应用中台思路。

那么，应该考虑的是，应用中台、业务中台和组织中台，是否可以运用到传统的企业信息化乃至管理中？或传统大型央企在借鉴“大中台、小前台”的应用架构和业务架构中，应该注意什么？

首先，应用中台是一定需要在企业应用系统架构设计中应用的，这是SOA的典型应用，但很多企业把SOA仅仅做成接口服务，这是一个遗憾。

其次，业务中台是可以抽象的，特别适合逻辑复杂、交互多的业务，例如偏电商的供应链相关业务，而传统的行政管理业务基本上必要性不大，资源管理类业务也可以做一定的抽象，但由于目前普遍采用成熟套装ＥＲＰ软件，因此抽象了也没有用。

第三，应用中台的设计，形成现在的微服务化，其实是有相当难度的，在设计过程中需要对业务高度熟悉，而且逻辑思维强的专业人员来分析抽象、定义，另一个方面要熟悉SOA的相关技术（最好是来自互联网公司的团队），或有相关的技术组件，才能很好的架构应用中台。此外，应用中台的优势是能“快速随需而变”，因此，应用中台的技术人员需要长期服务，这就意味说，建设应用中台和业务中台，最好是企业自己有团队有实力。

第四、业务中台与共享中心一样，是一个集团组织架构优化的好思路，从企业组织架构设计中可以先把组织中台与应用中台分离对待，建立“炮火群支援”可能可以更好的提升企业的战斗力。

今年，阿里放弃中台，我理解并不是中台本身有错，而是阿里的战略管控方式有所调整。原来是一个阿里要支持淘宝、天猫等多个产品，因此将共性的业务提炼出来形成一个技术平台，并独立一个技术团队来支撑，这本来就是企业业务共享中心的理念，大中台支撑多样化、差异化的前台业务，最大化的提高了企业资源的利用，避免重复资源投入和不规范的业务运营。现在阿里希望分散式管理，把各事业部都孵化为一个小阿里去上市，那么追求的是各事业部的差异化、个性化和快速的市场响应与发展，那么统一而固定的中台在一定程度上制约各事业部的业务差异化和快速灵活发展，拆解中台，能让各事业部自身能更紧密的衔接和高效运转，对一个个小阿里的差异化的快速发展是有利的。因此，从阿里中台的建设和中台的拆解来看，并不是中台本身的管理方式或技术结构有错，而是顺应企业战略的要求，这也进一步说明，企业架构本身没有对错，只有优劣与合适，与企业战略及其管控要求一致的架构，就是合适的架构。

 【案例分析】——一次不成功的中台建设

如果基于我对应用中台的理解，其实在2010年就有幸参加过这样一个“不成功”的“中台”实践。首先没有写错，确实是“2010年”，那时候没有中台的概念，流行的是SOA的理念；其次，虽然项目成功，系统上线，但我和当时的小伙伴后来复盘都认为项目预期目标没有实现；第三，确实是“中台”，是一次用SOA在SAP和应用前端架构一个柔性灵活的中间服务层，来解决业务不断变化后架构的适应性的实践。

1）客户遇到的问题与挑战

客户是一个领先省级电网公司，无论是管理水平还是信息化水平都是行业领先，客户一直坚持SOA的技术路线，并卓有成效，但上级集团已经明确了用SAP套装软件，其面临的挑战是两个方面，首先是以SAP为核心的企业应用，如何适应企业管理的不断调整、发展与变化；其次，原有的信息化成果如何保护与利用；第三是如何在兄弟单位都实施SAP方案中形成自己的特色亮点。

当时的行业方案是按照电网企业职能业务条块划分八大应用系统，各系统纵向贯通，但相对独立，就是大家叫的“烟囱”，然后通过信息集成的是否打通八大烟囱。而实施SAP后，把人、财、物合并为一个大烟囱了，但这个烟囱由于是套装软件，体系完整、逻辑性强，也因此更难以基于管理创新变化而调整，用客户的话说，是一个不能动的大石头。

 2）当时构想的解决方案

基于对行业业务的理解，客户与咨询实施商讨论后共同认为，业务中相对稳定不变的是基层/操作层业务，例如计算电费、检修作业、工作票、采购订单等，而容易变化的是管理流程性的内容，例如采购审批流程、招标流程等，特别是圈集团集约化的程度在不断变化，共享型的业务不断的从县供电局集中到地区供电局再到省公司，因此，应用系统架构的策略应该首先固化基本稳定的操作层业务，然后将易变的管理业务抽象为灵活组装的SOA服务，形成前端组合业务功能，并通过工作流引擎驱动。这其实有点像现在流行的“稳敏双态”架构。

基于这个策略，要做的事情是要将业务分类分块，并抽象业务为服务，然后将稳定业务功能实施在SAP中，而将灵活的业务功能抽象为服务实施在中间的服务层中，并通过前端对服务的组合和工作流驱动形成具体的业务功能。

具体的方法论是采用了IBM EA、IBM SOMA、SAP实施三种方法论进行融合。其中最关键的工作就是用IBM EA方法论来将业务分类分块，形成完整的企业架构（业务架构、应用架构、数据架构和技术架构），并用IBM SOMA抽象业务为服务。

3）最终“不成功”的效果

首先，形成的中间服务层无论是服务的合理性、完整性、颗粒度都难尽人意，难以真正的组装前端应用功能；其次，最终没有真正把SAP解构，SAP仍然保留其相对的独立性和整体性。

从方法论上，整个方案是能走通的，但是对业务的分层、分区、分块、抽象化、服务化，是有相当难度的，对SAP的解构处理也是非常难的。因此，不成功的原因有三个方面：

（1）方法论上，需要大量的熟悉甚至精通业务的专业顾问，花费很长的时间，按照企业架构的步骤进行业务架构分析，并形成分层、分区、分块，更需要在设计过程中有对业务高度熟悉、而且逻辑思维强的专业人员来分析抽象、定义业务。

（2）SAP实施上，也需要大量的专业顾问与时间，来按照业务架构与应用架构对SAP进行解构性的实施，即要分解、关闭、切断、嫁接SAP中的功能、流程和数据。

（3）SOA的实现上，SOA架构的中间服务层，也受限一些技术和软件平台。

 3）对当前中台建设的启示

无论是叫中台，还是叫基于SOA的中间应用层，其架构的先进性是值得肯定的，确实能从架构上达到结构“稳敏双态”和应用“快速灵活组装”，实现架构既稳定又灵活的“随需而变”，但难度与代价确实非常大，甚至不可完成。这个“不成功”的项目对企业架构和“中台架构”有两点启示：

（1）中台的建设不是一个技术活，也不是一个成熟中台软件可以装上就用，而是一个业务分析、整理、抽象的过程，就算是阿里自己的应用中台，也是在发展过程中，由一帮对电商业务高度熟悉、对技术十分擅长的专业人员，通过多次迭代逐步成型的，我认为其核心不在技术软件上，而在业务抽象上。

（2）传统企业，要实现中台，需要长期的项目投入、专业的资源支撑（关键是能否找到这样的专业人员），才有可能实现，甚至要为此专门成立软件公司长期服务，这个代价非常大。传统企业应该考虑自己的业务管理是否有这样的创新变化程度，是否值得花费如此的代价来实现业务“随需而变”。