自 2015 年阿里巴巴提出“大中台，小前台”战略以来，短短不到 5 年时间里，“中台战略”这个概念开始在国内 IT 领域普及开来。与此同时，国内仍有大量企业还在传统 IT 向互联网化或数字化转型的道路上探索着，大量的新概念和新技术不断刺激着整个市场。在后疫情时期下许多企业才刚刚摸出点中台的门道，阿里却开始了对中台战略的自我否定。本文以个人对中台概念的学习理解，结合众多业内专业人士的权威解读进行了整合，争取能从纷乱繁杂的中台知识体系中抽丝剥茧，提炼出有指导性建议的内容供大家分享交流。所谓弱水三千只取一瓢饮，中台只是个名称，我相信如果我们能抓住中台的本质，结合自身业务去思考，就一定能更加客观理性的去看待它。

中台的背景

IT 界一个有趣的现象，越是没有权威定义的概念，越容易获得大家的追捧。中台也是如此，你很难去给它下一个准确的定义，虽不至于如“一千个人眼中有一千个哈姆雷特”那样，但绝对容易引起大家的讨论。我们不妨先看看中台诞生的背景，或许这样能够更具像化的去理解它。

“中台”二字是阿里巴巴于 2015 年年底正式对外宣布的“中台战略”中提出的，彼时大家对它的定位还比较模糊并没什么直观的体会，但随着这几年阿里系业务在各行各业的迅速渗透，大家已经对其中台所带来的商业竞争力产生敬畏。让我们把时间再往回拨到 15 年中左右，马云率队远赴遥远的斯堪的纳维亚半岛去拜访芬兰一家“小而美”的游戏制作公司——SUPERCELL，这家当时只有 200 多名雇员的“小作坊”制作了全球屈指可数的几款爆款手游。从公司名就不难看出 SUPERCELL 所强调的价值观——坚持高质量且小规模的团队，CEO 潘纳宁始终相信充满信任且具备自组织能力的团队是确保公司能长久生存的根本。也正因为如此，SUPERCELL 尽其所能最大化的鼓励创新并拥抱失败。而支撑起公司能快速试错以迅速占领市场的一大秘诀就在于其背后的强大“中台”能力，SUPERCELL 将游戏开发过程中所用到的公共和通用的游戏素材与算法整合起来，为前端“CELL（5～7 人小团队）”提供工具和框架，实现了短时间内开发出新游戏的目标。据说阿里的领导层受此启发，并结合自身过往的经验决定进行组织架构调整。一股新的思想浪潮就这样顺着波罗的海的海风飘向了中国大陆，最终促成了阿里中台战略的落地。

如何看待中台

无论是从阿里还是 SUPERCELL 的情况去分析，中台本质上是要解决企业业务在复杂多变的市场环境中如何具备快速应变的能力。IT 行业中惯用的伎俩就是将复杂的问题进行分层，中台归根结底还是分而治之的产物，只不过它所处的位置和看待问题的角度更加宏观。

我认为搞清楚中台的概念之前，有几点需要明确。现如今都强调向客户交付价值，所谓价值是指服务商的交付内容对客户业务产生了实质性的影响，并且这种影响应该是积极性的，即客户通过采用服务商的交付物获得了业务价值的提升，在这种价值的输出上，主要依赖服务商的产品、服务及解决方案。其中产品应作为整个价值交付中不可分割的最小单元，是实体化的产品（通常也用来支撑计费标准），而服务则是产品价值的延伸，二者的组合则形成解决方案，解决方案通常用来处理特定场合下的特定问题，其自身包含一定的业务属性。举一个生活中的例子，比如油漆、瓷砖、各种耗材我们称之为产品。而改水电、墙地面处理等工作我们称之为服务，它们本身是产品价值的延伸。最后我们说全屋定制是一种解决方案，可以针对办公楼宇或者家庭住宅等不同场景进行细分。

将以上提到的产品、服务及解决方案进行封装整合并对外提供商业价值，就是我们所说的平台了。“平台”更加容易从技术角度去解释，例如大数据平台、云计算平台、物联网平台等。这时我们再来看中台，它其实是平台价值的延伸，并且平台对客户而言本身要么没有很强的业务属性，要么就是顺应具体的业务需求而建，而后者恰恰是它们之间最大的区别。

中台改变了什么

大部分的企业是重流程的，也就是从组织架构上来看，多个部门各司其职，希望通过流程来控制结果，这种理念在一些传统业务场景下是合适的。但当前的市场环境强调“VUCA“，即 Volatility（易变性）、Uncertainty（不确定性）、Complexity（复杂性）和 Ambiguity（模糊性）。企业如果想在这样瞬息万变的环境中保持生命力，就需要具备一定的商业洞察力和主动敏捷的应变能力。那些重流程化的方式将每个职能团队限定在自己所聚焦的业务指标上，比如产研关注产品先进性，销售部门关注营收业绩，市场运营团队紧盯用户增长，采购和法务等部门也都各司其职，这种状态其实是站在自身的角度来应对市场的，也就是说并没有从客户的角度出发，这与我们一开始所提到的”向客户交付价值“有些背道而驰。

而中台所带来的最大变革就是从企业的组织架构层面进行改进和优化，首先是将各业务部门的战略目标对齐，绩效关注重点需要被统一描述为“面向客户提供价值”来考量贡献度。其次是将以人为核心的业务团队位置提前（形成前台，具备机动性），而把以资源为核心的能力、流程置后，从中梳理沉淀出中台。这里要强调的一点是，理想化的中台不应该是技术工具的堆砌，也不仅是“流程可复制”，特别是后者通常作为平台建设的出发点，也就是我们经常会遇到某客户想搭建一个大数据平台或者一个”xx 平台”，这种需求一般是以具体的业务背景来推动的，它受限于业务诉求本身的条件，例如较为固化的流程和能力覆盖面，简而言之“平台”的适用范围有它的局限性，所以我们说某些业务可以复用该平台的能力，但是很难说在企业内部被全面普及，更不用说对外提供服务了。

中台的建设规划不会参考一个或某几个业务背景来设计，而是站在企业全局的角度出发，核心目标是解决前台与后台的配速问题，最终服务的是企业目前以及将来可能产生的业务。何为配速问题呢？这里举一个生活中的例子，我们每天一日三餐必不可少，家里面都会有冰箱等设施用来储藏食物和各类原材料，在这里冰箱就属于后台基础设施的典型代表，它的设计目标就是用来确保食物保鲜，我们假设它相当于 IaaS 层对数据进行存储和处理，但是它并不考虑业务打算如何应用数据。这在企业发展初期是可以被接受的，而如果随着业务规模不断扩大，新老业务交替出现，原来的那套强调标准化、资源复用节约的手段就有些力不从心了。这就好比在家做饭是需要有准备工作的，进了家门突然想吃一碗牛肉面，但肉还在冰箱里，面粉还没来得及加工，真不知道什么时候才能吃上。这就是快速变化的业务需求与后台僵化的能力之间所产生的配速问题，我们显然不能怪罪于后台服务，也更不可能抑制需求的变化，此时就需要一个“中台”角色来帮我们协调好两者之间的步调。

还是拿餐饮界举例，有一个叫做“中央厨房”的概念，它的出现从很大程度上改变了传统餐厅后厨的功能性、使用频率等问题，现在很多餐饮公司会统一由中央厨房进行食品原材料加工，然后统一配送到各个门店。这里中央厨房就等同于“中台”角色，而门店则是各业务部门，因其所经营的菜系和品类特征各不相同，所以中央厨房这一中台能力很好的支撑了前端业务，同时还提供配送服务以及优化前台店铺面积、雇员数量、餐厅运营流程等能力，最终将价值直接体现在提升前台餐厅的出餐效率、客户满意度，亦或是降低店面运营成本等方面。上面这个例子放在 IT 行业可能未必十分准确但足够具备参考意义，如果说没有中台的业务模式是“面向过程”的，那么有了中台后的业务模式应该是“面向对象”的，所有前台的业务都可以理解为基于中台的“实例化”。

中台的分类

上面聊了很多务虚的内容，总的来说“平台化”也好，“中台化”也罢，其实都是手段而非目的，一个中台做的好不好最终还是前台说了算。纵观目前业界趋势，大致可将中台分为以下几类：

1. 业务中台——对底层资源做抽象和封装，实现可复用的业务能力，为前台提供易用的服务；

2. 数据中台——从后台及业务中台将数据进行汇总，完成数据的存储、转化和处理的过程，为企业提供核心的数据平台，同时为前台提供基于数据驱动的创新能力和为业务中台提供基于数据反馈的持续优化能力；

3. 技术中台——辅助业务中台和数据中台的建设，以技术工具为核心提供支撑，例如借助云计算等基础设施服务等能力，或其他 PaaS 平台进行整合包装，尽量屏蔽复杂的技术细节，通过开放的 API 帮助企业加速建设中台体系；

4. 研发中台——主要解决软件工程中遇到的问题，基于方法和实践，以工具的形式进行赋能，包含了 DevOps 整套体系的概念，例如敏捷开发、CI/CD 流水线等；

5. 组织中台——从组织架构角度设置专门的团队，对项目提供诸如风险管理、资源协调、投资指导等方面的服务和支持。

前两类（即业务中台与数据中台）是当前企业构建中台战略所主要采用的实践，其余的内容更多是新瓶装旧酒，作为补足中台“大而全”的拼图。当前云计算厂商多善于利用”技术中台“概念对产品服务进行包装，以借中台热度帮助自己”带货“，其交付内容本质与之前的 IaaS、PaaS 产品并无二致，只不过随着技术不断优化更易于与客户业务进行深度的集成，同时可以借助生态合作伙伴的力量来拓展垂类行业。

研发中台方面主要以 DevOps 解决方案为主，将企业的生产效能进行整合优化，通过持续集成流水线实现质量内建，以此提高产研团队整体的敏捷性和最终用户满意度。

组织中台更多是从组织架构角度出发，成立专门的类似 PMO 的职能角色，用于辅助项目过程的管理，风险控制等工作，组织中台可以优化工作流程，减少跨团队协作可能产生的工作浪费。

如何落地

这里以业务中台和数据中台进行举例说明，一般情况下两者之间属于互补关系，前者负责封装可复用的企业能力（主要的业务逻辑），以提升对外部需求的快速响应能力。后者通过打通内外部数据让业务更加智能。因此一个是针对应用层面（Application），另一个是针对数据层面（Data）。企业的中台建设策略应该考虑将业务中台进一步细分为“通用能力中台”与“核心能力中台”，像一些辅助支撑类的业务系统，例如财务、OA、采购等应该避免被纳入到核心业务链路中，将核心能力中台适当的瘦身可以更好的面向外部用户提供服务，前台有业务需求时可以直接找中台而不必每次都改动自己的底层。

在设计和构建业务中台时，目前业界比较好的实践是采用“领域驱动设计（Domain Driven Design）”进行辅助指导。之所以借鉴 DDD 模式，主要是用到其战略设计和战术设计这两个方法论，所谓战略设计是指以业务语言进行系统的建模，力图将复杂的技术实现细节在设计规划阶段单独剥离出来，这样经过战略设计后的业务建模更加清晰规范。然后再采用战术设计来对业务建模实现技术手段的映射。领域驱动设计这一概念并不是新鲜事物，它非常适合用来设计微服务架构的系统，其中业务领域划分的方法可以帮助企业梳理中台内部各个业务模块的边界。

如果把前台比喻成前线机动性作战部队（就好比 SUPERCELL 公司中的小团队），业务中台相当于海陆空专业的战术能力，则数据中台就是情报中心及指挥部。数据中台概念与传统的大数据平台建设方式并没有太大的差别，只是更具针对性。数据中台的服务对象大体可以分为两条路径，一个是直接对前台业务，另外一条就是服务于内部运营。所以在设计阶段需要重点考虑如何与前台以及业务中台融会贯通。总的来说数据中台应具备以下三大职能：

1. 全域数据的采集与存储，并且可集中管理（解决数据分散各地的问题）；

2. 必须有标准的数据规范，要有能力将数据加工成面向不同主题的数据应用（数据治理工作）；

3. 支持各维度数据的价值提取，通过数据化运营推动业务创新（数据驱动运营）。

数据中台的落地步骤可以参考传统大数据平台的建设方法，首先是将企业内部的数据孤岛解决，实现各类型数据的采集汇总。其次是建立实时或非实时的大数据处理平台，最后实现全维度数据分析能力，能够从数据中提炼价值并达到数字化运营的水平。数据中台要兼具 OLTP 和 OLAP 的能力，通常建立在数仓之上提供服务给业务方使用，随着近年来数据湖（Data Lake）概念的兴起，更多非结构化数据得以被充分利用起来，传统的 ETL 过程在数据湖平台上更趋向于 ELT，数据能够按照业务需求灵活的调整处理模式。

常见的阻碍

中台是把双刃剑，企业要想很好的驾驭它先要克服几点困难，第一就是评估是否有必要进行中台化改造，按照康威定律的说法，企业的组织架构直接决定产品技术架构，那么如果说当前业务发展迅速，且需要不断适应外部需求变化，那么可以考虑引入中台化。在明确了必要性之后，则需要重点关注如何控制好中台化改造所带来的负面影响，做到尽量的“无痛”，以下几个问题需要引起决策者的重点关注：

1. 跨团队目标一致，统一面向客户提供价值。这样会改变当前的绩效评估方式，以及对组织架构作出调整，需要找到一种折中的方案。对于一些赋能型团队，很难完全量化工作产出，因此 OKR（Objectives and Key Results）是以结果为导向的绩效管理方法，比较适合在中台落地时采用。

2. 业务中台在技术改造时势必会引入微服务化架构，正如以前企业 IT 架构从单体应用到面向服务架构（SOA，Service-Oriented Architecture）的演进。这可能对当前的技术架构产生颠覆性影响，且服务化所引入的运维成本也会在初期阶段明显上涨，应该循序渐进的进行技术改革，按照不断迭代优化的方式小步快走。

数据中台的建设需要先做好数据治理的工作，特别是对数据规范要定义清楚。而且在引入数据湖技术时，要避免做成数据沼泽。

总结

综上所述，如果用一句话来概括“什么是中台“，我认为应该说“中台是一种组织能力”。它把企业的各类型资源整合封装进而实现业务能力可复用。如果说 DevOps 让产研团队变得敏捷，那么中台架构则让整个企业更加的敏捷。通过中台可以获得比竞争对手更多的试错机会，可以更灵活机动的调整自身业务，以便更好的适应市场竞争。

从服务商的角度来看中台，首先它不可归结为单一类型产品或服务，而应该作为解决方案来进行售卖，并且中台方案应该至少包括咨询服务与产品工具两种形式。纵观目前的国内大型企业应该只有阿里具备相对丰富的中台落地经验。但这里有一个很大的问题就是中台本身无法一对一复制，但好在中台概念算是“Made in China”，我们可以更自主的去理解和消化它，并结合自身情况进行裁剪。如果在推动中台相关的项目时，甲乙双方就中台概念理解一致，目标相同的话，其实就不必纠结要不要用“中台”这个名字。但如果甲方对“中台”寄予厚望，且过分期待它所能产生的价值以及低估实施过程中可能出现的阻碍，那么有必要提前给客户泼冷水，毕竟中台不是万金油，我们要对它有理性客观的认识，并有必要以专业负责的职业态度尽早帮助客户纠偏。

技术支撑架构，架构服务于业务，而业务取决于企业的战略。中台是实现业务敏捷化的手段而不是目标。中台与数字化转型通常被一同提及，后者是利用数字信息技术支撑企业转型，这是一个非常大的话题，而中台只是其中一个可选的手段，但不是必须的。最后希望本文能够帮助大家更好的理解中台概念，在项目中遇到类似问题能够调理清晰的引导客户，同时也期待与大家一同交流。