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

1、 组件化业务模型（CBM）在企业流程架构中的应用目 录 TOC o 1-3 h z u HYPERLINK l _Toc21947020 前言 PAGEREF _Toc21947020 h 4 HYPERLINK l _Toc21947021 一、CBM的展现形式 PAGEREF _Toc21947021 h 6 HYPERLINK l _Toc21947022 二、CBM的作用 PAGEREF _Toc21947022 h 7 HYPERLINK l _Toc21947023 1.实现专业化发展 PAGEREF _Toc21947023 h 7 HYPERLINK l _Toc2194702

2、4 2.实现柔性化运行 PAGEREF _Toc21947024 h 8 HYPERLINK l _Toc21947025 3.实现SOA管理 PAGEREF _Toc21947025 h 10 HYPERLINK l _Toc21947026 三、CBM设计方法 PAGEREF _Toc21947026 h 11 HYPERLINK l _Toc21947027 1.通过管理功能与管控权限来判别 PAGEREF _Toc21947027 h 11 HYPERLINK l _Toc21947028 2.通过业务活动类型来判别 PAGEREF _Toc21947028 h 12 HYPERLIN

3、K l _Toc21947029 四、业务组件的定义和描述 PAGEREF _Toc21947029 h 13 HYPERLINK l _Toc21947030 五、业务组件的典型特征 PAGEREF _Toc21947030 h 14 HYPERLINK l _Toc21947031 六、业务组件的设计原则 PAGEREF _Toc21947031 h 15 HYPERLINK l _Toc21947032 七、业务组件的验证方法 PAGEREF _Toc21947032 h 17 HYPERLINK l _Toc21947033 1.业务场景十字分析法 PAGEREF _Toc219470

4、33 h 17 HYPERLINK l _Toc21947034 2.业务组件依赖性分析法 PAGEREF _Toc21947034 h 18 HYPERLINK l _Toc21947035 八、CBM和流程架构 PAGEREF _Toc21947035 h 19前言此前曾经写了两篇关于CBM HYPERLINK /s?_biz=MzA4MTI0MzIyNw=&mid=2247483704&idx=1&sn=d1fbe5d38d5e1a18a818d461fc13f7e4&chksm=9f96bc0ca8e1351a843870b4c5ec9dfb8b8fce234042293108d28b

5、3f31629d8bbed347e5232c&scene=21 l wechat_redirect t _blank 组件化业务模型和 HYPERLINK /s?_biz=MzA4MTI0MzIyNw=&mid=2247483714&idx=1&sn=d86170cd88b7e88950935dc7c1e7a755&chksm=9f96bc76a8e13560fd787ed533706f444e800284494bc7fac025546f32aea1cc02498fa9fa79&scene=21 l wechat_redirect t _blank 业务组件的文章。本次全面总结CBM的各项内容

6、和使用方法，并重点分析CBM方法在企业架构和流程架构之间的联系和区别，给出业务组件与流程的对应关系。企业架构是企业的完整“逻辑蓝图”，定义了企业的结构和运作逻辑，使企业能够达到现在和未来的目标。国际开发组织（TOG）提出的架构标准开放组织架构框架（TOGAF），给出了企业架构的开发方法和工作路径，定义了开发过程的制品类型，目前已经成为国际主流的企业架构开发理论知识体。但是TOGAF作为通用的企业架构框架，只给出了框架性要求，并没有给出具体的架构开发方法。例如在TOGAF的业务架构开发过程中，只提到了以下七个步骤：选择参考模型、视点和工具开发基线业务架构开发目标业务架构进行差距分析定义候选路线图

7、构件解决贯穿整个架构全景中的影响进行正式的利益攸关者审查最终确定业务架构建立架构定义文档在TOGAF核心的开发基线和目标业务架构这两个活动中，只给出了一些非常概要的要求：“必须完整, 但不需要的细节不用放；如果可能，最大限度地重用架构库构建块；如果不可能, 开发新架构”。从TOGAF的描述可以看到，如何开发业务架构，还需要企业在开发过程中自行补充相关的方法和理论。IBM公司充分参考了TOGAF的理论，总结了众多企业架构实施案例的经验，提出了一个既实用又易于理解的“企业总体架构框架”，包括按照战略-业务-IT等维度对企业全面地进行设计和规划。图1 IBM的企业总体架构框架从图1可以看出，IBM通

8、过业务组件模型（Component Business Modeling，CBM）作为描述企业业务架构的核心方法，包括业务组件、业务流程、属地分布、资源获取（内、外包）、组织架构、绩效考核、企业管控等。以下详细阐述CBM的理论和设计方法，在企业架构中的应用，以及CBM与流程架构的联系。一、CBM的展现形式CBM通过对企业的业务组件化建模，形成企业业务架构的顶层视图，在一张图上，直观显现出企业的业务蓝图。通过这种方式，将企业的各项业务活动重新分组到数量可管理的离散化、模块化和可重用的业务组件中，确定改进和创新机会，实现有组织的提供服务的能力。CBM采用二维矩阵的方式（见图2）描述企业能力的顶层图像

9、，明晰业务能力分布的映射网络。图2 组件化业务模型（CBM）CBM的横向是业务能力，即企业创造价值的能力。通过明确不同部门的业务功能、划分边界，确定关系，确保所有工作都有人在做，而且没有人做重复的工作。CBM的纵向是职能层级，分为战略/引导层、管理/控制层、执行层。战略层主要指战略、总体方向和政策的业务，聚焦于明确战略发展方向，建立总体的方针政策，调配资源、管理和指导各个业务板块。管理层主要指企业的管理活动，如监控、管理例外情况和战术决策等业务，负责把战略落实到运营当中，监控和管理业务指标和企业员工，发挥看管资产和信息的作用。执行层是指具体的业务执行来实现的业务功能，处理业务请求和业务数据，注

10、重作业效率和处理能力。处理各种资产和信息。二、CBM的作用CBM 提供了一个可以推广的框架，用来创造顺应组织战略的指导方向。企业也可以通过CBM实现专业化发展，实现柔性化运行，并建立和实现面向服务的架构（Service-Oriented Architecture，SOA），为实施 SOA 奠定基础。1.实现专业化发展专业化时代的到来，意味着任何一个公司，都不可能端到端的控制整个行业价值链，因此企业必须聚焦自己真正拥有绝对市场优势的领域。例如苹果聚焦于研发，把制造外包；再如滴滴聚焦于网约车平台，而不是自己拥有司机。在这样的市场环境下，只有专业化，把企业的所有资源，都集中在能够为企业带来核心优势和

11、利润的少数几个活动是，才能让企业为客户、员工和股东提供最大价值。要想体现专业化，必须首先认识到企业应该聚焦的领域。组件，这一源于软件领域的概念就很好的引入企业管理中。组件化的目的是为了识别并解耦具有独立价值的业务活动，通过业务组件之间的服务提供与使用建立彼此关联，以便于重新考虑业务的管理策略（如自主/外包/合作）；提高各个业务组件的专业化能力，保障战略调整的灵活性；同时促进组织内业务服务的复用性和扩展，提高资源共享与服务水平。通过组件和业务模型，为企业的内外部提供了一种专业化验证的工具。对外，可以外包自身无法满足或者附加价值较低的专业化功能，从而达到“让专业的人做专业的事，企业集中精力创造核心

12、价值”的局面。对内，可以重新认识并最大化利用现有的资产和功能，消除非增值活动，整合重复的业务活动以降低损耗。2.实现柔性化运行传统的企业一般都分成了独立的功能性部门，无法看到跨部门的协作以提供客户价值。CBM用业务组件描述企业业务，能够概括描述企业整体业务及业务间相互关系。采用业务组件的方式描述企业业务，避免了采用流程较为复杂的方式。采用CBM分析企业业务方式见图3。图3 采用CBM分析企业业务的方式通过CBM对企业的业务进行建模，使企业原有的所有业务系统都下沉，不再有按业务部门建立的多个烟囱式的业务系统的概念，原有的业务系统变化为一个个提供业务组件和服务能力的能力单元。此外，原有的所有业务系

13、统中的组织，人员，权限，流程引擎，安全等公共基础设施全部抽取，放到同一的平台进行管理，业务系统部再单独构建IT公共基础能力设施。在这种情况下，对新业务系统的建设变化为一个个新的业务能力单元的建设，以后各个业务部门使用的不是孤立的业务系统，而是按需由业务能力单元组装成的可灵活配置的业务应用。不再有明确的业务系统的边界概念，而只有业务组件和能力组装的概念。从而更加快捷有效的调配企业资源，实现企业的柔性化管理。采用CBM对企业业务进行建模的作用见图4。图4 采用CBM对企业业务进行建模示例3.实现SOA管理面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过

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

15、向能力层级对企业的所有业务进行矩阵式定义，但是CBM体现的是企业的业务能力专业化整合能力，其划分并没有固定的方法，同一个企业的CBM可能由于关注点不同而呈现完全不同的结果。业务能力的划分需要与企业价值链保持一致，但先后顺序没有绝对定义。业务组件在划分的时候属于哪个维度，业务组件在操作层面需要反应到什么细节程度，也没有绝对的定义。但是企业的业务在CBM中属于哪个职能层级，可以通过以下原则进行确定。1.通过管理功能与管控权限来判别按管理职能和管控权限的划分两个维度来确定。例如企业人力的备案属于执行层，而人力的审批属于管理层。详细判断原则见图5。管理功能的定义见图6。管控权限的定义见图7。图5 通过

16、管理职能和管控权限划分业务组件能力层级图6 管理职能定义图7 管理权限定义2.通过业务活动类型来判别任何一项业务最终都会落实到执行，但每个业务活动根据其不同的活动的类型，所担负的责任也有所不同。对于会产生3-5年的影响的战略活动、战略规划类活动、体系建设类活动应属于战略层级；对于识别类、过程监管类、制定制度或规则类、统计类、考核评价类应属于管理层级；围绕单一事项的任务执行活动应属于执行层级。四、业务组件的定义和描述CBM中每一个单独的业务模块叫做业务组件（Business Component，BC）业务组件是CBM的核心。二者关系见图8。图8 CBM与BC的关系业务组件的定义为：一个可以独立运

17、行的构建企业的系统或功能模块。通俗来说，业务组件就是对达成特定目标，需要完成的一组紧密关联的工作事项的合集。通俗一点说，业务组件就是组成企业的乐高积木。但是不能有两块一模一样的，不能有相互包含关系的积木。业务组件通过五个要素来描述（见图9）：目标/用途：为什么存在，创造什么价值，如何衡量；活动：定期执行的是哪些简单的、具有凝聚性的活动；资源：需要哪些知识、资产和人力资源；治理：活动和资源是如何管理的；服务：从其他组件获得哪些内容，以及向其他组件提供了哪些内容。图9 业务组件五要素五、业务组件的典型特征业务组件的典型特征，可以归纳为“高内聚、低耦合”。所谓高内聚，就是业务组件具有独立、单一且具有

18、明确边界，业务组件之间相互隔离，改变其一，接口不变，系统不受影响。高内聚的业务组件体现为企业内部具有“高凝聚力”的业务，将具有类似的员工、流程和技术的工作汇聚到一起。在这种情况下，这些业务组件能够形成统一的管理模式，并且具有高度的自主性，能够单独为其他业务提供服务，也能够外包。低耦合，就是一方面业务组件能够独立提供服务，一方面也可以从其他业务组件获取服务，从而达到低耦合。注意，低耦合不是没有耦合，而是能够松散耦合。松散耦合代表着这种链接不是固定的，而是能够依据服务请求的不同，随时形成或者断开链接。只有建立在松散耦合的基础上，才能实现SOA的理念，依据不同的业务组件提供的服务，进行灵活组合，有的

19、时候只要调整应用的界面层内容即可。而且只要我们需要，就可以把业务组件当成一个“黑盒子”，不在对组件内部的关系进行管控。业务组件的高内聚，低耦合使得业务组件具备灵活、响应快、使用能力强的特点。业务组件内各活动的具有高凝聚力，可对外提供效率高、质量好的服务。业务组件之间不会因为其中一个变化而影响另一个也相应变化，从而提升企业的专业化、柔性化，并提供统一的服务。六、业务组件的设计原则业务组件是一系列不可分割的业务活动，那么如何设计业务组件呢？还是需要从业务组件的定义和特征着手，从业务组件是企业专业化的功能模块这个本质出发，从业务组件高内聚低耦合的特点出发，综合考虑以下因素：业务组件由具有内在联系的一

20、系列业务活动组成，这些相似的业务活动应具有通用的业务目标，使用类似的数据，使得业务组件成为单项业务能力的模型化描述；业务组件是唯一的且不能重复，每个业务组件都应具有独立运作的能力的，为企业提供独特的服务；每个业务组件都可以与外部组件通过服务进行合作，业务组件之间通过明确的接口调用关系实现业务交互；每个业务组件执行都需要消耗一定的资源，企业通过共享通用的业务组件，提高资源使用效率，实现差异化竞争优势。业务组件的划分需要深入了解业务之间的关系，并根据企业的战略、管理和执行各层面要求来进行归类划分。这需要有很好的业务分级分类能力，并考虑到业务间的数据流向和共享。在理解业务组件“高内聚、低耦合”的特点

21、基础上，业务组件的设计还要把握好组件的颗粒度。业务组件的颗粒度用于表示业务所包含的业务组件的大小，是一个组织的管理颗粒度的反映，是一种达成共识的范式。颗粒度过大，功能复杂，灵活性小，升级困难（可以独立升级往往会作为确定一个业务组件范围的重要因素），很难实现重用；颗粒度过小，业务组件数较多，造成业务组件之间交互增多，管理成本提升，性能低下。因此找到一个合适的业务组件粒度是很重要的事情。首先要说明的是，业务组件的颗粒度没有硬性指导的原则，因为这不是一个硬性或可以测量的事物。一般来说，业务组件的颗粒度更多应从业务直接实现的业务目标层面去考虑，业务组件的精简代表管理能力的聚焦、灵活度的提高、复杂度的降

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

23、证方法1.业务场景十字分析法业务场景十字分析法（见图10）类比于软件测试的白盒测试，即通过“测试用例”（流程场景）来验证组件外部的流程和内部业务活动，验证组件的正确性。对于业务组件的CBM图，首先相同业务域下的业务组件应能够串接，其次不同业务域下的组件间的交互关系，应体现在同一层次，即战略层面的不同业务域交互应都体现在战略层，管理层面的不同业务域的交互应都体现在管理层，执行层面不同业务域的交互应都体现在执行层，在交互过程中不应有斜线关系。图10 业务场景十字交叉法2.业务组件依赖性分析法业务组件依赖性分析，类比于软件测试的黑盒测试，即不关心组件内部，而通过验证外部接口关系分析（组件的输入、输出

24、、支持三方面）、验证组件正确性。图11 业务组件依赖性分析图示通过连接业务组件的输入输出，可以分析业务组件在职能层级上是否准确。一般来讲，战略、管理和执行层的业务组件在连接上具有图12的特点。图12 业务组件不同职能层级特点八、CBM和流程架构CBM和流程架构存在着天然的联系。在IBM提出的企业总体架构方法论中，CBM和流程都是描述企业总体架构的不同视图。流程可以表示为业务组件相互协作、有序执行的活动。组件可以表示为众多具有同类特征的流程的集合。流程是企业业务活动的内建特性，无论企业是否开展流程管理，流程都体现为“存在即合理”。CBM能够促使企业的流程整合为既能为组织发挥独特作用，又能作为单独

25、实体运行的业务组件，将企业变成一个由不同业务模块组成的网络，每个模块中都包含一系列彼此关联的活动，并促使企业从单条的流程优化向流程整体优化发展，并最终形成整个企业层面上的全局优化的趋势。图13 业务组件之间的协作组成了流程CBM和流程架构也存在着明显的区别。二者核心功能不同，CBM聚焦于业务块层面的业务设计和业务变革，目的是提高业务的专业化水平；而流程架构是描述业务构成，主要指导业务流程的梳理，提供结构性框架。二者描述层面不同，CBM定义每个业务组件的五要素，包括价值、资源、需要的活动、业务治理、提供的业务服务；流程架构重点定义末级流程的要素，包括活动、岗位、表单、制度依据等。CBM的核心目的

26、是实现业务组件化，通过业务的模块化设计，为企业的应用架构、数据架构提供同样的模块化输入，实现企业架构设计的纵向传递和上下对准。企业通过CBM实现了业务组件化以后，还要详细分析业务组件的交互，而这个的基础就是业务流程交互。通过分析业务组件的交互，既能够为建立企业的业务流程体系提供输入，也能够通过分析业务组件之间传递的业务对象，为数据架构元数据模型定义提供指导。CBM的设计需要按照流程的角度进行分析。一般情况下，流程是企业客观存在的，业务组件是需要提炼设计的。CBM需要通过流程分析识别和发现的业务活动，识别和抽象为相应的业务组件。所以CBM的设计首先应根据企业的业务能力提炼形成业务域，然后根据业务流程细化业务活动，通过对同类型的业务活动进行归集提炼，进而归纳CBM的职能层级，并最终形成CBM业务组件图。CBM的应用也需要按照流程的角度进行分析。企业定义了CBM组件图以后，还没有细化到服务。但是业务组件化后，可以通过流程对业务组件之间的关系和交互进一步分析，确定为了完成一个完整的端到端流程