最新业务笔记（业务组件BusinessComponent）

前期在《组件化业务模型（component business model, CBM）》（链接）中已经阐述了CBM对企业的专业化整合、柔性化运行、建设基于SOA的信息化系统等方面的作用。CBM由业务组件描述和构成，本文主要介绍业务组件的定义、作用、设计和验证方法。

一、业务组件的定义

业务组件（Business Component，BC）定义为：一个可以独立运行的构建企业的系统或功能模块。通俗来说，业务组件就是对达成特定目标，需要完成的一组紧密关联的工作事项的合集。

二、业务组件的作用

业务组件的作用，就是通过把企业功能组件化，从专业分工的角度构建企业业务能力网络，从而实现企业的专业化和柔性化。此部分内容已经在《组件化业务模型（component business model, CBM）》（链接）中阐述，本文不再赘述。

业务组件还可以提供后续的基于SOA服务目录清单，虽然在业务组件定义这一时期还没有细化到服务，但是业务组件化后，我们可以通过流程对业务组件之间的关系和交互进一步分析，确定为了完成一个完整的端到端流程业务组件之间必须存在的接口和数据的交互，而这些交互正是识别服务的关键点。业务组件不是孤立的而共同组装完成了流程的整合，而为了达到这个目的业务组件必须和暴露相应的服务能力，即我们说的组件本身的服务能力化。

三、业务组件的五要素

业务组件是组件化业务模型（CBM）的核心。二者关系见图1。

图1 CBM与BC的关系

业务组件包含五个要素（见图2）：

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

图2 业务组件五要素

三、业务组件的特点

业务组件具有如下特点：

1. 业务组件有自己的输入/输出，在企业中承担特定的职责，对外提供服务；
2. 业务组件是唯一的、不会重复的构造块，由一系列紧密关联的活动组成，可以单独运行；
3. 企业所有的业务活动只能归属于某一个组件，组件间通过调用服务的方式进行协同与交互；
4. 业务组件具有高内聚，低耦合的特点。所谓耦合，就是两个组件，其中一个变化将影响另一个也相应变化。所谓内聚，就是独立、单一且具有明确边界，业务组件之间相互隔离，改变其一，接口不变，系统不受影响。业务组件的高内聚，低耦合就是指业务组件之间通过低耦合方式进行链接，具备灵活、响应快、使用能力强的特点；其次，业务组件内各活动的具有高凝聚力，可对外提供效率高、质量好的服务。所以企业管理的目标就是降低业务耦合度（解耦），提升企业的内聚度（专业化）。耦合程度的分级可见图3。

图3 耦合程度的分级

四、业务组件的划分原则

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

1. 相似的业务活动；
2. 使用类似的数据；
3. 具有通用的处理流程；
4. 通用的业务目标；
5. 密切联系的组织单元通过组件共享，企业可以显著地改善运营效率并提高差异化竞争优势。

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

五、业务组件的颗粒度

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

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

1. 业务特点：不同的业务特点导致业务颗粒度不同，如行政管理，各业务事项相对独立，业务事项间松耦合特点明显，可能会业务组件较多；
2. 抽象级别：不同的抽象层级导致业务颗粒度不同，如总部级的与部门级的；
3. 避免陷入根据日常业务出现的频率、耗时、工作量等去评价颗粒度的大小。不能单纯的把现频率高，耗时多的业务定义为一级组件。应从该类业务实现的目的、价值去评估组件的大小；
4. 对于总是固定配合的几个业务，且任何一个业务都不被此几项业务以外的其他业务调用，则建议此几项业务合并为一个组件。一个业务组件的输出必须为多个业务组件使用，如果一对一使用，代表该组件可合并。

六、业务组件的验证方法

1. 业务场景十字分析法

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

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

图4 业务场景十字交叉法

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

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

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

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

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

,