|
业务中台是企业数字化转型的重要平台和基础。业务中台是企业能力共享平台，前台可以基于中台能力快速搭建新的应用、推出新的产品和服务、快速响应业务需求。 中台可以作为一种企业组织管理模式和理念（Middle Office），也可以作为一种新的企业IT架构（Middle Platform）。从技术系统层面看，中台是企业级共享服务平台。业务中台是从多个相似的前台业务应用共享的需求中产生的。业务中台本质上是一个体系或系统，它实现了企业核心的业务运行机制，因而处于企业运行生态的核心位置，所有应用系统都必须与之建立联系。业务能力输出的内容主要是核心业务数据和业务流程，这是中台存在的本质。 业务中台围绕以交易为核心关联的领域组成。典型的业务中台由多个业务服务中心组成。下图就是阿里的业务中台，包括用户中心、商品中心、交易中心、评价中心、店铺中心、搜索中心、营销中心等。中心是一个独立的体系，它能够独立运营，支撑多个业务场景。同时，它也是中台能力的物理载体，既提供了中台能力的编码实现，又在运行时生成一个物理进程承载多个中台能力。中台建设过程中，要把握和前台的边界。中台既要满足业务的需求，但又不能过度参与业务。中台提供的能力要具有灵活性和可定制性。便于业务方根据规范自主完成，减少沟通成本，提升效率。中台所沉淀的共享服务能力并不要求支撑所有前台业务，只要有多于一个前台业务需要某一种能力，此能力即可沉淀为中台能力，因此不能大而全地建设中台。中台的建设是可以分阶段逐步实施的，无需将所有重构全部一起推动。第二步是企业级架构设计，包括业务中心划分和应用架构、技术架构设计、数据流向等。 第三步是1级架构设计，包括产品设计、组件建模、系统设计。 第四步是分步实施中台。 第五步是持续进行中台运营，包括业务运营、内容运营、技术运营和数据运营等。 在业务抽象阶段，通过业务调研和业务分析，设计业务蓝图和抽象业务元素，为下一阶段的中心建模阶段准备顶层思想和业务素材。这一阶段，根据企业不同的实际情况，可轻可重。比如企业已经做过咨询调研和流程梳理工作了，那就可以在以往工作成果基础上进行短期的业务理解和业务设计工作了。如果企业对以往的咨询工作并不满意或者上一次咨询时间久远，竞争环境发生了巨大的变化，这就需要做仔细完整的业务咨询了。这里的调研分析不同于传统的系统调研。我们更加强调的是，以面向中心的思想来探讨业务，认为业务流程只是形式，核心是各领域中心的结构和运行机制。各中心的设计需要满足业务流程的需要，但是这不是核心目的。我们主张在业务调研过程中进行领域模型的探讨，反复思考逐步清晰业务领域的边界。在业务调研结束后，结合行业趋势、类似项目的比较以及自身的经验，输出企业的商业模式和核心业务场景。业务场景包括企业级业务场景、部门级业务场景和操作级业务场景。并在业务场景梳理过程中，找出企业痛点。最终设计出企业TO-BE的业务蓝图和应用蓝图。通过顶层业务分析，明确了总体方向后，我们便可以展开对具体业务场景的梳理和抽象，并输出功能需求清单。在此过程中，还需要定义出功能操作的原子业务对象或业务实体。原子业务对象包括原子业务实体、原子业务活动和原子业务规则。基于业务实体，结合对应的功能需求，定义出需要系统提供的能力。根据能力的主题和实体间的密切关系，我们便能对实体进行归类，定义出主题域。首先，我们梳理出企业功能需求。如某饮料企业的功能需求汇总表如下图所示。其次，找出每一个功能需求所对应的业务对象或实体。这一步需要剥离功能的差异性，抽象功能的共同点，才能保证定义合理。实体分为两类：业务实体（静态实体）和过程实体。实体性质相同或者实体结构相似度较高，都可归纳为同一实体。在实体基础上，为了满足当前功能需求，我们需要定义出系统所需提供的能力。能力就是对实体施加的操作或发出的命令，这里的能力我们称为领域能力。最后，根据能力的主题、实体的密切关系，定义出主题域（也可以称为“业务域”）。业务域的命名一般由资深业务架构师来定义，以避免出现二义性。基于功能需求的抽象，输出的产物见下表。经过业务的调研和分析，技术架构师理解并熟悉了业务。基于上阶段输出的主题域，技术架构师按照中心的多个划分标准，进行中心的规划。这里使用的是实体抽象法。中心规划时要遵循业务中台的分层模型。业务中台从下向上可拆分为业务实体层、业务协作层和业务活动层，如下图所示。以上分层结构不仅定义了业务中台的结构，也定义了数据流向、服务依赖关系、单次事务的调用次数等。我们可以基于此定义中台的开发规范。1）业务实体层（BusinessEntity Layer，BEL）：由对静态业务实体进行管理的中心所构成，也就是我们分析的企业静态资源管理。静态资源包括通用业务对象，比如省地市、元数据，还包括商品、会员、用户等。2）业务协作层（BusinessCollaboration Layer，BCL）：由以完成或管理支撑类业务活动为目标的中心所构成，比如促销中心、评价中心等。本层的中心并不一定是业务活动不可或缺的部分（或者说主流程的一部分），但是没有这些支撑类的业务中心，我们的服务和业务水平就不能更上一层楼。3）业务活动层（BusinessActivity Layer，BAL）：由以完成或管理核心类业务活动为目标的中心所构成，比如交易中心、供应中心、物流中心等。本层的中心都是企业业务活动必不可少的部分，它们为业务活动提供了核心运行机制。中台的内部层级关系确定下来后，接下来就需要确定层级间的依赖关系了。层级间的依赖，其实就是不同类型中心的调用关系和异步数据流动关系。划分出多个主题域后，技术架构师需要结合技术的实现，将领域进行组合规划出中心。中心的划分标准主要从实体的聚合度、中心的职责、中心颗粒度、能否独立运营等方面来权衡。确定中心的过程也就是划定功能边界的过程。下图是某企业的中心划分结果。业务中台的0级架构本质上是应用架构，它以中心为最小单位进行设计，因此也称为整体架构设计。0级架构包括了功能层级的架构和技术层级的架构。功能层级的架构需要描述业务中台在整个数字平台中所处的位置，业务中台由哪些中心组成，以及中心与应用、中心与后台的交互关系。功能层级的0级架构承接了企业的应用蓝图规划，指导企业各IT系统的职责划分和定位。技术层级的0级架构需要说明各系统、各中心分别使用什么技术来实现，以及整个体系的技术分层。如下图所示，技术架构总体上分为展现层、服务层、接口系统、运营管理和运维支撑。
为了简化业务流程，根据前期的业务分析，结合0级架构的设计，我们可规划出企业的业务数据流（以房屋租赁行业为例，多业态），如下图所示。产品设计是在业务顶层设计的指导下，逐层往下抽象的过程，主要是将业务调研的成果转化为产品原型和需求规格说明书（主要由业务场景、业务流程构成）。需要强调的是：中台产品的详细设计需要以面向中心为指导思想。不仅需要设计出应用需要实现的功能，更重要的是要将需要中心支撑的功能明确标识出来，归到中心的待实现列表里。这样技术工程师在领域建模阶段才有具体和明确的输入。组件模型设计承接0级架构设计，是对中心内容的展开。通过对中心功能的分析和对中心业务实体的抽象，将具有较强依赖关系的业务实体聚合为一个组件，或者将具有相同主题的业务功能聚合为一个业务组件。最后以结构化的形式聚合这些组件，构成中心。 组件是可以独立为微服务的，只要符合微服务的条件，就可以独立，但在具体实践中需要进行权衡。组件模型设计完成后，需要将模型转化为应用架构。这里的应用架构是指中心内部的应用架构，我们称为1级架构。1级架构是以组件为最小单位设计的功能层级的架构。1级的功能架构是必不可少的，它指导着我们的设计和开发；技术层级的1级架构可视情况而定，如果技术内容比较复杂则需要输出。下图为某企业功能层级的交易中心1级架构。前面已经完成了0级和1级的架构设计，有什么方法能证明设计是否可以满足实际业务场景的需要吗？我们可以通过实现业务场景的动态交互图，来反向论证设计的合理性。如何判断动态交互图是否合理呢？根据业务逻辑是否清晰、流程是否简洁、客户交互是否高效来判断。<END>
|
