一切业务数据化，一切数据业务化。

“中台”概念这几年非常火，特别是阿里、腾讯、百度、京东等互联网公司最近频繁的基于中台调整组织架构，把“中台”的热度又上升到另一个高度，甚至有这样的声音， 90 年代不做 ERP 会死，现在不做中台也会定企业生死。中台的概念起源于阿里，也发展于阿里。笔者有幸参与阿里业务中台方法体系建设，也主导参与一些阿里云新零售业务中台项目，经常被问到如下问题。本文作为“阿里巴巴业务中台”专题的第一篇，和大家分享一些思考（本文内容仅代表作者个人观点，欢迎交流）。

什么是业务中台？

中台起源于阿里，2015年，阿里提出了 “大中台，小前台”战略，灵感来源于芬兰的一家游戏公司Supercell，仅300名员工，却在短时间推出多个爆款游戏，成为全球最会赚钱的游戏公司。其实，阿里早在 2009 年建设“共享事业部”开始，就已经开始了中台的探索，并通过十年上百个客户的实践，阿里也将自己的技术和业务能力沉淀成为一整套解决方案和方法论体系。

中台是什么？不同的人有不同解读。我认为，中台是一套结合互联网技术和行业特性，将企业核心能力以共享服务形式沉淀，形成“大中台、小前台“的组织和业务机制，供企业快速低成本的进行业务创新的企业架构。中台又可以进一步细分，比如业务中台，数据中台，xx中台。本质上，都是对企业通用能力在不同层面的沉淀，并对外能力开放。

业务中台将企业的核心能力以数字化形式沉淀为各种服务中心。业务中台的目的是“提供企业能够快速，低成本创新的能力”。业务中台的核心是“构建企业共享服务中心”。业务中台的过程是通过业务板块之间的链接和协同，持续提升业务创新效率，确保关键业务链路的稳定高效和经济性兼顾的思想体系，并突出组织和业务机制。业务中台也包含技术和组织两大部分，通过“方法+工具+业务理解”加以实现。

数据中台通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。数据中台建设的基础还是数据仓库和数据中心。

那业务中台和技术中台的关系是什么呢？阿里有句话非常形象，“一切业务数据化，一切数据业务化”。业务中台源源不断地从业务造数据，把业务实时在线的交易数据进行统一记录和沉淀，这就是“业务数据化”；而数据中台对沉淀的数据进行二次加工，通过数据标准及算法，产生进一步的分析型数据服务，这些数据服务反向又服务于业务，将业务固化，形成业务闭环，也就是“数据业务化”。比如天猫淘宝的用户实时在线的交易信息，存放在业务共享中心的交易中心当中；而数据中台基于这些用户历史信息，并通过数据分析后的用户画像和标签属性，提供服务给到前端，形成千人千面。这就是我们一直讲的数据驱动、数据闭环、数据价值。

阿里业务中台核心架构是什么？

阿里巴巴超过数十个业务单元（如淘宝、天猫、聚划算、阿里巴巴）均不是独立构建在阿里云之上，在后端阿里云技术平台和前端业务之间有“共享业务事业部“（也就是这里讲的“业务中台”），将业务当中公共、通用的业务沉淀下来，包括用户中心、商品中心、交易中心、评价中心等十几个共享单元，是“厚平台的真正实现“。而后端的阿里云提供计算资源和中间件PaaS云服务能力做载体。同时，使用集团近十年的双11、双12的高可靠、可稳定的运维保障能力，对整个系统进行支撑。中台的使命是从下到上逐步完善阿里的整个体系，从阿里云、数据、中间件、算法，到上面支撑的各种业务解决方案，构建阿里自己核心的能力。

谈到中台，不得不提阿里共享服务事业部的由来，在淘宝初期，主要面向C2C的电商领域，整个系统都是围绕一套“烟囱式”的淘宝技术框架进行。随着业务的不断扩张，集团成立出天猫事业部主抓B2C电商领域，又形成了一套烟囱式发展。这种烟囱式的架构体系带来了诸多不足，比如成本的重复投入和维护、数据之间打通复用的难度、几年之后推倒重建的风险。为了解决这些问题，集团已经开始构建共享服务体系，来沉淀和复用业务能力，但是由于没有过多的业务话语权，共享服务体系的建设一开始并不顺利。之后，随着“聚划算”团购项目的启动，各种系统的流量都需要通过聚划算，这时，共享服务中心得以大展手脚，逐步将集团核心的业务能力构建成用户中心、商品中心、交易中心、评价中心、店铺中心等等数十个共享服务。可以说整个阿里中台的革命也是共享服务中心的革命，各共享服务中心聚焦核心业务单元能力的构建，协助目前集团上百个前台业务的快速创新。

我的企业需要业务中台吗？

阿里业务中台如此强大，那对于传统企业，在做数字化转型的过程中，是否需要业务中台呢？我认为，如果你的企业有以下问题的任何一个，有必要考虑建设业务中台：

• 业务具有不确定性：创新困难，无法支撑市场高速变化。如渠道扁平化管理，统一会员营销，全渠道等。
• 业务不在线：企业信息化程度不足，大量人工统计，核心业务没有做到实时、在线、统一。比如会员订单不完整，经销商进销存数据不在线等。
• 烟囱式系统多：系统割裂，数据孤岛，端到端无法实时协同，更无法基于现有系统进一步构建数据中台。
• 系统重复建设：内部大量重复建设，缺乏业务核心的固化沉淀，系统服役到期只能推倒重建。
• 业务与互联网紧密：业务与互联网紧密相关，特别是面向市场消费者，系统的弹性不足，需要支撑不确定的用户数量。

有些同学认为业务中台是大公司要考虑的，而对于业务不复杂、人员也不太多的中小公司不适合。我有不同的观点，其实，无论业务复杂与否、人员庞大与否，只要你的业务与互联网相关，需要快速应对消费者带来的不确定需求，需要打通烟囱林立的系统，需要业务在线来提高企业创新和协同，都应该考虑建设业务中台；同时，业务中台也不一定彻底推到整个系统，首先要改变意识，分步实施、小步快跑，有很多可落地的途径和方法。

那业务中台对企业有什么价值呢？这里我们先简单罗列一下。

1、激发创新：让企业通过核心能力的沉淀，给予快速创新机会，拉通业务整体的点线，降低了试错成本；
2、高效协同：中台侧重的是跨部门跨团队的深入合作，激活了组织创新；
3、业务在线：服务中心化的构建打破了烟囱式的IT架构，提高核心数据实时/在线/统一；
4、人员提升：业务沉淀中台提升了IT人员能力，提高业务运营以及全局意识，成为既懂业务又懂技术的核心战略人才；
5、变现营销：会员资产化，全渠道下沉，补全客户画像，提升精准营销；
6、智能商业：业务数据化+数据业务化的闭环模式，构建了商业智能的基础；
可以看出，业务中台无论对企业战略发展、商业模式创新，还是内部高效协同、人员培养提升等都会带来很多好处。

如何规划和建设业务中台？

很多人认为业务中台落地难，其实难在具体的规划和落地实施上，我们对业务中台的建设路径有这样的一些看法：

1、决心变革：企业内达成战略共识，一把手牵头，业务/技术等团队全局共识。做总体战略规划、分步实施，找准切入点，解决具体业务问题。比如会员营销、经销商门店、全渠道、采购供应链，不同的切入点策略不同。
2、成功试点：通过业务和系统分析调研，明确业务目标和范围，完成技术平台引入、中台建设方法论宣导，并选择验证过的技术平台和实施团队。进行试点，梳理标杆，积累经验。比如从新的业务系统尝试，或者改造现有系统，步步为营。
3、持续融合：总结出适合企业自身的理念和规范，优化组织、提升中台效率。并全面迭代和构建企业业务能力生态。

现有系统如何改造？

前文讲到业务中台在分步实施中，讲究总体规划、分步实施。面对现有系统，并不一定都要进行中台改造，我们建议“外松内紧”：

外松：面向市场和客户方面，以精细化运营为驱动，这些系统更适合建设业务中台。对外市场，快速应变，敏捷创新。比如电商、客户管理、全渠道、营销、创新业务。

内紧：面向内部和员工，以标准化流程为驱动，这些系统更适合保持不变，与业务中台进行对接。对内管理，流程严谨，标准规范。比如PLM、MES、HR、OA、财务。

共享中心如何建设？

在企业的中台能力中心建设中，核心是共享服务中心的建设，不同行业的业务中心有所不同，比如新零售领域，一些参考可以有用户中心、会员中心、营销中心、商品中心、库存中心、交易中心、结算中心、渠道中心。中心设计需要关注如下几点：
1、共享中心是核心业务通用能力沉淀，需要考虑能力地图，产品整体规划，以及协议标准、业务需求构建标准等；
2、共享中心目的是复用和协同，需要通过领域模型，对业务场景流程进行有效建模；
3、共享中心要考虑能力开放，通过API接口、配置管理、或者low-code的高可配置运行机制；
4、共享中心实现前端应用和后台的解耦，需要一定组织机制和考核倾斜，制定沟通机制和冲突升级机制。

业务中台与前台/后台/平台的关系？

业务中台与前台和后台，我认为，主要是这样的配合关系：

前台：敏捷创新，面向不同用户的触点，“点”状繁花似锦。比如2C的电商应用、2B的门店管理等，使用中台开放能力快速变化满足市场的不同业务场景。

中台：核心能力共享沉淀， “面”状协同复用。比如交易中心，正常的交易下单、双十一的预复购、团购秒杀的拼团场景，都可以通过公用的交易中心统一配置。

后台：强大的支撑能力，比如支撑系统稳定高效运行的各种后端系统，以及前文提到的面相内部标准化管理的系统，由中台统一协同和对接。

比较晚前中后台，我们来比较一下中台、平台和中心化。

中心化类似烟囱式架构，一个中心解决整个技术堆栈，而平台和中台都是为了去中心化而生，具体的区别如下：
1、中台是面向业务的能力组合和复用，提供集成化的解决方案：中台的目的是提高研发效率、降低创新的成本。中台包括人，组织，平台，数据，标准，规范，是人和系统的一整套体系。
2、中台是平台的自然演进：平台是单一团队、部门、系统的效率提升，而中台是多领域、多BU、多系统的负责协同。如果说平台的目标为高内聚、低耦合、职责边界清晰；中台是平台化的自然演进，这种演进带来“去中心化“的组织模式，突出复用、协调、业务创新差异化构建。
3、中台不是系统，中台是一种体系/生态/方法论：中台有标准和机制，解决顶层领域下各业务子域的高效协同和资源复用问题。各部门、业务域共同建设，是中台能力的使用方也是提供方。同时，中台提供整个业务快速响应的一种理念和方法，对上层业务支撑。

业务中台建设的关键要素

我们认为，企业在业务中台建设当中要关注4个升级：

1、战略升级。通过中台建设，落地企业数字化战略。中台一定是“一把手工程”，整体规划分步实施。
2、组织升级。组织架构需要与中台架构相匹配，根据企业实际情况优化组织效率，提升效能，数据化运营，更好支持业务发展和创新
3、流程升级。将企业现有流程进行梳理，优化及固化企业流程，提高企业共享复用能力，提升企业运作效率。
4、技术升级。通过互联网技术，对企业基础技术设施进行升级，降本增效，达到企业IT部门整体技术升级。

业务中台需要哪些核心技术来支撑？

业务中台落地中需要一些核心技术，我们也叫“技术中台”，有一些通用的建议：
1、尽可能拆分，共享中心建设：企业应该尽可能地拆分自己的应用，进行共享服务中心的建设，将核心的业务能力复用和沉淀。共享中心的拆分也可以有层次，可从从基础主数据、核心业务、流程规则等角度来进行拆分。
2、去中心化，线性扩展：企业需要采用去中心化架构，没有核心流量汇入点，服务中心尽量无状态，便于水平扩展。这样平均分担压力，负载均衡，对单个中心带来的负载更小，故障影响的范围也更小。
3、数据化运营：去中心化也会面对系统运维和管理成本上升的问题。企业需要对自身的运维运营过程进行积累和沉淀，整理出数据化、自动化运维的经验，同时增强监控告警、限流降级、性能分析诊断等方面的能力，精准定位目前系统中存在的问题，并提出相应的改善方案。
4、异步化，最终一致：在大量的实践中，大部分业务流程不需要强一致性，而使用最终一致来平衡。我们需要使用异步解耦，如使用消息队列来完成业务逻辑，缩短相应周期。
5、尽可能自动化：企业进行中台改造，要求企业尽可能提高自动化能力，比如自动部署、自动弹性扩容、自动升降级、自动限流降级，降低运营成本，也提高系统的稳定性和业务连续性。
6、尽可能使用成熟组件：中台的建设要求企业将重心放在服务中心上，对于底层组件，尤其是中间件层面，尽量使用成熟的云原生组件来提高系统稳定性和性能。目前，阿里巴巴中间件已经将多年经双十一购物狂欢节的严苛考验的技术沉淀，以阿里云标准云服务的方式输出给外部客户，其中包括多款阿里云云原生中间件产品（比如K8S/EDAS/MQ/DRDS/ARMS/PTS/CSB/GTS/MSE/ACM），阿里与流行的云原生技术完整融合（比如Dubbo/SpringCloud/K8S/RocketMQ/Nacos）。

阿里在业务中台建设上能提供什么？

阿里是最早提出中台概念，并成功实施落地，阿里中台所配套的中间件是经过阿里多年双十一洗礼的成熟产品。阿里内部几百个业务应用，共享一个技术中台底座，服务新的业务场景，带来更好的用户业务体验。同时，阿里云通过为上百个外部客户实施业务中台，培养了一大批具备中台实施交付能力的行业ISV，同时沉淀了大量行业最佳实践。

阿里云提供一整套“业务中台技术解决方案”可以解决的问题有：

• 将企业核心能力下沉共享，加速企业创新速度；
• 规范IT全生命周期管理，提升研发效率与质量；
• 提供行业最佳实践，助力企业快速落地中台战略。

架构优势

• 云原生：支持弹性调度、微服务化解耦，自动化运维；
• 高可靠：阿里中间件产品支持，历经多年双11考验；
• 高并发：支持按流量线性扩展，支撑海量用户。

更为重要的，阿里基于近十年的最佳实践，沉淀了一整套业务中台实施的方法论，包括中台架构设计、微服务架构设计、中台开发规范、全链路压测等方面的最佳实践。这些全方位的中台建设方法论、阿里商业能力、阿里云技术支撑，不仅仅是技术红利的分享，更重要的是整个阿里中台战略思想的传播。

更多可以参考“阿里云业务中台技术解决方案官网”。

小结

本文希望通过笔者在阿里业务中台方法体系建设及项目中的一些经验，为企业在业务中台建设过程提供一些帮助。同时本文是“阿里巴巴业务中台”专题的第一篇，后续我们还会有中台方法、中心设计、典型场景、最佳实践等更多精彩内容，敬请期待，欢迎与我交流。

参考资料：

• 阿里云业务中台技术解决方案官网
  https://www.aliyun.com/solution/bme/index
• 阿里架构总监一次讲透中台架构，13页PPT精华详解
  https://yq.aliyun.com/articles/717505
• 互联网时代的企业必定都要实现中台
  https://yq.aliyun.com/articles/717505

作者信息：王思轩，花名宇升，阿里云业务中台&云原生架构师，博士留学期间发表论文10余篇，多年大型分布式系统架构设计经验，现主要参与阿里云业务中台方法体系建设，以及新零售业务中台和云原生技术咨询工作。