一、背景介绍

1.1、中台的起源

中台思想很早在美国军事上已有实践场景，比如美国海豹突击队，他们要执行任务，通过小团队出征，小团队到达战场后，会将单个小队无法扫除障碍的问题和具体情况反馈给指挥中心，指挥中心会根据前方战况灵活调度海陆空火力资源，帮他们扫除。

指挥中心，比如航母群就是一个中间平台，上面有飞机、坦克、装甲车、登陆艇、鱼雷、雷达等各种资源，随时可以提供调度，支持前方战场，高效的协同；整个海豹突击队的作战模式，用小团队去快速调整应对各种变化，后方指挥中心通过高效协同，迅速清理障碍，其实与中台很像，只不过当时没有人把这个作战平台叫作中台。

另外一个应用到商业典型经典案例，也是启发阿里巴巴-马云和他的团队进行中台战略的最主要因素。

该经典案例是来自芬兰的一个叫 Supercell 游戏公司，公司规模不大，五十人左右，基本上一个月就能发布一款游戏，例如比较出名的部落冲突、卡通农场、海盗奇兵、皇室战争、荒野乱斗等，都是这个公司小团队做出来的；通常我们知道，游戏的话没有个大半年，甚至更长都无法上市，而这家公司基本上一个月就能拿出一款游戏；原因是他将游戏的剧情编辑、地图、背景、人物风格、刀具、规则引擎等，都多元化、模块化、组件化，他们想要什么游戏，直接去选游戏的要素，灵活编辑即可，而这些组件都是提前固化好的，所以游戏交付周期降低，节大的控制了成本，提高了生产力。

从 2015 年开始，以阿里巴巴为代表的各互联网巨 头，陆续开启中台化进程(如图 1)。随后，“中台” 理念和相关实践开始快速向各行业渗透和发展。

1.2、常见的组织应用

“在中国古代东汉时期，尚书台成为政府的中枢，号称中台。唐朝所完善的三省六部制，以门下省为西台，中书省为东台，也将尚书省称为中台。尚书省作为执行机构，辖吏、户、礼、兵、刑、工六部，如图 3-1 所示。”

在投资银行的组织结构中，前-中-后台分别有自己的释义。

前台(Front office）：是与客户和顾客（无论是个人客户还是公司客户）直接互动的岗位，诸如大堂经理、客户经理、柜员等。

中台(Middle office）：是指直接支援前台工作的所有人员，使用前台或后台的资源，为前台提供专业性的管理和指导，并进行风险控制，比如风险管理、合规、财务管控以及 IT 服务等。

后台(Back office）：指幕后的职能岗位，行使管理职能，比如结算、清算、会计、人力资源等。

1.3、前后台架构的演变

在很早以前，Client-Server 端作为传统部署架构，再到后期大家习惯 MVC 三层架构(视图层、控制层、数据模型层)，这里面其实都涵盖了前后台的概念。

1.3.1、前台+后台架构

起初的架构如下图，只依赖前台+后台即可。

前台：指由各类前台系统组成的前端平台。每个前台系统都是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机 App，微信公众号等都属于前台范畴。

后台：指由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。

1.3.2、前台+网关+BFF+后台架构

由于前台设备类型增多(iPhone/Android/iPad/WindowsPhone)，后台业务复杂性增加进而发展微服务架构，逐步发现仅仅是前台+后台的架构方式已经不满足当前快速支持市场业务变化，诸如隔离、聚合、裁剪和适配等问题日益明显。

• 隔离问题：无线 App 和内部微服务强耦合，任何一边的变化都可能对另外一边造成影响；

• 裁剪问题：App 需要根据设备类型进行裁剪，比如手机屏幕小，需要多裁掉一些不必要的内容，Pad 的屏幕比较大，可以少裁掉一些内容；

• 适配问题：有些后台服务比较老，只支持老的 SOAP/XML 格式，不支持新的 JSON 格式，则无线 App 需要适配处理不同数据格式；

基于以上问题，采取了新的架构如下图，通过 BFF 层解决适配问题，通过网关层解决掉服务隔离和路由、限流安全等问题。

网关：专注跨横切面的功能，包括：路由，将来自无线设备的请求路由到后端的某个微服务 BFF 集群。认证，对涉及敏感数据的 API 访问进行集中认证鉴权。监控，对 API 调用进行性能监控。限流熔断，当出现流量洪峰，或者后端 BFF/微服务出现延迟或故障，网关能够主动进行限流熔断，保护后端服务，并保持前端用户体验可以接受。安全防爬，收集访问日志，通过后台分析出恶意行为，并阻断恶意请求。

BFF：BFF((Backend for Frontend))是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑）。

1.3.3、遗留可视化债务架构

当随着我们前端快速的业务创新、客户和业务数据却因为组织的壁垒无法打通。诸如滴滴网约车事业部与顺风车事业部、花小猪的数据割裂，造成数据孤岛现象严重。对于企业越来越重视用户的一致性体验来说，无疑带来极大的冲击。同时，阿里 2022 年将淘宝和天猫进行融合，也是在应对快速变化的环境，更好的保障客户一致性体验和客户价值。在京东同样发生着以上的事情，诸如跨境业务、商业化业务、海外业务都是基于主战业务的扩展，不同垂直业务如同烟囱式的重复建设，在面对业务变化的同时，不仅仅数据孤岛严重，组织协同也带来巨大负担，另外企业还为此付出极大的昂贵成本(人力、资源)。在现代化数字基建下(如下图)，从用户价值上没有带来更好的体验、从企业组织上没有带来更高的效率、也无法保证质量的交付，从企业支出上却反而不断追加成本。基于以上遗留的可视化债务，企业不得不进行架构升级。

如何消除数据孤岛、组织壁垒、重复建设，中台建设是行业普遍认同的有效解决方案。

二、现代企业架构

2.1、中台的价值

2.1.1、什么是中台(Middle Office)

"中台架构，是将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新， 实现以数字化资产的形态构建企业核心差异化竞争力。"---阿里巴巴中间件团队

"企业级的能力复用平台"---ThoughtWorks 首席咨询师 王健

“企业级”划定了中台的范围，区分开了单系统的服务化与微服务。

“能力”指定了中台的主要承载对象，能力的抽象解释了各种各样中台的存在。

“复用”定义了中台的核心价值，过去的平台化对于易复用性并没有给予足够关注。中台的兴起，使得人们的目光更多的从平台内部，转换到平台对于前台业务的支撑上。

“平台”说明了中台的主要形式，区别于应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支持。

那么从上述的定义来看，中台建设与我们在 1.3.3 小节中提到的解决数据孤岛和重复建设目标相同，重点在于复用。

那么再来思考一个问题：中台复用的是什么？

中台本质上是针对于“商业模式”和“业务模式”的抽象与复用。背后体现的是企业希望通过对于自身商业模式的 不断思考与认知，再通过自身业务模式的抽象与沉淀，实现跨地域、跨用户、 跨场景、跨领域的扩展与复用，支撑企业业务的快速拓展与创新，也体现和契合了平台向业务的再演进过程。

所以中台仅仅是手段和过程，它并不是目的的本身(这也解释了为什么中台失败案例的频频发生，因为仅仅是建立了中台组织结构并不代表对于你的企业解决了问题和带来了价值)。我们本质上是希望通过中台建设的手段达到对企业的自身业务模式阶段性的深度思考和沉淀，进而支撑未来业务的快速扩展与再演进。

通过海比研究院之前的调查来看中台能解决的四大类问题。

在此，我重新尝试定义下中台的个人理解，中台是基于企业级能力复用的阶段性探索，也是支持未来业务扩展和再演进的手段。

“中台，通过对业务、数据和技术的抽象，对服务能力进行复用，构建了企业级的服务能力，消除了企业内部各业务部门、各分子公司间的壁垒，适应了企业，特别是大型企业集团业务多元化的发展战略。基于中台，可快速构建面向最终消费者和客户的前台应用，从而满足各种个性化特征的前台需求，为企业的数字化转型提供明确的道路。”

摘录来自

中台战略：中台建设与数字商业

陈新宇

2.1.2、中台对于企业的影响

中台基于企业级能力复用的阶段性探索，也是支持未来业务扩展和再演进的手段。我们现代化企业面临的问题(数据孤岛、重复建设)，那么我们基于企业问题域的解决方案之一是中台建设，根据康威法则来说，

Organization which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.

设计系统的组织其产生的设计等价于组织间的沟通结构

Conway’s law reversed: You won’t be able to successfully establish an efficient organization structure that is not supported by your system design(architecture)。

如果你的系统架构不支持，你无法建立一个高效的组织架构。如果你的组织架构不支持，你也无法建立一个高效的系统架构。

所以本质上来说，中台建设也会产生相应的组织和系统架构映射。如果从单体系统中的业务架构、数据架构、应用架构、技术架构体系将可共享的组织服务、可共享的数据服务、可共享的业务服务、可共享的技术服务等提取沉淀，进而便可融化企业架构组织中台架构、数据中台、业务中台和技术中台架构体系。

2.2、中台的分类

在 2.1 小节中，已经明确中台建设的消除数据孤岛、减少重复建设 2 个大目标。在中台建设的过程中，中台建设数据和基础设施资源必然是先行策略，同时为了保障中台建设的更好落地，也需要从组织结构上考虑。至此我们已经明晰，中台的分类一般大概三种：数据中台、技术中台、组织中台。此外在电商业务领域非常成熟的阿里和京东，当面对想要将系统复用到跨境、商业化业务的时候，依然面临着业务系统的重复建设和大量的资源投入，所以便有了业务中台。在现代企业架构中，越来越多的企业更加关注到业务模式的复用，也就是业务中台建设。

为了便于大家理解，先给大家一个通俗简单的划分：

• 技术中台，比如微服务开发框架、Devops 平台、PaaS 平台，容器云之类的

• 数据中台，比如数据模型中心，数据开发中心，数据存储中心，数据服务中心等

• 组织中台，比如企业内部资源调度中心和内部创新孵化组织等

• 业务中台，比如用户中心，订单中心、商品中心、库存中心、交易中心等

那么如果我们从更专业的角度来看下，其实每个中台分类的背后代表的是一类问题+解决方案。

2.2.1、技术中台

技术中台指的是将公共技术组件、工具、平台的通用的技术能力聚合到一起，由同一个团队负责，防止重复造轮子，这也是最容易实现的中台化。比如各公司的基础服务(微服务开发框架、Devops 平台、PaaS 平台，容器云之类的)，阿里的淘宝、天猫、飞猪等业务使用同一套基础服务框架(HSF、EDAS 等); 滴滴的快车、专车、顺风车等业务之间使用同一套基础服务框架（DiSF、DDMQ、Fusion 等); 京东的商城、到家、健康业务之间也同样如此，使用同一套基础服务(JSF、JimDB 等)。

那么其实这样理解是从技术实现角度的狭义定义，也就是我们经常说的基础架构部做的就是这类事情。

如果从更广义的角度来定义、比如 Kafka 被各个系统共用，但是需要额外开发对接，那么这也涉及重复的工作成本问题。所以为了更好的落地中台，我们通常会提供技术平台，也就是大家常说的 PaaS 平台，平台即服务(Platform as a Service)。

2.2.1.1、核心问题

技术中台的行业隔离度问题，比如我们传统的国企、银行、证券、保险通常很多项目是通过采购或者外包形式建设的业务系统。上面提到我们本质上是期望解决的复用问题，而该复用问题的解决方案到底是否是技术中台，可能需要技术管理者需要深度思考的一个问题。

2.2.1.2、核心举措

综合自己的业务量、数据量规模对于企业发展的阻碍程度、平衡自身企业的资源人力成本情况，如果对于数据孤岛和重复建设问题并不明显，建议不要选择中台的方案。中台的建设是一个持续完善的过程。

2.2.2、数据中台

上面我们提到的现代企业面临的信息孤岛和重复建设 2 大难题，其中数据中台便是信息孤岛的解决方案之一，可以帮助企业进行数据资产管理，通过提供一整套平台工具以支持数据采集、开发、治理、安全、及权限等，为企业提供“从数据到价值”的数据服务生产能力。

数据中台简单理解为是企业的数据服务工厂，通过业务系统产生数据，数据中台进行二次加工处理数据，产生数据产品，然后把它以各种方式(例如 data API 的方式)提供给前台或者业务系统形成业务产品，销售出去。

在电商行业中，通常用“采”、“卖”、“给”、“退”四个字便可以涵盖交易的整个数据生命周期，而信息流、订单流、资金流、实物流中则传递的是数据，携带的便是业务价值。

2.2.2.1、四类核心问题

数据中台建设的特殊使命主要在于解决以下四类核心问题：

1）数据信任：因为数据质量不齐、获取难度大，数据消费者包括经营决策者对数据失去信心；

2) 需求响应：开发周期长、效率低、服务响应慢、计算资源紧张、数据时效性不强；

3) 协作效率：架构平台化、组织模式去中心化的趋势下， 数据复用与协作越发重要；

4）创新乏力：全局规划、确保共识，统筹数据积累，才能更好地开展创新。

2.2.2.2、五个核心举措

基于以上核心问题，需要数据中台的 5 个举措：

图来自 IBM 对于数据中台商业价值研究

采、析、用、治、运

图来自 IBM 对于数据中台商业价值研究

1) 治理标准化：通过数据标准化治理，进而保证采集、获取和存储的数据质量。

2) 数据资产化：盘点、分析、探索数据，可以通过数据来进行资产化，形成企业的第四张"报表".

3) 资产服务化：开放 data API 服务，让数据服务化协助智慧业务的决策；

4) 数据业务化：通过不断沉淀业务数据、进而加工驱动业务的创新；

5) 运营平台化：将数据可视化运营，便于运营管理人员进行精准分析和度量；

通过采、析、用、治、运的循环不断加深数据中台建设，本质上也是一个长期良性循环的过程，如果只是期望快速的能够搭建一个数据中台并能挖掘价值，则可能收益不会那么明显。

2.2.3、组织中台

组织中台的概念，来源穆胜老师在《释放潜能：平台型组织的进化路线图》书中，分析海尔平台化组织的演进过程提出的。组织中台比较像企业中的内部风投和创新孵化机构，为前台组织和团队构建创新型前台应用提供基础能力支持，在京东的企业内部，会有采购中台、供应链中台、运营中台等组织机构。

2.2.3.1、核心问题

组织中台的核心问题更多在于如何进行高效协同、快速调整战略来面对复杂多变的业务，是基于康威定律的一种业务系统架构和组织架构之间的映射，比如滴滴的 2021 年成立的智能中台更多聚焦于车载业务、交易业务、客服业务等共性的业务单元。

2.2.3.2、核心举措

我们在面临企业问题域的时候更多可以从中台思维入手，重新对“人”“事”“流程”“企业运营”进行平台化 / 中台化改造。然后在之前的中台定义时候，已经提到过一点中台是基于企业级能力复用的阶段性探索，也是支持未来业务扩展和再演进的手段。那么组织中台也是我们通过中台化思维，加速企业管理标准化和提升运营能力的一种手段。

2.2.4、业务中台

网易副总裁汪源曾在网易云创峰会上提到过：“所有的中台都是业务中台”。这个可以从广义上来理解，不论是业务中台还是数据中台或者技术中台等，都是为企业业务发展而形成的解决方案。

但是在企业中，我们还是需要从狭义的视角来理解，我们通常说的业务中台是将前台业务中公共、通用的业务沉淀下来，如会员中心、营销中心、商品中心、订单中心、等若干共享能力中心，形成“厚平台”的真正实现。也就是说我们的业务中台能力中心的设计原则是围绕一个业务领域来实现可复用的高内聚、低耦合的服务集合，并且这个能力中心通过产品化、平台化的方式，使其达到可以运营的目的。

2.2.4.1、核心问题

业务中台起源于公司的不同业务线，售卖的产品渠道不同、消费用户群体不同、售卖区域不同，进而形成烟囱式重复建设的问题域。比如京东会有主站(APP、M 站、小程序、PC 网页端)、国际站(泰国、印尼、马来西亚)、商业化(北汽、宜宾、商羚、数智农批)、开放(开普勒、京东云)、垂直业务(7F、拼购、京喜、到家...)等，而这些将不同业务线解决相同问题域的解决方案进行抽象与封装，通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求，实现对于不同业务线的业务支撑，就是业务中台的价值所在，如果当前您的企业或者您的系统还没有满足多元化业务，则业务中台可能是需要谨慎的一件事。

2.2.4.2、核心举措

业务中台建设，往往是企业或者管理者最难实施的一件事情。复杂度远远高于技术中台、数据中台和组织中台。目前阿里的 BizWorks、京东的藏经阁都是在提供业务中台快速建设与运营整体解决方案，后面会以系统案例来具体开展讲解，从方法论到建模实践的过程。

2.3、中台与平台的关系

中台的本质是一种分布式应用系统分层架构方式，作为我们之前提到的中台建设是为了消除数据孤岛现象、打破组织壁垒、减少重复建设的有效方式，通过共享和复用为企业提高效率、降低成本。中台建设之前，我们曾经尝试过代码复用、函数复用、类复用到组件复用等不同层级和粒度的复用探索，对于真理和解决方案，我们一直没有放弃过尝试。

举个中台服务的例子，我们在使用网站或者 APP 的时候经常会有个登录认证，如果每个业务系统都需要登录认证模块，那么传统单体系统的每个业务应用就都需要开发一遍登录认证，这就造成了大量的重复建设和浪费。那么如果我们把登录认证提取为公共服务，不仅将登陆方案规范化，并且为企业降低重复建设的成本。

平台的本质是一种对于不同渠道触达客户平台工具。比如我们刚才提到的登录认证服务，我们可以统一服务提供认证平台和工具给消费者、运营、商家，同理，应用于日志服务和日志平台等。所以中台更偏向于技术架构的视角、平台则偏向于产品的视角，平台和中台是两个概念，平台包含了前台、中台、后台。

2.4、中台与 PaaS 的关系

PaaS 属于云部署的概念，从传统意义上看，云服务模式分为 IaaS、SaaS、PaaS 三类。

• SaaS 全称为 Software-as-a-service， 软件解决方案（Saas），意思是“软件即服务”。 在业内，SaaS 被 称为软件运营或简称软营。 SaaS 是一种基于互联网提供软件服务的应用模式。

• PaaS 全称是 Platform as a Service ，中文含义是 平台即服务

• IaaS 全称是 Infrastructure as a Service ，中文含义是 基础设施即服务

我们来看这张图

图片来源于《架构设计篇之云计算服务设计与决策》

如果从定位来看，中台大致上可以对应 PaaS，但中台又不能等同于 PaaS。因为讲中台的时候，其实并没有讲它是部署在云还是本地，如果部署在云上，其实就是 PaaS，如果部署在本地，在企业自己的机房上建立，就不叫 PaaS，而是叫中台。

三、云计算时代

Salesforces 于 2007 年推出了全球首个 PaaS 平台 Force.com，并在此平台上推出了 CRM SaaS 等企业云软件。摩根士丹利曾在 2018 年预计代表了 IaaS 模式的 AWS 市值 2700 亿美元，而作为全球 PaaS 及 SaaS 的鼻祖 Salesforces，目前已完成了第一阶段 IaaS 市场的竞争，PaaS 将成为其未来十年云计算产业竞争的焦点。同时，2020 年农历春节前，美国市场也盛传谷歌欲 2500 亿美元收购 Salesforce，无疑各种信号都表明了 PaaS 的战略意义，以及 PaaS 是未来企业中台战略的重要支撑。

3.1、PaaS 的舞台

3.1.1、什么是 PaaS

前面我们在 2.4 中简单的进行了中台与 PaaS 类比，如果本地部署则为中台，如果云部署模式则是 PaaS。

我们常说的 PaaS 是一种云部署服务模式，英文全称 Platform as a Service，平台即服务。通常的理解是把 SaaS 应用的开发和运行环境作为一种服务提供给开发者和企业的模式。相比于相对标准化的 IaaS（主要由服务器、存储和网络等硬件组成），PaaS 为纯软件服务层，主要涉及到数据服务、消息与通讯、缓存等传统本地 IT 模式下中间件的云服务化。

无论是 IaaS、PaaS、SaaS、私有云、公有云和混合云都是一系列的给用户交付的 IT 服务类型，统一称为云计算。

英国 FCA 金融行为监管局在 2016 年曾发布一个金融机构将 IT 系统外包给云服务商或第三方 IT 服务商的指南（更新于 2019 年 9 月）

3.1.2、PaaS 到 xPaaS

Gartner 对 PaaS 的定义是：PaaS 是将应用基础设施（中间件）能力通过云服务方式对外交付。

Gartner 追踪多种 PaaS 技术（xPaaS），包括 aPaaS（application PaaS 即面向应用开发的平台即服务）、iPaaS（integration PaaS 即面向基础设施整合的平台即服务）、apimPaaS（API management PaaS 即 API 管理平台即服务）、fPaaS（function PaaS 即函数平台即服务）、baPaaS（business analytics PaaS 即业务分析平台即服务）、IoT PaaS（物联网平台即服务）、dbPaaS（database PaaS 即数据库平台即服务）等。

虽然出现了 xPaaS，但是仅仅通过 PaaS 平台又很难盈利，比如我们上面提到的 SalesForces 虽然是作为 PaaS 和 SaaS 的鼻祖，但是从 2006 年-2017 年一直亏损状态，直到 2018 年，Salesforce 终于实现大幅盈利，其主要产品和商业模式是以 CRM SaaS 云为主要营收来源、以 PaaS 平台云为主要技术支撑。所以最终是 SaaS 业务拉动的 PaaS 平台带来盈利增长。

在中国的 PaaS 市场很难出现 SalesForces 这种公共云 PaaS 的独角兽，原因是大型互联网公司阿里、腾讯、百度、京东倾向于自建云服务，中小互联网公司则向大型互联网公司租赁云服务，这就导致纯技术型 PaaS 创业公司很难独立生存。

在中国，互联网之外的中国商业经济的主力大型国有企业、央企和民营企业也同样面临着技术能力、学习能力的差距。所以产生了所谓的 New PaaS 数字中台。

3.1.3、数字中台

数字中台，也可以称为 New PaaS in China，主要是针对大型国有企业、央企和民营企业，通过私有云为主、公共云为辅的部署，通过 PaaS 服务部署的方式对底层技术进行抽象和封装，暴露给上层用户友好和易用的技术方案，而不是像互联网公司那样直接使用底层技术。

阿里在实施中台战略以后，经过阿里云对外输出就是阿里云中间件产品 EDAS PaaS 平台。但是对于传统企业使用者来说依然具有学习和理解成本。针对该不友好问题，云徙科技走上探索如何批量化复制阿里中台的道路。在 2019 年推出数字中台 3.0 版本，包含业务中台和数据中台双中台方案，双中台之下是云原生研发管理平台，通过零代码和低代码方式帮助企业开发者更好地进行软件开发。

从 2020 年后的十年，正如阿里研究院安筱鹏博士在近期所表达的观点，未来是新型数字基础设施“安装”期，企业将重建商业基础设施和商业模式来满足未来客户的创新需求。

3.2、现代企业架构的深水区

在 3.1.3 小节中，我们提到了数字中台 3.0 版本，包含业务中台和数据中台双中台方案。其中现代企业架构面临的问题是当我们真正构建起中台，将每个前台业务的通用和共性业务下沉到中台，是否真正解决了企业的问题。

以我现有的一个系统 A 为例，是作为京东黄金流程(京东对搜推-商详页-结算页-订单的购买链路定义)链路上的逆向入口，也面临着所有的前台业务都会统一对接系统 A，经常会面临如下问题：

• 业务链路长，范围广，业务价值不好衡量

• 需求紧急重要、紧急支持需求成为日常

• 需求排期紧张、需求经常撕扯升级

• 团队人员忙碌、幸福指数不高

• 业务方众多、业务满意度不高

那么我们在开始的时候提到过中台建设帮助我们消除数据孤岛、消除重复建设，明明理想很美好，为何会出现上面的一系列问题呢？这里就是我们现代企业面临的架构深水区，也是非常多企业中台战略失败原因。这里面我们需要深度思考以下几个事情：

• 【统一认知-愿景战略】企业的愿景、中台建设愿景、以及各个事业群的相关干系人认知是否统一

为什么认知是非常重要的一个事情：原因在于大多数的产品经理和架构师更加关注的是系统级别或者单条业务线的系统改造，很少人能够达到高级管理或者 VP 级别的视野和思考高度。所以在落地的时候，无论是产品还是架构都会自主的带入业务线或者系统的浅意识。

• 【权衡共赢-各方长期和短期利益点】企业管理层与业务线关注点的结合点，也就是长期战略价值和短期战术价值的结合点。

无论小到一个业务团队，还是大到事业部或者公司，只要是涉及到利益那么一定会产生冲突，对于中台属于一个中立的角度和站位，那么是被业务牵着走还是有自己的独立发展计划？其实是需要权衡利弊掌握好程度的，不然很容易后续产生利益冲突。

• 【厘清边界-业务边界和价值】中台建设需要想清楚的一个问题也就是哪些是业务边界内，哪些是业务边界外，哪些是企业和业务的长期价值、哪些是企业和业务的短期价值，哪些应该做？哪些不应该做？

• 【分摊成本-中台的经验成本】对于中台团队面临的另外一个挑战就是费力不讨好，业务满意度不高，每个业务方都不愿意独立承担中台团队的成本。对于企业管理者和业务方都是不期望成本只有自己分摊，毕竟中台建设没有直接给业务方带来明显收益，反而是比较符合企业长远规划。所以这里面可以考虑一种投融资的方案，也就是比如京东会专门成立技术与数据中心作为中台部门，预算从企业战略资金储备中提供快速搭建中台架构体系，当具备一定成熟度的时候，根据前台业务接入业务体量进行成本分摊。

• 【考核结果-OKR&KPI 指标】中台架构体系建设以后，如何能够衡量考核其未来的发展需要定义严格指标，比如我们在 C 端面向用户的产品，可以通过用户留存率、活跃用户、用户转化率、用户购买率等来定义。作为中台架构产品面向多个业务方，如何以更好的方式考核和衡量呢？其实这里面可以从上面的问题出发，中台建设是在解决问题，当然引入的问题会有相对应的方案。比如阿里巴巴的中台考核就是设计成: 40% 稳定性 +25% 业务创新 +20% 服务接入量 +15% 客户满意度 。

从上面看企业面临的问题以及我们需要面临的挑战，其实都是企业架构(Enterprise Architecture)的问题。只是传统企业架构是基于现状的业务梳理和实现，考虑如何通过系统的构建来解决业务流程的信息化改造问题，而现在企业架构是考虑如何通过中台建设可以构建一个面向过去反思和总结、面向未来创新的问题。

在笔者构建自己的业务中台系统的时候，主要是做了统一认知、统一问题、统一方案三个统一。

从业务需求现状出发，明确我们要解决的需求重灾区，从中台的挑战出发，明确我们的问题域，针对过往现状需求认知统一，问题域。那么统一方案以后就可以正常按照轨迹对接了。在 ThoughtWorks 咨询方案中有个 D4 方法论，其实和三个统一理念一致。

3.2.1、数字中台 3.0 的双中台

现代企业架构面临的多条业务线、多个业务单元并行发展，当随着业务快速扩张期，自然而然 IT 建设会随着业务边界、组织边界，隔裂和加剧统一管控的困难。烟囱式系统重复建设也不难想象了。当企业业务增长缓慢，资源成本过高的问题凸显，那么如何降低资源成本和可持续发展创新就是一个非常有挑战的事情。

🤔思考：如何抽离多业务线共享的解决方案和能 力，集中管控和演进，以避免重复投资? 新业务如何基于企业已有的解决方案和 能力快速组装上线，以支撑业务快速迭代 创新?

3.2.1.1、数据中台

运行类场景

运行类场景以业务事务为主线，关注点在于业务事 务运作证据的完整性和一致性，以及确保各类数据 在各业务单元间高效、准确地传递，实现跨业务单 元的事务推进以及对于业务溯源的支撑 。

分析类场景

分析类场景则需要对内、外部数据进行收集和加工， 用来度量业务运行表现、尝试分析产生偏差的原因， 甚至结合机器学习等技术给出对于未来发展趋势预 测和判断，尝试构建数据驱动运营的企业组织。

从数据形成分析类价值，需要摄取 (Ingest)- 加工(Process)- 能力包装(Serve) 三大工序，可以进一步分为数据仓库、数据湖、 数据与 AI 平台、数据中台等构建模式。

准确的说，一定会形成自己的数据指标、并梳理现有数据和加工转化成数据能力，为业务赋能。

3.2.1.2、业务中台

2017 年 12 月 1 日，赖春波在 2017 全球软件开发技术峰会主会场上发表了《如何构建滴滴出行业务中台》的实践和探讨。以滴滴为例，滴滴出行在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。面临的四个问题：

• 重复性垂直化架构建设，无法做深，做专

• 高昂的人力成本，研发的薪酬高

• 用户体验不一致，同属一个系列的产品，却因不同团队造成用户体验不一致，流畅度、颜色、交易流程等不同

• 信息孤岛，同样的用户信息，需要企业通过多个 APP 进行重复获取新用户

在对业务和产品进行更好建模的基础上，进行“五化”：服务化、异步化、配置化、插件化、数据化。

3.2.1.2.1、服务化

结合微服务架构来将原单体架构应用拆分，从而开始进行相似性功能和模块聚合下沉。

3.2.1.2.2、异步化

拆解核心流程和非核心流程，将系统解藕降低复杂度。

3.2.1.2.3、配置化

解决业务差异性问题，通过配置化进行简单的功能处理和优化，避免了重复定制逻辑的开发。

3.2.1.2.4、插件化

通过插件的形式在每个系统加载它的插件，使其跟随业务思考、跟着产品思考让组织公共逻辑更加具备普适性。

3.2.1.2.5、数据化

数据化方面，需要注意三方面：

• 让数据更加规范和标准化。

• 构建完整的数据流，从在线到离线，从日志到模型的在线使用。

• 引入机器学习的算法、人工智能的算法去构建在线数据智能的决策

结合上面滴滴的业务中台的探索，其实滴滴已经较先寻求方法论来支撑业务中台的落地。而京东开启的 B-PaaS 之路也是基于上面的五化的另外一种形式，京东源于电商业务，在近几年逐步发展了海外业务、商业化业务，为了快速的扩张业务的同时也面临了独立部署海外站、商业化站，相同于上面说的滴滴快车、顺风车、货运、出租车、专车、代价等烟囱式架构林立。那么京东是如何做的业务中台建设探索和实践呢？京东的业务平台化 B-PaaS 之路。

3.2.1.3、中台建设经验

• 持续迭代，信心和持续创新的环境

• 团队组织错误-人越多效率越快

• 业务拆分不清（业务理解不透彻、业务梳理和系统规划不能满足实际需求）

• 微服务被滥用

“中台的建设过程虽然可以自下而上、由点及面，但驱动力一定是自上而下、从全局出发的，并且需要一定的顶层设计”

“企业级也是区分企业中台化与应用系统服务化的关键点，简而言之，中台化是企业级、全局视角的，微服务化更多是系统级、局部视角的。从组织架构模式的角度，“中台”突出的是规划控制和协调的能力，而“前台”强调的是创新和灵活多变。微服务不是越多越好，一定要根据实际的业务做相应的匹配，设置一个独立的业务单元，单独提供一个系统服务。”

摘录来自中台战略：中台建设与数字商业 陈新宇

• 系统过度设计

“软件架构的最基本规律是解决当前的需求和痛点，无法对没有出现的问题和痛点进行设计”

摘录来自 中台战略：中台建设与数字商业 陈新宇

3.2.2、业务平台化之 B-PaaS

在上面我们已经提到过 PaaS 化是中台建设的一种方式，基于基础组件搭建技术和数据中台后，业务系统也面临着同样的问题。这里强调的一个点是我们这里和后续说的业务中台是指的业务系统的中台能力建设。B-PaaS，在这里定义为 Businese Platform as a Service。用之前架构演变的图描述下 PaaS 的几个映射关系。

从上述图中大家会发现很容易联想到电商购物场景，那么这里面大家思考 2 个问题

1）商品详情页属于 B-PaaS 范围内么？

2）自营和 POP 商家他们都有自己操作的系统属于 B-PaaS 范围内么？

如果对于这两个问题没有直接答案，那么大家思考下，我们做的中台建设要解决的是什么问题？PaaS 是中台建设在云部署交付下的一种方案，B-PaaS 解决的问题和中台建设要解决的问题一致么？答案是肯定的，从开始到现在我们强调的目的都是一致的。所以现在回答上面的两个问题，商品详情页和自营和 POP 系统本身都不属于 B_PaaS 范围内，但是由于不同的海外站业务、商业化业务、子集团业务、垂直业务等差异导致系统逐步沉淀出通用的业务模式、业务流程可以复用不同的业务场景，逐步让自己有了通用能力划分到 B-PaaS 范围内。但是如果从真正意义上来说，业务中台应该是面向的全域业务场景的。所以到底属不属于 B-PaaS 范围内，要从是否能够通过业务中台建设复用的能力来考虑，如果没有该需求，那么就不涉及 B-PaaS 范围内了。