第三章 业务中台建设

第三章 业务中台建设

3.1 什么事业务中台

从业务运行机制和系统开发机制两个维度，展开产生建设业务中台的主要内容。

3.1.1 业务中台定义

==业务中台是以业务领域划分边界，形成高内聚、低耦合的面向业务领域的能力中心，打造持续演进的企业级业务能力共享服务平台。业务中台的直观呈现就是各能力中心，常见的有交易中心、商品中心、库存中心等==.它不仅提供丰富的共享服务，还包含体系建设企业能能力域的方法和机制。业务中台不仅是生产上层应用的开发设计平台，也是配置、编排、和扩展业务对象、业务能力、业务规则及业务流程，完成企业资源运营管理的平台。他为上层应用系统的稳定运行提供了高并发、高可用的执行环境。

• 1.微服务不是业务中台
  • 微服务是当今比较流行的一种技术架构，而业务中台的内涵不仅仅是技术架构，还是一种组织层面的业务架构。
  • 首先中台作为技术架构体现出来的是本书着重介绍的中台系统，但从广义上讲，它还跨越式一种企业组织管理模式和理念。中台是在“集中”的基础上建设隔离分权的前台业务，并将这些业务进行联通。
  • 其次，业务中台结合了系统论整体规划的思想，将系统按纵、横两个方向进行拆分。它吸收了微服务“按业务领域”的纵向拆分应用方法，形成“高内聚、低耦合”的能力中心；
  • 再在纵向拆分的基础上，横向将业务中台与业务应用进行隔离，造就了中台的共享理念，使其超脱了微服务的范畴。
  • 中台内部纵向拆分服务，降低了领域间的耦合度。中台与上层应用横向隔离，促进了业务和数据在各应用间的交叉共享，大大减少了重复建设和重复投资，由此，也造就了可持续沉淀积累和运行的企业资产，中台因此成为企业数智化转型的新基建
  • 因此微服务不是业务中台，但微服务与业务中台并不是截然分开的，微服务是在技术层面建设业务中台能力中心的最佳实践。
• 2.业务中台不是前台应用
  • 前台应用包含两大部分：前台交互界面和前台应用服务
  • 前台应用服务是指前台交互界面提供后端服务接口的功能单元集合
  • 业务中台一般不直接面向前台界面，而是面向前台应用服务，为其提供共享的服务接口
  • 前台应用服务提供的功能具有应用局限性和特殊性，它一般是完成某一个特定业务场景所需的功能
  • 相比而言，业务中台完成的则是多个业务场景的通用部分，以及挂载和执行面向特定前台业务的扩展功能
  • 通常来说，前台应用服务会根据前台业务场景的特殊需要，将中台能力进行编排、转换后再提供给前台界面使用。
• 3.业务中台是通用业务机制的实现
  • 业务中台共享服务域前台应用服务的一个重要区别是，业务中台实现的是业务场景通用部分的功能
  • 这部分通用功能是结合不同前台业务，通过抽象所形成的通用业务运行机制，解决的是前台业务共性的问题。
  • 这种通用的业务运行机制是业务中台的核心内容之一。
  • 中台专注于通用机制的抽象和实现，所以中台才具有通用性和包容性。中台再结合可动态修改的配置项，以及可即时扩展的插件，通过业务空间的隔离，解决了业务个性化问题，即以一套通用的机制同时支撑不同业务，从而进一步保证了中台的开放性。
  • 业务中台主要就是以这两点来支撑不断变化的业务场景，并确保自己不会品牌反的被推倒重建

3.1.2 业务中台主要建设内容

业务中台专注于通用业务运行机制和系统开放机制的实现。在此，我们将业务运行机制拆分为业务四要素：业务对象，业务能力，业务规则和业务流程，并将系统开放机制拆分为业务配置和业务隔离。

1.业务对象

业务对象包括实体对象和过程对象。实体对象是指具体的企业资源、产品和服务，例如店铺、用户、客户、组织机构、价格政策等一切有形或无形的资源。过程对象主要是指企业在经营活动中对业务动作进行的描述。比如“订单”是对交易活动的描述，“结算单”是对多方利益关系体分利润过程的描述，他们都是过程对象。

2.业务能力

业务能力是同类业务功能的抽象实现，是对业务对象的操作。业务能力可以改变业务对象的状态，并通过结合业务规则来操作相关的业务数据。一个能力可以支持多个功能。能力的基础hi结构和算法。能力是系统内生机制的体现。在不同的业务场景下，业务能力可以间接表现为不同的应用功能。比如商家入驻能力，即可以对应商家自主注册的功能，又可以对应电商平台后台主动开通商家账号的功能。

3.业务规则

业务规则就是业务逻辑，是用来控制或影响业务能力的定义或者约束的描述。中台将业务规则与业务能力独立开来，单独实现。业务规则影响了各能力中心所提供的能力和业务数据的聚合、转换、变化。比如，“商品创建能力你”搭配“商品需要审核”的业务规则，就会产生“商品创建后，商品牌进入待审核状态，需要审核通过后才能发布”的情况。

4.业务流程

业务流程规定了业务中台系列业务动作执行的顺序，用以完成特定的业务目的。中台针对不同业务需要设计不同的业务引擎，比如交易引擎处理交易相关的 逻辑，促销引擎负责促销活动相关的自动化，审批流程引擎负责业务单据的审批。业务引擎和流程定义决定了能力中心内部以及能力中心之间如何自动化执行。比如通过可自定义的交易流程，业务系统既可实现先付款后发货，有可实现先发货后付款。这种面对实际场景需要多变的业务不是通过修改代码，而是通过调整业务流程来实现的，从而让中台达到随需而变。

5.业务配置

业务配置是内嵌在中台业务逻辑中的一些控制点和扩展点。通过可视化的配置视图，用户可以动态控制中台的执行逻辑，让业务柔性运行。比如用户身份认证扩展点，可以配置用户在下单时是否需要认证。如果进行认证，是选用滑块认证、人脸认证还是其他认证方式，从而动态控制下单场景中的业务执行。

6.业务隔离

业务中台作为共享服务，需要支撑多个前台应用。在共享的基础上，需要隔离前台应用，让前台应用即可执行个性化逻辑，又避免互相干扰，各自独立运营发展。比如，当任何一个前台应用增加功能或者修改执行逻辑时，我们只需要对该前台应用进行整体回归测试，而不需要对其他前台应用进行回归测试。

3.2 业务中台的架构设计和组成

对于企业而言，要开展业务中台建设，首先需要进行顶层架构设计。==业务中台的核心架构是纵向切分、横向分层的架构风格。==中台在纵向维度进行领域划分，形成中台的能力中心；同时在横向维度，根据业务领域与上层应用的关联性，将业务中台领域进行分层。明确了能力中心的层次依赖关系，我们可针对不同层次的能力中心，采取不同策略进行设计及建设。在确定了业务中台核心架构的基础上，我们再从软件工程角度出发，进一步介绍业务中台在设计态、管理态、运行态三大阶段的关键特征，以指导业务中台的架构设计落地。

3.2.1 业务中台的核心架构

企业业务中台建设是一个系统化工程。中台有自己的架构体系。那么中台的主要架构风格是怎么用的呢？总结起来就是纵向切分，横向封层。
纵向切分是指，中台将企业的业务内容，按照不同领域，以及能否独立运营为标准，进行纵向切割。对切割后的大小各异的、算不上严谨的多个业务领域，中台从技术上再进行一系列的分析、抽象、归类、推演，形成在业务上能独立运营、技术上含有多个微服务的系统。切分之后的各个系统，我们一般称为中台的能力中心。如常见的会员中心、营销中心、交易中心、库存中心、消息中心、认证中心、流程中心、调度中心等。 每个能力中心都支撑着不同的业务领域，他内部所有的领域对象均与业务领域有直接的聚合关系。
横向分层是指需要建立在纵向切分的基础上。对于不同的业务领域，中台会根据其管理对象的不同性质，从下向上拆分为业务实体层、业务协作层、业务活动层。

注意，这里所说的“横向分层”强调的是业务中台内部，而3.1.1节提到的“横向隔离”，指的是整个IT系统层面的横向隔离，也就是将中台与前台应用隔离。

• 业务实体层（Biz Entity Layer， BEL）：由管理企业静态资源的能力中心构成，局于三层模型的底部，比如商品、会员、用户等。
• 业务协作层（Biz CollaBoration Layer，BCL）：由对企业资源使用策略进行管理的能力中心构成，居于三层模型的中间，起到承上启下的作用，比如营销政策中心、价格政策中心。
• 业务活动层（Biz Activity Layer，BAL）：由管理或实现企业核心业务活动的能力中心构成，居于三层模型的顶部，可实时调用下方两层的业务能力，完成业务活动的执行，不如交易中心、结算中心。

通过横向分层，中台就确立了不同层次能力中心之间的依赖关系和数据流向关系。

3.2.2 业务中台体系内容

从软件系统工程的角度看，完整的中台体系由设计态、管理态、运行态三个阶段组成。

1.设计态

设计态的业务中台提供组件平台和能力平台。组建平台的作用是快速搭建应用，能力平台的作用是统一管理和使用中台能力。
组件平台可完成前后端组件的注册、发布及接入指引。这里的组件包括技术类组件和业务类组件两大类。技术类组件封装了通用的技术能力；业务组件不仅封装了特定的业务逻辑，也封装了对中台能力的调用。组件平台为业务应用端到端的建设，从创建应用、描述数据模型到组装页面，提供了组件素材，加快了应用的搭建。
能力平台提供能力的注册、发布及接入指引。通过能力平台，中台系统的使用者（包括中台能力使用方、中台能力提供方和中台机制设计方）不仅可以统一直管的查看中台具备的能力域能力详情，还能汇总统计能力的调用情况等。能力地图即是能力平台的一个体现。

2.管理态

管理态的中台应包括需求管理、进度管理、质量管理、项目管理、配置管理等多个方面。因为中台建设是由多人多角色共同协作完成，所以需要通过统一的管理平台从中协作推进。我们一般把这些软件生产过程中通用的需求管理、进度管理、质量管理等放在技术平台的研发服务平台上实现，详见5.2.2.在中台的建设的推进的过程中，建设方还需要加强对各阶段产出物的评审，并通过对评审结果的记录，实现上线内容的追溯。

3.运行态

运行态的中台包括能力配置、能力编排、能力执行三个方面。可配置和可编排的能力需要统一上报，形成全局的控制中心，即中台控制平台（MPC）。MPC完成对业务能力的管理和配置，然后通过执行平面实现能力的执行，在结合运营平面（BOC），三个平台共同配合，达到对中台运行内容的柔性控制。

3.3 业务中台构建策略

围绕核心架构和体系，业务中台应该按照怎样的方式进行构建？
构建业务中台的具体策略：领域驱动、需求结构化和能力可配置。首先，我们通过领域驱动，从整体上划分业务中台的领域，进而划分出业务中台的具体能力中心；其次，对具体的领域进行细化。在这里我们会使用需求结构化和能力可配置两种策略，最终形成易用、灵活的业务能力中心。

3.3.1 领域驱动设计

业务中台的构建，首先需要进行整体规划。对企业而言，中台所涉及的内外部系统交错复杂，而领域驱动设计（Domain-Driven Design，DDD）是厘清这些错综复杂系统的一种实践战略。借鉴领域驱动设计，我们可以梳理业务应用系统所涉及的各角色的旅程地图，包括运营者、消费者、客服、导购等，然后根据用户旅程地图所涉及的业务对象或实体，剥离差异性，抽取共性，最终形成共享的服务能力。
领域驱动设计最早是有Eric Evans提出的，目的是对软件所涉及的领域进行建模，以应对系统规模过大时引起的软件复杂性问题。以领域驱动构建业务中台的过程可以分为战略和战术两大阶段。

1.战略阶段

业务中台建设的战略阶段的核心目的是划分问题域，确定核心领域，整理出限界上下文。领域 按照类型可划分为核心领域、支撑子域、通用子域。实现业务愿景和价值的主要系统功能及时核心域，用来支撑核心域的子域称为支撑子域，而相对通用的则称为通用子域。限界上下文为领域提供上下文语境，确保领域内的术语在其特定的边界范围内具有一个没有二义性的含义。领域驱动的业务中台建设过程中，首先从业务维度出发，开发者与领域专家使用通用语言进行信息的沟通及确定，梳理出业务关键的核心域及支撑核心领域的子域。在过程中，也会浮现一些通用系统需求及出于技术维度方面考虑的场景，就形成了通用子域。
在领域划分的基础上，我们将中台所涉及的业务领域划分为管理、登录认证、消息发送、数据字典等通用功能，可以形成==通用能力域==。而针对客户互动相关的场景（如消费者浏览商品并下单购买，消费者享受会员权益），所涉及的商品中心、交易中心、库存中心、会员中心、营销中心等促进商业行为的领域，可以形成业务中台的==商业能力域==。通用能力域主要关注基础性能力，为商业能力域提供基础支持；而商业能力域主要关注各类商业领域能力，以进一步支撑前台业务的多样化场景。

与传统DDD不太一样的是，我们不太强调支撑子域。这是因为中台是企业应用的共享服务平台，他将支撑各色各样的业务应用。从不同的业务应用角度区分核心域和支撑子域是有意义的。但从业务中台的角度，就没太大必要分出建设过程中，还是会区分核心域和支撑子域，因为业务中台建设是由业务应用驱动的。

2.战术阶段

在将系统划分为多个能力中心后，中台建设就进入战术阶段。在战术阶段，针对已确定的能力中心，中台要进行具体领域设计。在此阶段，我们会更关注领域内部的要素。我们一般使用领域模型来表达领域知识。常见的领域模型包括实体、值对象、领域服务、领域事件和聚合等。
以交易上下文为例，建如下图，

在该限界上下文中，关键核心为交易（Transaction）。交易体现的不只是一个订单，还体现了一个交易动作。一个交易会产生很多种单据，如交易订单（TradeOrder）、支付订单（PayOrder）、发货订单（DeliveryOrder）等。一个交易订单会由一条或多条订单商品信息（OrderItem）组成。这些单据包含对应的单据ID、状态及其他实体属性，塔里木就是限界上下文实体。交易上下文中，所有实体、值对象都围绕着交易，而外部需要访问交易上下文，必须从交易开始，所以交易可视作一个交易上下文的聚合根。但一个消费者下单后，首先会常见交易实体，在创建该聚合根实体的过程中，还需要创建对应的多种单据。为了完整构建、初始化交易实体，我们可以通过工厂（TransactionFactory）来封装具体的创建逻辑。
每个实体均会涉及状态的改变，而这种状态改变的工作可以触发一个领域事件。领域事件一般是“名词+动词过去式”。消费者下单后将产生一个订单已创建（OrderCreated）的领域事件。对于交易订单实体而言，创建订单属于实体的能力。而下单过程中，需要扣减库存（DeductStock），该动作在交易上下文中涉及了其他上下文的领域对象，所以可以通过领域服务进行协调，进而保证不同上下文的一致性。
综上，在领域驱动设计的过程中，我们通过战略、战术两个阶段，从宏观上整体划分领域边界，将业务中台划分为通用能力域及商业能力域，进而针对每个能力中心，不断细化领域对象，形成丰富的领域对象模型，将领域能力构建成具体业务中心的能力。

3.基于事件风暴的DDD

不过，对于如何可操作地实时DDD，业务有很多不同的探索，其中时间风暴（Event Storming）是一种即经济又高效而且充满乐趣的方法，也被证明是一种可以快速探索复杂业务领域的方法。
时间风暴是一种战术阶段的设计方法，它自下而上地从微观的领域事件推演出战略宏观的领域模型。它被业界戏称为“糊墙”，因为它会在一个房间的四面墙上湖满便利贴。它几乎没有学习曲线，唯一稍微有点高的要求是要有一间足够大的房间，并且有足够多的不同颜色的便利贴。他的核心是协同共创，要求领域专家、业务架构师与技术人员以协同的方式迭代地探索构建出领域模型。
事件风暴的理论基础来自领域事件。如果一个系统能够支持一项业务，那么当该业务开展时，角色在业务上的操作就会导致系统的响应，从而留下一些足迹。这些足迹往往以数据的形式存在于某个地方。留下这种足迹的系统的响应就是领域事件。通过对领域事件足迹的追踪可以推测当时的业务操作。如果把领域事件按照时间排序，就能在时间线上还原一些列业务行为，从而推导出系统所需的能力，并通过技术性的手段转化为系统的空间结构。而系统的空间结构就是系统的领域模型。 上图素食的是一个对商城中同城配送需求进行事件风暴后得到的领域事件流。首先，事件风暴的展开是基于业务场景的。在这个需求中，领域专家识别出了店铺创建、同城配送配置、商品选购、订单确认、接单、配送几个业务场景。然后展开每个业务场景，从左到右识别出该场景下的领域事件，以及触发该事件的命令和角色。这些事件的后续建模工作的战术层输入，基于他们就可以逐步推演出领域模型。
经过事件风暴，即可以发现与通用模型的重叠之处，也可以找出差异点。如此，我们不仅最大程度复用了中台现有能力，也通过增加差异点持续扩展了中台的能力。
对于如何构建基于事件风暴构建业务中台领域模型，可参考下图所示流程。

1. 业务架构师与领域专家主导，带领团队按照业务场景识别领域事件、命令和角色，并按照时间排序。
2. 业务架构师与领域专家带领团队，基于战术层的业务场景与事件流提炼子域。对于中台来说，可以认为子域是能力中心。但这个时候，能力中心还处于问题域空间，没有任何解决方案。
3. 技术人员带领团队基于事件流提取业务元素，识别实体、值对象及聚合。
4. 技术人员再次带领团队，跨越到战略层，识别出限界上下文及其映射与集成的关系，并验证是否有足够的能力解决能力中心的问题。这个时候，能力中心的问题有限界上下文解决，业务中台架构终于从问题过渡到了解决方案。

3.3.2 需求结构化

业务中台的核心价值在于能力的共享。中台能力使用方在接触业务中台时面临的首要问题是：如何了解业务中台有哪些能力？这些能力与实际业务场景的匹配程度如何？因此，业务中台的构建首先需要考虑业务能力的呈现方式。我们以业务场景、业务能力、业务配置的层次来结构化地表达业务需求。需求结构化体现的是一种结构化思维，即在面对需求问题时，采用一种层次结构将需求进行拆解。在中台能力结构化展现时，想要了解中台所提供的的能力，一般是通过API列表，而且只局限于开发人员，因为业务人员不易理解API列表。但是，需求结构化不仅让我们更易于了解业务中台的共享能力，还扩大了受众人群。
需求结构化，一般可以从两个维度来体现。

1. 能力地图。从领域、场景、能力的结构化层次，可视化地体现需求场景和流程中的每个节点。如此一来，中台能力使用方可基于原始需求快速匹配可用的业务领域、场景及能力。而对于不存在的业务场景，能力使用方则形成当前需求的场景能力开发项。
2. 配置视图。在同一领域，不同的业务场景会导致不同的业务规则。通过配置视图、中台能力使用方可以查看业务中台已有的业务规则，与当前的业务场景规则建匹配。若规则已存在但与当前所需的规则策略不匹配，则形成规则的扩展实现开发项；如规则为当前业务场景特有，则可以形成定制实现开发项。

综上，通过能力地图、配置地图，我们能够将业务场景、业务规则以系统结构层次的方式串联起来。按照需求结构化方式，针对具体需求，我们首先会整理出需使用的场景、能力、配置，并在现有的系统上梳理出需要新增的开发场景、能力、规则，形成最终需求需要开发和配置的条目。
业务中台不是一蹴而就的。需要结构化的方式一方面可以让中台使用方便易于应用共享能力，验证业务能力；另一方面也能不但沉淀更多的业务能力、业务规则配置及扩展项。这也是业务中台不断自我演进的方式。

3.3.3 能力可配置

因为业务能力之间存在差异性，所以业务规则也不全相同。比如，同样都是下单能力，对普通商品而言，下单动作只需校验基础商品、库存的有效性；但对于热门抢购商品而言，在基础校验完成后，下单前系统还可以增加商品限购的校验。根据不同的使用场景，商品限购校验也会存在多种限购规则和策略，如会员等级限购、会员预约限购等。由此可见，不同场景下同一个下单能力所涉及的业务规则并不完全相同。因此，业务中台作为能力共享的平台，如何针对不同的业务场景、业务对象（如商品、店铺）进行不同业务规则的配置以及配置的隔离，就是是一个必须解决的问题。
中台在实现通用业务规则的基础上，将其针对不同业务场景的可变部分提取出来，作为业务的可配置项，并对这些可配置项进行统一管理，就形成了中台能力可配置的特性。业务配置项一般分两种类型：

1. 业务参数
2. 业务扩展点。业务扩展定义了中台统一业务逻辑与业务个性化实现的一个接口契约。只要遵照该契约，根据业务需要，我们就可以随时扩展不同的业务规则逻辑。这也是业务中台所需的另一个很重要的特性---动态化扩展。

业务中台的建设过程是一个不断整理、实现配置项的过程。通过不断丰富业务中台的可配置化能力，不断打磨业务能力，让业务中台成为支撑前端业务快速创新的利器。

3.4 业务中台构建五步法

业务中台构建五步法是指导我们建设中台的方法论，具体步骤为：业务规划-》领域分析-》中心设计-》中台实现-》业务运营。其中，领域分析的过程非常关键，是业务中台区别于以往传统IT系统建设的环节。
业务中台建设五步法3.0如下图：

3.4.1 高阶规划

高阶规划包括宏观业务规划和宏观技术规划，是一个提纲挈领的过程。
宏观业务规划，就是分析企业的核心业务场景，解剖企业整体及局部存在的问题与痛点，从宏观上规划处业务蓝图及业务解决方案，是一个顶层设计的过程。宏观业务规划无需深入每个具体业务场景。
宏观技术规划，就是通过对核心业务场景、宏观业务蓝图的理解和分析爱，推导出宏观的业务领域与业务中心，然后以此为基础，设计出宏观的0级架构的过程。宏观技术规划也会输出各中心需要提供的主要业务能力。0级架构是一个宏观的应用架构，解决的是如何拆解系统才能承接和支撑业务蓝图的问题。它包括能力中心、应用以及需要集成的三方系统及其相互关系。另外，0级架构还需要体现分层的职责、层间关系以及层内各组成部分的关系。0级架构不仅为中心、应用、三方系统划定了边界，也框定了中台代码工程的创建，还为后续的中台设计工作指明了方向。除0级架构外，宏观技术规划还需要明确系统的设计原则，以指导团队在中台建设过程中思想保持一致。
高阶规划的产物，特别是0级架构，需要进行充分讨论和评审。良好的0级架构需要清洗的描绘出中台包含的内容和组成结构，并应在系统复杂度、建设经济成本、可扩展等方面达成较好的评审。

3.4.2 领域分析

领域分析包含如下三部分：

1. 业务场景梳理：根据高阶规划时所划分的业务领域，梳理出各领域的业务场景。结合场景存在的痛点，规划未来的系统功能，进一步设计出对应的系统原型。
2. 领域模型推倒：首先根据各领域的场景清单，采用事件风暴来梳理和总结出领域模型清单。再根据领域事件，抽象和归纳出领域模型，包括领域活动、领域事件、领域对象、领域规则等。然后以领域模型为基础，按照模型之间的聚合关系，推导出业务子领域最后分析各子领域的职责与整体目标的相互关系，我们就能推导出能力中心。

场景清单-》领域模型清单-》领域模型-》业务子领域-》能力中心 3. 高阶规划调整：推导出能力中心之后，需要与高阶规划阶段预设的能力中心进行比较，再根据需要对规划的内容以及0级架构进行调整。

3.4.3 中心设计

中心设计包括组件规划、1级架构设计、中心概要设计。 组件规划是指明确根据领域模型规划处的能力中心由哪些业务组件组成。业务组件是业务逻辑的封装单位，包含一个或多个能力，一般用于完成一个具体的业务任务，并可被多个业务场景所复用。业务组件按照逻辑关系聚合为能力中心，能力中心又可以根据逻辑关系分为BAL、BCL、BEL三个层。这样就形成了业务中台内“横纵有序、解耦合理”的立体架构。
如果说0级架构是中台的骨架，那么1级架构就是中台的血液。骨架的作用是稳定和支撑，而血液则需要在身体各部分流动才能维持好各项机能的正常运作。1级架构聚焦的是在具体业务场景下，各中心、各应用如何各司其职、承载所属的数据和业务逻辑，即通过具体业务场景，将各中心的能力和领域事件串联起来。在串联的过程中，我们有可能会发现0级架构缺失的能力，甚至需要调整0级架构各中心的领域模型分布。1级架构是从0级架构设计到落地开发的关键桥梁，也是中心概要设计的指导方针。
中心概要设计是是从系统设计到开发交付的过渡阶段。通过设计数据库概念模型、功能包结构、核心时序图、接口设计等，为中心的详细设计与开发奠定基础。

3.4.4 开发交付

开发交付是将0级架构及具体场景下的1级架构落实到代码，并实现为可运行系统的过程。开发交付包括中心详细设计、测试用例设计等详细内容的设计输出以及代码开发、持续交付等。中心详细设计包含数据物理模型设计、具体能力的时序图、类图等。这里需要注意，数据库模型并不等于领域模型。
开发交付是一项复杂的工程，需要依托一套对设计态、管理态、运行态统一进行管理的技术平台，才能顺利完成。（参考第五章）另外，在使用技术平台的过程中，开发团队也要不断吸收先进内容，如管理思想、开源技术、快捷工具等，这样不仅可以更好地帮助团队快速成长，也可以推动技术平台的沉淀和演进。
整个开发交付过程需在技术自治的思想指导下展开，包括迭代规划、需求返讲、持续集成等，并辅之以日清日结的过程管控。日清，帮助团队发现问题；日结，及时总结经验教训。通过总结回顾，先进有效的措施得以发扬，不足和错误则可被及时制止，保证开发活动有效推进。

3.4.5 持续运营

中台需要持续运营才能不断沉淀和发展。持续运营包含以下4个方面：

1. 业务运营
2. 内容运营
3. 技术运营
4. 数据运营

3.5 业务中台与其他系统的集成

企业应用与中台存在额关系：

1. 在中台上新建应用，即用新建应用替换原有应用
2. 部分改造原有应用，将其与中台对接，即使用技术平台提供的工具，从原有应用中剥离出由中台提供的部分，接入中台，比如接入中台的用户、会员、订单。
3. 企业应用可能是稳态的应用，也可能是当前中台建设阶段所未涉及的应用。中台需要借助这些应用已有的功能或数据，集成这些应用。
4. 除此之外，企业还有外部的上下游、外部平台等系统间的对接要求。因此，中台需要提供合适的集成机制，以“衔接过去，联通未来”。

3.5.1 业务驱动集成

中台建设过程中的应用集成是由业务驱动的，但集成的范围却与企业推动中台建设的阶段、中台与其他系统的边界相关。而且，随着中台建设的发展，中台所能支撑的领域逐渐扩张，原有集成边界将会发生改变，甚至完全接替现有被集成的系统的功能。

1.外部平台服务

• 第三方支付
• 物流
• 认证
• 短信
• 社交分享
• 电子发票
• 电商平台

2.企业内部系统

• ERP
• dms
• crm
• os

3.5.2 集成策略

需要考虑三个原则：

• 耦合性：在不依赖外部系统或在模拟接口的情况下，业务中台中的业务场景能形成完整的流程。需要设计松耦合的架构，来确保业务中台的独立性和完整性。
• 侵入性：业务中台在与其他系统进行集成时，需要抽象出一套标准接口，统一实现外部系统的对接，以减少对业务中台功能代码的改动。
• 可靠性：系统集成的过程中，需要保证无论斯业务中台还是其他系统出现故障，都有完善的容错和重试机制，确保系统回复整车后业务能够继续开展。

综上，为了保证业务中台的业务独立性、降低对外部系统的依赖、提高集成的效率和系统的容错性，我们需要设计一个中台连接器，来统一实现和管控与第三方系统的对接。参考下图。

引入中台连接器可很好的解决如下几个问题：

1. 中台连接器能够隔离业务中台与外部系统，避免外部系统的复杂影响业务中台本身的纯粹性。
2. 由中台连接器进行数据统一适配转换，解决各系统数据不一致问题，降低数据维护成本。
3. 当数据有错漏时，中台连接器可以进行数据重试。连接器提供默认的重试机制，并且可以手动批量调整数据状态进行重放。
4. 当中台和各系统对接数据场景不一致时，中台连接器备有预留扩展。如果遇到不满足的业务场景，重新开发新的适配器即可。

常见的集成方式如下：

1. 接口调用
2. 消息队列
3. 文件传输
4. 共享数据库

强调，业务中台与其他系统的集成并不是只能选择以上集成方式中的一种，而是需要从业务出发，全面地考虑集成的范围、模式、策略、代价等因素，根据对接的系统选择合适的方式。

3.6 业务与数据的联动

业务中台与数据中台各自独立，却又相辅相成。业务中台支撑实时在线业务，并产生业务数据；数据中台则通过汇聚整合、提纯加工、建模处理、算法学习，将数据转为数据资产，并以共享服务的方式提供给业务使用，从而与业务联动，并再次产生新的数据。

从数据角度看，业务中台通过能力的输出，获取了大量的业务数据。这些实时的运维数据是数据中台非常重要的数据来源之一。而且，因为这些数据是实时的，所以就减少了数据中台模型加工的时间延迟。与此同时，数据中台通过模型加工处理的数据结果，可直接推送给业务中台，丰富业务中台的业务内容。比如，数据中台加工精产生的客户标签，推送给业务中台后，业务中台就可以展现综合的客户画像，为营销和服务提供高效率和高质量的服务。

从业务协作角度看，业务中台在支撑业务时，需要数据中台提供的数据服务来对业务能力进行调整。数据中台提供的在线数据服务可以帮助业务能力更有针对性和精准度的执行。比如营销互动场景下，业务中台的交易能力可以结合数据中台的任务画像服务，完成千人千面的差异化推介。

从系统管理角度来看，业务中台在建设同一业务中心的同时，也起到了统一管理数据源的作用。这位数据中台的数据治理打下了业务、数据统一的基础，并为数据中台提供了高质量的数据。另外，业务中台对业务对象的元数据定义完全可以为数据中台所用，减少数据中台的重复定义、重复管理的工作量。

最终，业务中台和数据中台一起，构建数据“生产-消费-再生”的闭环，双轮驱动企业的数智化转型。