CBM 由业务组件描述和组成。本文主要介绍业务组件的定义、功能、设计和验证方法。 1、业务组件的定义业务组件（BC）的定义是：构建一个企业能够独立运行的系统或功能模块。通俗地说，业务组件是为了实现特定目标而需要完成的密切相关的工作项的集合。 2、业务组件的作用业务组件的作用是将企业功能组件化，从专业分工的角度构建企业业务能力网络，从而实现企业的专业化和柔性化。这部分内容已在《组件化业务模型（component business model, CBM）》（链接）中进行了说明，本文不再重复。业务组件还可以提供后续的基于SOA的服务目录列表。虽然在业务组件定义期间服务还没有细化为服务，但是当业务组件形成之后，我们可以通过流程进一步分析业务组件之间的关系和交互。确定业务组件之间必须存在的接口和数据交互，以完成完整的端到端流程，而这些交互是识别服务的关键点。业务组件不是孤立的，而是组装在一起完成流程集成。为了实现这个目标，业务组件必须暴露相应的服务能力，也就是我们所说的组件本身的服务能力。 3、业务组件五要素业务组件是组件化业务模型（CBM）的核心。两者的关系如图1所示。

业务组件包含五个要素（见图2）： 1. 目标/目的：为什么存在、创造什么价值以及如何衡量它； 2. 活动：定期进行哪些简单、有凝聚力的活动； 3. 资源：需要哪些知识、资产和人力资源； 4. 治理：如何管理活动和资源； 5. 服务：从其他组件获取什么以及向其他组件提供什么。

4. 业务组件的特点业务组件具有以下特点： 1. 业务组件有自己的输入/输出，在企业内承担特定的职责，并对外提供服务； 2. 业务组件是独特且不可重复的构建块。它由一系列密切相关的活动组成，可以独立运行； 3、企业的所有业务活动只能属于某个组件，组件之间通过调用服务进行协作和交互； 4、业务组件具有高内聚、低耦合的特点。所谓耦合是指两个组件。其中一项的变化会影响另一项的相应变化。所谓凝聚力，就是独立、单一、界限清晰。业务组件彼此隔离。如果更改其中一项，界面保持不变，不影响系统。业务组件高内聚低耦合是指业务组件通过低耦合方式联系起来，具有灵活、响应快、可用性强的特点；其次，业务组件内部的活动具有较高的凝聚力，能够对外提供效率高、优质的服务。因此，企业管理的目标是降低业务耦合（解耦），提高企业凝聚力（专业化）。耦合度分级见图3。

5、业务组件划分原则业务组件是一系列不可分割的业务活动，那么业务组件如何划分呢？还是要从业务组件的定义和特点出发，从业务组件是企业专门的功能模块的本质出发，从业务组件高内聚、低耦合的特点出发，然后综合考虑以下几点因素： 1. 类似的商业活动； 2、使用相似数据； 3、有通用的加工工序； 4、共同的经营目标； 5.密切相关的组织单元共享组件，企业可以显着提高运营效率，增强差异化竞争优势。业务组件的划分需要深入了解业务之间的关系，根据企业战略、管理和执行的要求进行分类和划分。这就需要有良好的业务分类能力，并考虑业务之间的数据流动和共享。 6、业务组件的粒度业务组件的粒度用于表示业务所包含的业务组件的大小。它是组织管理粒度的体现，也是达成共识的方式。粒度过大，功能复杂，灵活性低，升级困难（独立升级能力往往是决定业务组件范围的重要因素），难以实现复用；粒度太小，业务组件数量较多，导致业务组件之间交互增多，导致管理成本增加，性能变差。因此，找到合适的业务组件粒度非常重要。首先要注意的是，对于业务组件的粒度，没有硬性且快速的指导方针，因为它不是一件困难或可衡量的事情。一般来说，业务组件的粒度应该更多地从业务直接实现的业务目标层面来考虑。业务组件的精简代表了管理能力、灵活性的提高和复杂性的降低的重点。我们可以从以下几个角度来确定业务组件的粒度： 1、业务特性：不同的业务特性导致不同的业务粒度，比如行政管理，各个业务事项相对独立，业务事项之间的松耦合明显，这使得可能会导致业务问题。组件有很多； 2、抽象层次：不同的抽象层次导致不同的业务粒度，比如总部级、部门级； 3、避免陷入根据日常业务的频率、耗时、工作量等大小来评估粒度的陷阱。发生频繁、耗时较长的业务不能简单地定义为一级组件。组件的大小应根据此类业务的目的和价值进行评估； 4、对于几个始终相互配合的业务，并且任一业务不被除这些业务之外的其他业务调用的情况，建议将这些业务合并为一个组件。一个业务组件的输出必须被多个业务组件使用。如果一对一使用，则意味着组件可以合并。七、业务组件的验证方法1、业务场景交叉分析方法业务场景交叉分析方法（见图4）类似于软件测试的白盒测试，即通过“测试用例”（流程场景）来验证组件的外部流程和组件。内部业务活动验证组件的正确性。对于业务组件的CBM图，首先同一业务域下的业务组件应该能够串联。其次，不同业务域下组件之间的交互关系应该体现在同一层面，即战略层面不同业务域的交互应该体现在战略层面和管理层面不同业务域的交互体现在管理层，执行层不同业务域的交互也应该体现在执行层。交互过程中不应该存在斜线关系。

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

通过连接业务组件的输入和输出，可以分析业务组件在功能层面是否准确。总体而言，战略、管理和执行层面的业务组件在连通性方面具有图6的特征。

往期亮点： 企业建模理论与方法架构建模的十三条基本原则数字化转型的六大关键成功因素如何设计业务架构从“0”到“1”，让大象敏捷系统设计一些原则利用企业架构战略关系模型让组织的战略目标从“口号”变成“干货” TOGAF9.2升级要点架构应用实践入门——数字化组织（企业）建模思路企业架构业务-应用的建模流程-正向设计方法数据技术架构