组件化业务模型（CBM）在企业架构和流程架构中的应用

前言

此前曾经写了两篇关于CBM《组件化业务模型》和业务组件的文章。本次全面总结CBM的各项内容和使用方法，并重点分析CBM方法在企业架构和流程架构之间的联系和区别，给出业务组件与流程的对应关系。

企业架构是企业的完整“逻辑蓝图”，定义了企业的结构和运作逻辑，使企业能够达到现在和未来的目标。国际开发组织（TOG）提出的架构标准——开放组织架构框架（TOGAF），给出了企业架构的开发方法和工作路径，定义了开发过程的制品类型，目前已经成为国际主流的企业架构开发理论知识体。

但是TOGAF作为通用的企业架构框架，只给出了框架性要求，并没有给出具体的架构开发方法。例如在TOGAF的业务架构开发过程中，只提到了以下七个步骤：

• 选择参考模型、视点和工具
• 开发基线业务架构
• 开发目标业务架构
• 进行差距分析
• 定义候选路线图构件
• 解决贯穿整个架构全景中的影响
• 进行正式的利益攸关者审查
• 最终确定业务架构
• 建立架构定义文档
  
  

在TOGAF核心的开发基线和目标业务架构这两个活动中，只给出了一些非常概要的要求：“必须完整, 但不需要的细节不用放；如果可能，最大限度地重用架构库构建块；如果不可能, 开发新架构”。

从TOGAF的描述可以看到，如何开发业务架构，还需要企业在开发过程中自行补充相关的方法和理论。

IBM公司充分参考了TOGAF的理论，总结了众多企业架构实施案例的经验，提出了一个既实用又易于理解的“企业总体架构框架”，包括按照战略-业务-IT等维度对企业全面地进行设计和规划。

图1 IBM的企业总体架构框架

从图1可以看出，IBM通过业务组件模型（Component Business Modeling，CBM）作为描述企业业务架构的核心方法，包括业务组件、业务流程、属地分布、资源获取（内、外包）、组织架构、绩效考核、企业管控等。

以下详细阐述CBM的理论和设计方法，在企业架构中的应用，以及CBM与流程架构的联系。

一、CBM的展现形式

CBM通过对企业的业务组件化建模，形成企业业务架构的顶层视图，在一张图上，直观显现出企业的业务蓝图。通过这种方式，将企业的各项业务活动重新分组到数量可管理的离散化、模块化和可重用的业务组件中，确定改进和创新机会，实现有组织的提供服务的能力。

CBM采用二维矩阵的方式（见图2）描述企业能力的顶层图像，明晰业务能力分布的映射网络。

图2 组件化业务模型（CBM）

CBM的横向是业务能力，即企业创造价值的能力。通过明确不同部门的业务功能、划分边界，确定关系，确保所有工作都有人在做，而且没有人做重复的工作。

CBM的纵向是职能层级，分为战略/引导层、管理/控制层、执行层。战略层主要指战略、总体方向和政策的业务，聚焦于明确战略发展方向，建立总体的方针政策，调配资源、管理和指导各个业务板块。管理层主要指企业的管理活动，如监控、管理例外情况和战术决策等业务，负责把战略落实到运营当中，监控和管理业务指标和企业员工，发挥看管资产和信息的作用。执行层是指具体的业务执行来实现的业务功能，处理业务请求和业务数据，注重作业效率和处理能力。处理各种资产和信息。

二、CBM的作用

CBM 提供了一个可以推广的框架，用来创造顺应组织战略的指导方向。企业也可以通过CBM实现专业化发展，实现柔性化运行，并建立和实现面向服务的架构（Service-Oriented Architecture，SOA），为实施 SOA 奠定基础。

1.实现专业化发展

专业化时代的到来，意味着任何一个公司，都不可能端到端的控制整个行业价值链，因此企业必须聚焦自己真正拥有绝对市场优势的领域。例如苹果聚焦于研发，把制造外包；再如滴滴聚焦于网约车平台，而不是自己拥有司机。

在这样的市场环境下，只有专业化，把企业的所有资源，都集中在能够为企业带来核心优势和利润的少数几个活动是，才能让企业为客户、员工和股东提供最大价值。

要想体现专业化，必须首先认识到企业应该聚焦的领域。组件，这一源于软件领域的概念就很好的引入企业管理中。

组件化的目的是为了识别并解耦具有独立价值的业务活动，通过业务组件之间的服务提供与使用建立彼此关联，以便于重新考虑业务的管理策略（如自主/外包/合作）；提高各个业务组件的专业化能力，保障战略调整的灵活性；同时促进组织内业务服务的复用性和扩展，提高资源共享与服务水平。

通过组件和业务模型，为企业的内外部提供了一种专业化验证的工具。

对外，可以外包自身无法满足或者附加价值较低的专业化功能，从而达到“让专业的人做专业的事，企业集中精力创造核心价值”的局面。对内，可以重新认识并最大化利用现有的资产和功能，消除非增值活动，整合重复的业务活动以降低损耗。

2.实现柔性化运行

传统的企业一般都分成了独立的功能性部门，无法看到跨部门的协作以提供客户价值。CBM用业务组件描述企业业务，能够概括描述企业整体业务及业务间相互关系。采用业务组件的方式描述企业业务，避免了采用流程较为复杂的方式。采用CBM分析企业业务方式见图3。

图3 采用CBM分析企业业务的方式

通过CBM对企业的业务进行建模，使企业原有的所有业务系统都下沉，不再有按业务部门建立的多个烟囱式的业务系统的概念，原有的业务系统变化为一个个提供业务组件和服务能力的能力单元。此外，原有的所有业务系统中的组织，人员，权限，流程引擎，安全等公共基础设施全部抽取，放到同一的平台进行管理，业务系统部再单独构建IT公共基础能力设施。

在这种情况下，对新业务系统的建设变化为一个个新的业务能力单元的建设，以后各个业务部门使用的不是孤立的业务系统，而是按需由业务能力单元组装成的可灵活配置的业务应用。不再有明确的业务系统的边界概念，而只有业务组件和能力组装的概念。从而更加快捷有效的调配企业资源，实现企业的柔性化管理。采用CBM对企业业务进行建模的作用见图4。

图4 采用CBM对企业业务进行建模示例

3.实现SOA管理

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过服务之间定义良好的接口和契约实现联系和交互。

业务组件化是在实施SOA需求分析和建模中常用的需求分析方法。CBM的业务组件将系统模块化和组件化的思路提前到了业务建模阶段。这样才能够更好的分析和识别业务服务，为后续的基于SOA服务提供业务目录清单。业务组件化可以很好的界定业务边界，边界清楚了才能够更好的识别交互和接口，通过交互和接口的识别来定义业务组件需要的能力，而这些能力转由SOA以服务方式提供。业务组件化的目的仍然是清晰的定义边界和交互，体现业务驱动IT的思路，使业务和IT之间能够平滑映射，如业务组件对应的实现中的服务组件，交互接口对应到服务实现等。

三、CBM设计方法

CBM通过横向业务能力和纵向能力层级对企业的所有业务进行矩阵式定义，但是CBM体现的是企业的业务能力专业化整合能力，其划分并没有固定的方法，同一个企业的CBM可能由于关注点不同而呈现完全不同的结果。业务能力的划分需要与企业价值链保持一致，但先后顺序没有绝对定义。业务组件在划分的时候属于哪个维度，业务组件在操作层面需要反应到什么细节程度，也没有绝对的定义。但是企业的业务在CBM中属于哪个职能层级，可以通过以下原则进行确定。

1.通过管理功能与管控权限来判别

按管理职能和管控权限的划分两个维度来确定。例如企业人力的备案属于执行层，而人力的审批属于管理层。详细判断原则见图5。管理功能的定义见图6。管控权限的定义见图7。

图5 通过管理职能和管控权限划分业务组件能力层级

图6 管理职能定义

图7 管理权限定义

2.通过业务活动类型来判别

任何一项业务最终都会落实到执行，但每个业务活动根据其不同的活动的类型，所担负的责任也有所不同。对于会产生3-5年的影响的战略活动、战略规划类活动、体系建设类活动应属于战略层级；对于识别类、过程监管类、制定制度或规则类、统计类、考核评价类应属于管理层级；围绕单一事项的任务执行活动应属于执行层级。

四、业务组件的定义和描述

CBM中每一个单独的业务模块叫做业务组件（Business Component，BC）业务组件是CBM的核心。二者关系见图8。

图8 CBM与BC的关系

业务组件的定义为：一个可以独立运行的构建企业的系统或功能模块。通俗来说，业务组件就是对达成特定目标，需要完成的一组紧密关联的工作事项的合集。通俗一点说，业务组件就是组成企业的乐高积木。但是不能有两块一模一样的，不能有相互包含关系的积木。

业务组件通过五个要素来描述（见图9）：

• 目标/用途：为什么存在，创造什么价值，如何衡量；
• 活动：定期执行的是哪些简单的、具有凝聚性的活动；
• 资源：需要哪些知识、资产和人力资源；
• 治理：活动和资源是如何管理的；
• 服务：从其他组件获得哪些内容，以及向其他组件提供了哪些内容。
  
  

图9 业务组件五要素

五、业务组件的典型特征

业务组件的典型特征，可以归纳为“高内聚、低耦合”。

所谓高内聚，就是业务组件具有独立、单一且具有明确边界，业务组件之间相互隔离，改变其一，接口不变，系统不受影响。高内聚的业务组件体现为企业内部具有“高凝聚力”的业务，将具有类似的员工、流程和技术的工作汇聚到一起。在这种情况下，这些业务组件能够形成统一的管理模式，并且具有高度的自主性，能够单独为其他业务提供服务，也能够外包。

低耦合，就是一方面业务组件能够独立提供服务，一方面也可以从其他业务组件获取服务，从而达到低耦合。注意，低耦合不是没有耦合，而是能够松散耦合。松散耦合代表着这种链接不是固定的，而是能够依据服务请求的不同，随时形成或者断开链接。只有建立在松散耦合的基础上，才能实现SOA的理念，依据不同的业务组件提供的服务，进行灵活组合，有的时候只要调整应用的界面层内容即可。而且只要我们需要，就可以把业务组件当成一个“黑盒子”，不在对组件内部的关系进行管控。

业务组件的高内聚，低耦合使得业务组件具备灵活、响应快、使用能力强的特点。业务组件内各活动的具有高凝聚力，可对外提供效率高、质量好的服务。业务组件之间不会因为其中一个变化而影响另一个也相应变化，从而提升企业的专业化、柔性化，并提供统一的服务。

六、业务组件的设计原则

业务组件是一系列不可分割的业务活动，那么如何设计业务组件呢？还是需要从业务组件的定义和特征着手，从业务组件是企业专业化的功能模块这个本质出发，从业务组件高内聚低耦合的特点出发，综合考虑以下因素：

• 业务组件由具有内在联系的一系列业务活动组成，这些相似的业务活动应具有通用的业务目标，使用类似的数据，使得业务组件成为单项业务能力的模型化描述；

• 业务组件是唯一的且不能重复，每个业务组件都应具有独立运作的能力的，为企业提供独特的服务；

• 每个业务组件都可以与外部组件通过服务进行合作，业务组件之间通过明确的接口调用关系实现业务交互；

• 每个业务组件执行都需要消耗一定的资源，企业通过共享通用的业务组件，提高资源使用效率，实现差异化竞争优势。

  
  

业务组件的划分需要深入了解业务之间的关系，并根据企业的战略、管理和执行各层面要求来进行归类划分。这需要有很好的业务分级分类能力，并考虑到业务间的数据流向和共享。

在理解业务组件“高内聚、低耦合”的特点基础上，业务组件的设计还要把握好组件的颗粒度。业务组件的颗粒度用于表示业务所包含的业务组件的大小，是一个组织的管理颗粒度的反映，是一种达成共识的范式。颗粒度过大，功能复杂，灵活性小，升级困难（可以独立升级往往会作为确定一个业务组件范围的重要因素），很难实现重用；颗粒度过小，业务组件数较多，造成业务组件之间交互增多，管理成本提升，性能低下。因此找到一个合适的业务组件粒度是很重要的事情。

首先要说明的是，业务组件的颗粒度没有硬性指导的原则，因为这不是一个硬性或可以测量的事物。一般来说，业务组件的颗粒度更多应从业务直接实现的业务目标层面去考虑，业务组件的精简代表管理能力的聚焦、灵活度的提高、复杂度的降低。我们可以从以下几个角度确定业务组件的颗粒度：

• 业务特点：不同的业务特点导致业务颗粒度不同，如行政管理，各业务事项相对独立，业务事项间松耦合特点明显，可能会业务组件较多；

• 抽象级别：不同的抽象层级导致业务颗粒度不同，如总部级的与部门级的；

• 避免陷入根据日常业务出现的频率、耗时、工作量等去评价颗粒度的大小。不能单纯的把现频率高，耗时多的业务定义为一级组件。应从该类业务实现的目的、价值去评估组件的大小；

• 对于总是固定配合的几个业务，且任何一个业务都不被此几项业务以外的其他业务调用，则建议此几项业务合并为一个组件。一个业务组件的输出必须为多个业务组件使用，如果一对一使用，代表该组件可合并。

  
  

七、业务组件的验证方法1.业务场景十字分析法

业务场景十字分析法（见图10）类比于软件测试的白盒测试，即通过“测试用例”（流程场景）来验证组件外部的流程和内部业务活动，验证组件的正确性。

对于业务组件的CBM图，首先相同业务域下的业务组件应能够串接，其次不同业务域下的组件间的交互关系，应体现在同一层次，即战略层面的不同业务域交互应都体现在战略层，管理层面的不同业务域的交互应都体现在管理层，执行层面不同业务域的交互应都体现在执行层，在交互过程中不应有斜线关系。

图10 业务场景十字交叉法

2.业务组件依赖性分析法

业务组件依赖性分析，类比于软件测试的黑盒测试，即不关心组件内部，而通过验证外部接口关系分析（组件的输入、输出、支持三方面）、验证组件正确性。

图11 业务组件依赖性分析图示

通过连接业务组件的输入输出，可以分析业务组件在职能层级上是否准确。一般来讲，战略、管理和执行层的业务组件在连接上具有图12的特点。

图12 业务组件不同职能层级特点

八、CBM和流程架构

CBM和流程架构存在着天然的联系。在IBM提出的企业总体架构方法论中，CBM和流程都是描述企业总体架构的不同视图。流程可以表示为业务组件相互协作、有序执行的活动。组件可以表示为众多具有同类特征的流程的集合。

流程是企业业务活动的内建特性，无论企业是否开展流程管理，流程都体现为“存在即合理”。CBM能够促使企业的流程整合为既能为组织发挥独特作用，又能作为单独实体运行的业务组件，将企业变成一个由不同业务模块组成的网络，每个模块中都包含一系列彼此关联的活动，并促使企业从单条的流程优化向流程整体优化发展，并最终形成整个企业层面上的全局优化的趋势。

图13 业务组件之间的协作组成了流程

CBM和流程架构也存在着明显的区别。

二者核心功能不同，CBM聚焦于业务块层面的业务设计和业务变革，目的是提高业务的专业化水平；而流程架构是描述业务构成，主要指导业务流程的梳理，提供结构性框架。

二者描述层面不同，CBM定义每个业务组件的五要素，包括价值、资源、需要的活动、业务治理、提供的业务服务；流程架构重点定义末级流程的要素，包括活动、岗位、表单、制度依据等。

CBM的核心目的是实现业务组件化，通过业务的模块化设计，为企业的应用架构、数据架构提供同样的模块化输入，实现企业架构设计的纵向传递和上下对准。企业通过CBM实现了业务组件化以后，还要详细分析业务组件的交互，而这个的基础就是业务流程交互。通过分析业务组件的交互，既能够为建立企业的业务流程体系提供输入，也能够通过分析业务组件之间传递的业务对象，为数据架构元数据模型定义提供指导。

CBM的设计需要按照流程的角度进行分析。一般情况下，流程是企业客观存在的，业务组件是需要提炼设计的。CBM需要通过流程分析识别和发现的业务活动，识别和抽象为相应的业务组件。所以CBM的设计首先应根据企业的业务能力提炼形成业务域，然后根据业务流程细化业务活动，通过对同类型的业务活动进行归集提炼，进而归纳CBM的职能层级，并最终形成CBM业务组件图。

CBM的应用也需要按照流程的角度进行分析。企业定义了CBM组件图以后，还没有细化到服务。但是业务组件化后，可以通过流程对业务组件之间的关系和交互进一步分析，确定为了完成一个完整的端到端流程业务组件之间必须存在的接口和数据的交互，而这些交互正是识别服务的关键点。业务组件不是孤立的而共同组装完成了流程的整合，而为了达到这个目的业务组件必须和暴露相应的服务能力，即我们说的组件本身的服务能力化。

通过上面的分析，我们可以得出，CBM和流程架构在业务域层是一致的，在业务活动层是重合的。如图14所示。

图14CBM和流程架构关系图

那么CBM中间的业务组件和流程架构的流程组是什么关系呢。

业务组件是企业业务功能的划分，并且为了实现专业化发展，针对不同的业务都采用面向对象的切分原则。例如针对战略规划业务能力（业务域），需要根据企业不同的规划对象，切分为企业整体战略规划、人力资源战略规划、科技发展战略规划、军民融合发展战略规划等。

流程是面向特定的业务目标，将输入转化为有价值输出的一系列相互关联的活动。流程组是流程的集合，可以采用面向对象的集成原则，也可以采用面向过程的集成原则。当流程组采用面向对象的原则时，和业务组件的划分一致，二者是相同的。当流程组采用面向过程的方式时，二者存在着多对多的关系。

仍以战略规划业务能力（业务域）为例，采用面向过程分解时，流程组可以划分为：战略分析、战略决策、战略规划制定、战略规划实施、战略规划调整等。

图15 业务组件与流程组对应关系

无论流程架构还是CBM，只要在划分时按照“高内聚低耦合”的特征，体现出清晰的业务逻辑与主线，满足MECE原则，这两者就能在形式上实现统一。

笔者较为推荐按照面向对象的方式切分不同的流程，这样可以把不同的流程归纳为业务模块，不仅能够基于流程的角度考虑业务的接口、角色、岗位、输入输出等因素，还能按照业务组件的方法考虑资源、治理、服务等因素，综合使用二种业务分析方法，推进企业的专业化和柔性化发展，对接应用架构和数据架构的设计和实施。

当然，有的流程不适宜采用面向对象的方式分类，那么采用面向过程的原则切分的流程组，因为流程组之间的接口联系较强，无法实现“低耦合”的特点，在与业务组件对应的时候，需要通过对流程组中的流程进一步分析，提炼共用流程及其活动，形成业务组件，实现业务组件和流程组的多对多的关系。

作者：焦志强

来源：架构与流程