【软件工程】构件化业务模型CBM

引言

随着Internet的流行，市场越来越趋向于网络化，对于企业而言，其服务趋于专业化是必须的。企业之间传统的边界由于全球连接平台而被打破，企业的利润越来越取决于其在某些领域的绝对优势，因此将企业核心竞争力建立在几个核心的业务上市成功的关键，那么企业怎么样实现服务的专业化呢？

企业可以使用CBM的原理来将企业内部、外部服务变得专业化。CBM让企业评估整个企业的目标和策略，同时对企业的内部、外部服务实施专业化。在不增加系统复杂性的情况下，CBM模型可以允许组织不断扩大、发展，同时降低风险，提高经营业绩、提高生产力、降低成本和提升资本效率和财务的可预测性。

CBM框架

就像我们之前看到的那样，业务构件可以将业务服务内聚成独立的模块，这些模块可以在整个企业内部共享。但是，业务构件在整个业务模型的上下文环境中如何一起工作呢？就像在图5中看到的那样，CBM框架按照能力和可靠性级别将业务构件组织在一起。有了CBM，企业执行官们现在可以将现有业务想象成一些连在一起的模块。

将业务构件按照能力分类，可以从它们为企业提供的价值角度有一个更高级别的视图。不同行业的不同公司对业务能力建模的方式也不一样，但是，不管怎样，每项活动都会依据某种能力组织起来。

每项活动被分配到三个可靠性级别（决策，控制和执行）之一，可以帮助企业的执行官开始充实业务构件愿景。每一个业务构件的级别是凭直觉分配的，当然有些情况下也会出例外。

• 决策：这一层次的业务构件为其他业务构件提供战略决策和企业政策，它们还简化与其他业务构件之间的协作。
• 控制：这些中间层的业务构件在“决策”和“执行”层之间完成检查和平衡的功能。他们监控工作执行情况、管理出现的异常、作为资产和信息的管理者。
• 执行：这些底层业务构件提供商业行动，这些行动为企业创造价值。它们处理资产和其他业务构件或者客户用到的信息。

这三个层次的可靠性级别优先考虑的内容是不一样的。比如在“执行”这一层，重点是保持员工的工作饱满和富有成效。建立这一层的业务构件的目标是让信息更容易的获得。技术上来说，数据访问的速度和及时性是关键。比如，当客户使用ATM机时，他们希望它能通过简单的界面、直接了当的方式提供准确的信息：我的帐户中有多少钱？

把执行层和决策层对比一下，决策层中都是像处理新产品的推出这样的高级活动，这些活动只涉及到少数对于股东价值有重大影响力的人，因此，这一层的设计思路和“执行层”的设计思路基本相反。处理新产品的推出需要很多部门的合作，包括市场、风险、财务、管理和信贷。这些部门提供的信息是保证活动成功的关键，因此，工作流程是关键特性。从技术角度来说，这些活动都需要人从保存在数据仓库中的海量、多维度的信息中分析范例和趋势。因此，决策层的系统设计不是关注于数据访问的速度，而是为了分析的简单、广度和深度。实时的界面也不是必须的，因为数据通常都是几个月前的而且被批处理。

业务构件

业务构件是一些标准的构件，他们经过装配构成了专业的企业，每一个构件都可以从五个方面来解读：

• 一个业务构件必须具备其需要实现的业务目标，它必须为其他业务构件提供服务。
• 每个业务构件都实现相互排斥的业务活动，以实现其特定的业务目标。
• 业务构件需要资源，人，知识和资产来支持他们实现的业务。
• 每个业务构件都可以作为一个独立的实体，拥有自己独立的治理模式。
• 和一个独立的业务服务一样，每个业务构件都对外提供业务服务或者使用其他业务服务。

比如，一家银行决定将其客户信用决策业务封装成一个业务服务，为了提高效率，它需要将与此相关的人、流程、资产都集中起来，之前这些人、流程、资产可能由几个业务单位管理，它同样需要合并公司内部的所有金融数据库，提高用来评估信用的信息的质量。把所有信息集中到一处额可以让信用评估者在评估投资组合信息时作出更好的决策（比如：为客户信用卡申请提供信用评估时）。通过对客户信用风险有一个全面的认识，企业可以更加高效的交叉销售它的金融产品。

为了从业务组件中获取最大限度的好处，公司在选择业务构件时需要谨慎的选择那些具备“高可结合度”的业务活动，也就是那些需要相似的人、流程和技术基础架构的业务活动。当确定业务构件的边界时，公司也要综合考虑这三个因素，而不是其中的某一个或者两个因素。

之前，该公司有5个不同的群体处理信用评估，经过业务构件化后，信贷管理构件现在可以为所有和潜在客户的信用评估相关的业务构件提供服务，比如应用流程的管理、分配信贷资源以及信用政策的调整。

信贷管理构件有自己的管理结构和治理模型，因此具有很高的自治性。原则上来说，它可以作为一个独立的业务为整个企业提供服务，在新的业务产生时，它也可以为其他的企业提供服务。

当新的业务构件运行时，它可以和公司内部或者外部的其他业务服务实现高度协作。这种协作通过业务构件之间的服务交换、输入、输出得到实现，当业务构件需要输入以便完成特定的业务活动时，信用管理构件通过访问其他业务构件的服务来获得。这样它就可以获得输入的全部信息（比如客户信息和账户恢复）。与此相反，当其他业务构件需要信用管理服务时，比如需要信用评估或者信用活动报告，信用管理构件可以将这些信息作为输出。预先设定的服务等级协议，包括格式转换、时效、数量、质量、费用以及交付等，将为这些服务访问提供执行标准。

这种面向服务的处理可以让信用管理构件保持它的唯一性，同时它又通过松耦合和其他业务构件进行协作。当业务环境发生变化时，每个业务构件可以终止这种耦合性并且更容易的完成新的耦合。

松耦合和高内聚

业务构件获得的好处源于两种相关但是截然不同的特征： 业务构件之间的松耦合提供了灵活性、适应性和灵敏度，同时，每一个业务构件内部的高内聚提供了高效率和更高的质量。

业务构件之间是松耦合的，而不是基于私有的或者定制的“硬”连接，业务构件之间有清晰定义的服务边界，在他们初始化、响应请求的时候形成、断开连接。松耦合同样依赖于一些互相都能理解的通讯语言，这样，异种系统之间也可以按照需要连接在一起。比如： 互联网银行可能允许通过电话亭和网络门户同时访问它的CallCenter功能。业务构件的这种特性让企业提供的服务具备更好的扩展性，同时，获得了更多的灵活性，保证企业可以获得为内部或者外部客户提供更多服务的潜在能力。与此相反，业务构件要求服务和服务的实现是分开的。事实上，从外部看一个业务构件，它就是一个黑盒子，它的内部运作是透明的。

在业务构件内部，业务构件将企业内部类似的业务服务聚合为一个简单的逻辑模块，提供了模块化和高效率。在这个意义上来说，构建一个业务构件最重要的就是将类似的业务放在一起。为了获得内聚性，业务构件内的每个服务都是唯一的，而且不会和其他构件内的服务重复。

把这些类似的业务放在一起有一个额外的好处，就是暴露真正的专家和那些做得不好的人之间执行服务时的差异。在整合业务过程中推荐专家级的实践，整合后的业务构件将有效提升对业务和客户的服务质量。实际上，这也是在企业内部共享最佳实践的一种很好的方式。

许多公司都努力去实现高内聚。当互联网作为一种服务交付渠道一出现，一些企业就建立直接的Web网站作为一条新的业务线，独立完成服务、交叉销售和市场活动。这种方式让企业给用户的体验式混乱和复杂的。一个通过网站看到的市场信息和产品和另一个走进卖场、或者通过CallCenter和企业交互的用户看到的东西不一样。这些公司没有实现在服务、销售和市场之间共享高内聚的活动，不考虑任何和渠道相关的因素。

更加聪明和优雅的方式是一次性的创建这种服务能力，然后再不同的渠道之间去共享它，只是针对不同的环境调整用户界面。这样，对待用户的方式、用户可选的服务和产品、对用户公布的市场信息都是一致的。不考虑这种跨越人、流程和技术的高内聚的活动让很多企业环境更加复杂。

原文链接

• 《构件化业务模型(1) - 框架》
• 《构件化业务模型(2) - 什么是业务构件》
• 《构件化业务模型(3) - 松耦合和高内聚》