文：戴敏

南天信息金融科技首席架构师

前面文章提到数字化转型需要支撑企业“混沌边缘”产生的各类创新，成功的数字化转型战略往往能够兼顾处于“秩序”状态下保障企业稳定性的业务，和处于“混沌”状态下不断涌现的创新。体现在落地实施中，会有敏态、稳态两类业务，至于相应的数字化系统、服务是否分两类进行建设，取决于企业的战略规划和路线图，需要结合资金、时间成本等因素综合考虑。

数字化转型的落地实施中可以通过数字化技术范畴内对技术体系、框架、设计思想、开发语言、工具等的众多规划和决策，缓解焦油坑的影响，也可以通过高明的商业、市场决策为从焦油坑中挣脱赢得时间，但避免焦油坑的关键，还是在于推进数字化时代的业务组件化。

在系列文章的第三部分，我们会讨论数字化时代，什么是业务组件化以及业务组件化主要包含的内容。在分布式、去中心化的技术浪潮背景下讨论的业务组件化与以往有很大的不同，对此本文不做展开，后续可以有单独的文章讨论分析。

一、数字化转型的成功标准

不同于数字化技术应用的初期，今天数字化转型的成功标准已经发生了变化，即成功的度量标准的变化，最直接的一类体现是绩效指标的改变。对于业务的成功度量标准，从以往的面向内部的投资回报率转变为对外部的客户价值的关注。对于技术的成功度量标准从对成本与效率的关注，转变为对速度与适应性的关注。

达成数字化转型成功标准所面临的技术挑战是：信息化转型及Digitization型数字化虽然在一定时期内构建了以简化、高结构化、自动化业务流程为目标的应用系统，但随着新业务流程在这些遗留应用系统上的不断叠加，不但迭代周期越来越长，原来的应用程序也越来越分散、碎片化、重叠，难以按照原来的设计进行组合、创新，并且在以组合、重用为主的产品、功能、API建设或重构中引发了大量的焦油坑。

数字化转型按照核心内容的不同可以大致分为Digital的数字化转型、Digitization的数字化转型两类。Digitization的数字化转型聚焦实现围绕流程的运营效率和质量的提升。Digital的数字化转型聚焦实现企业的新价值主张，如互联网企业依托流量优势进行创新，响应客户的新使用体验和长尾客户的交易诉求，围绕“平台经济”的新价值主张，构建平台生态提供高效的互联网产品和服务。一般而言，Digital以Digitization为基础或包含Digitization的建设，不同行业、业务领域的企业有不同的IT基础，会有不同的数字化实施路径。相比较而言，业务敏捷性组件基础设施对于Digital数字化转型的作用要大于对Digitization数字化转型的作用，因为Digital致力于业务敏捷性的深层次变革。

二、业务敏捷性组件基础设施

在系列文章的第二部分，我们曾经提到业务敏捷性组件基础设施帮助我们避开数字化转型焦油坑，快速、弹性地响应产品、运营、市场的需求，实现业务产品、服务的快速调整和完善。

业务敏捷性组件基础设施包括面向业务敏捷性的业务组件及其支撑组件，其核心在业务组件化。相关的支撑组件系支撑业务组件实现体系化和系统性的一系列技术组件，这部分组件的设计和实现相对容易，可以结合各个企业多年信息化过程中的积累，落地在适合的企业级架构中。支撑组件不属于本系列文章讨论的重点，不在此展开，本文主要针对业务组件部分进行分析和阐述。

数字化转型在实施中都会涉及新建数字化系统、服务或对原有系统、服务进行迭代。由于服务化的深入，“系统”的边界可能会越来越模糊，未来可能会只有服务平台，表现为“平台/控制面+框架+服务”。数字化转型的业务敏捷性的代价之一，是由众多独立业务单元相互组合、协同而构成的业务产品、服务网络的复杂性显著增加。建设业务敏捷性组件基础设施除了可以帮助应对数字化转型焦油坑，还可以帮助降低这类复杂性的边际成本。

三、业务组件化

本质上，业务组件化的过程就是企业在数字化转型过程中为了应对数字化系统、应用系统的复杂性及其组合的复杂性问题，尝试将企业的业务运营组件化的过程，可以看作是是业务建模的一种实践。

1、业务组件化的驱动因素：

不同的业务部门可以在过程中开发/提供更专业化的、更高级的单个组件，这些组件组合起来可以帮助业务部门交付更复杂的产品和服务。另外，因为能将影响控制在一个或几个组件的小范围内，业务组件化能更好地应用新技术和新方法，帮助控制转型实施风险。

2、业务组件的典型特性

离散、不重叠。每个业务组件都有离散、不重叠的特性，天然支持容器化和运营重用。在以往的实施中，业务功能通常以硬连接（固定连接）的方式与特定的系统自动化处理流程关联起来，但业务组件化可以提供离散的、专业化的业务单元，包括内聚的业务、数据逻辑和对外提供的业务行为、动作，在任何适用的业务环境中都可以进行重用，提供了较高程度的业务（运营）能力的重用。

自治。每个业务组件都体现为自治的，会伴随着业务实践和技术的发展以相对小的影响不断进行迭代、增强、自发展。

可替换性。业务组件的可替换性，体现了其较强的生命力。在数字化服务生态链中，企业自身及服务商依托业务组件，可以将单个业务组件进行切出（业务服务链）、替换，不论这个替换是技术层面上的更新还是业务产品、服务上的重构。

在实践中，企业为业务组件建设统一的业务组件框架，规范业务组件规划、设计、实现中关键业务内容的一致性和运营质量，例如明确构建块（Building Block）的标准。

数字化转型中落地业务组件化以实践中成功验证的DDD（Domain-driven design, 领域驱动设计）、微服务架构设计思想为支撑，也继承了业务中台热潮中对业务单元化的思考和实践。这里暂不展开业务组件化与其他新兴技术的结合，因为业务组件化+容器的应用架构可以轻松地与其他主流的数字化技术结合。

（关于业务单元：在组件化设计的专题文章中讨论。在本文中可以简单理解为业务单元是独立的，具有清晰的业务产品和服务概念或内涵的，有明确边界、上下文的业务对象为中心构建，这些不同的业务对象的组合、继承可以支撑新的业务产品和服务）

3、业务组件体系

业务组件体系有不同的落地实现方式，大多需要从业务战略规划开始做起。以下为集合实践和相关建模理论的一种参考落地方案，方案围绕企业产品、服务的运营抽象出相应的业务能力、业务领域、服务域、API，以这些要素为中心从上至下进行分解、设计至可进行开发的组件和相应的支撑框架、规范等，共同构成业务组件体系：

•    要素1：业务能力（BC）

业务能力也包括多个层级，上层的业务能力由下层业务能力组成/支撑。每个业务能力都反映了从能力角度看，产品、服务的某种经营能力的要求，这种能力的设计需要业务部门回到业务本质的角度，针对产品、服务的运营能力进行分析、分解、抽象，目标在于其可重用性。对于抽象出的不同业务能力会有不同的复用率，对于复用率较低的业务能力也需要抽象出来，以达到对企业业务的全覆盖。对企业中BC的抽象是为了实现单个运营能力在企业内部的重用，通过BC的重用改善业务经营效能，使企业得以将人员、资金投入到更有价值的地方，如资源利用率的改进和提升。

业务能力的划分通过多个层级逐级分解、全面覆盖。例如业务能力可以划分为产品及相应的服务支持、营销和销售、客户及相关的分销、企业级支持能力、企业管理及控制相关能力等。每个上级BC可以再细分出多个下级BC。以银行为例，产品及相应的服务支持的业务能力下，可以分解为协议管理、财务计划及管理、抵押品管理、金融工具管理、设备管理、资金转移管理、订单管理、支付管理、产品管理、贸易融资管理、信托管理等下级业务能力。

•    要素2：业务领域（BD）

在完成业务能力的分析、设计后，从业务运营角度将企业的业务分解为一些相对粗粒度的、相互不重叠的业务领域。从组成上来看，业务领域应该是对企业业务的完全穷尽。业务领域是非原子性的业务运营单元，一个业务领域最终将分解为多个服务域（原子性的业务运营单元）。业务领域的分析、设计属于领域建模范畴的工作，由于视角的不同，业务领域与业务能力的映射关系非一一对应关系，最终所有业务领域能覆盖所有的业务能力。

不同的企业可以有不同的建模实践，一个业务领域可以再次分解为多个业务领域，如果需要也可以有不止2层级的业务领域。

•    要素3：服务域（SD）

服务域体现了对最细粒度的业务运营单元的封装，实施中从业务对象角度进行设计。服务域针对某种类型的业务对象实现控制和处理，它封装了对应业务的信息和逻辑，通过服务域的组合即可支撑业务的运营。服务域划分与传统的面向流程的业务运营设计理念不同，面向流程的设计中将运营的处理逻辑划分为步骤，基于特定的流程将不同步骤端到端地紧密链接在一起。而服务域提供的是以业务实体而非业务流程为中心的业务对象处理的复用。服务域处理所封装的业务对象及其相关业务行为的全生命周期，其以业务对象为中心进行抽象、设计，它是离散、自治、松耦合的，不同的服务域是可组合关系。服务域的组合设计也不同于面向流程的设计（组合的主体不同），服务域组合的执行顺序是不固定的，依据不同的业务场景、业务事件处理可以有不同的组合顺序，服务域的组合也可以设计为并行处理的方式。

落实到IT建设中，服务域以业务对象为中心，设计、实现应用API，其天然支持合适的业务数据及其处理的封装。基于这种与业务敏捷性潜在契合度较高的IT封装解决了很多传统的集中业务处理系统中的业务、IT的弹性问题（此处的“集中”包括系统服务的集中、业务数据的集中【做非业务维度的数据分片，例如hash sharding等，或做流程、步骤维度的数据分片，本质上也属于业务数据的集中】）。从技术角度，从业务领域分解而来代表原子性业务运营单元的服务域，更适宜SOA、微服务、分布式架构、云、Service Mesh等弹性技术、设计思想的应用。

从数据架构的角度，以服务域为基础设计、实现的API，也更有可能满足业务、技术弹性系统的数据分布、自治、封装、组合要求。

以银行为例，典型的服务域如信用卡、信用卡运营日志（全生命周期）、（公司）现金归集、公司往来账户、（个人）代理产品、（个人）销售产品、（个人）信托服务、公司贷款、贷款、定期存款、消费贷款、委托订单、储蓄账户等。非典型的服务域如信贷风险运营、信用卡交易网络参与方、（市场交易）适用性检查、企业融资、客户行为洞察、潜在客户活动、客户活动、折扣定价、产品部署、产品组合等。

•    要素4：API

API是组成业务组件体系的另一个要素，与前面的业务组件体系中其他要素不同，API最终可体现为直观的IT成果，而其他要素更多体现为规划、设计成果。在业务领域的设计中会包括相应的服务操作，这些服务操作的集合即是相应的API。每个服务域下可设计一个或多个可对外提供服务的API。API的具体实现方式可以多种多样，只要能支撑服务域的组合，完成相应的业务行为处理即可。

API的实现应该注意：避免实现技术对API的破坏性修改、维护API的技术无关性、消费方易于使用、不暴露API内部的实现细节等。从选择业务组件化最合适的技术架构角度，可以考虑将API设计为REST(表述性状态转移)架构风格。REST架构风格重要的优势在于保障了互操作性和高效性，非常适合业务组件体系这样的环境。REST架构风格有对资源的标准方法，HTTP的标准动词正好契合这些方法，通常业务组件体系直接使用HTTP服务请求的协议。业务组件的实现不建议基于RPC（远程过程调用）实现，具体分析请关注后续文章。

对于本文讨论的抽象、封装，从模型角度，DeFi（去中心化金融）即可视为一种较好的实践，DeFi生态的各种服务是一种不错的体现，通过繁多的跨链技术实现的跨链服务从模型角度来看是一种不错的封装、隔离、松耦合，尽管这种隔离主要的出发点是数字经济在特定环境、背景下的一种封闭式解决方案。

在下一篇文章中，我们将讨论基于本系列文章中提到的业务组件化如何开展落地工作以及其中的关注点，欢迎继续关注。