如何分析 BPM 解决方案

　　摘要

　　构建BPM 解决方案与构建传统应用程序截然不同。因此，定义这种解决方案的架构需要用一种不同的方式。

　　本文简洁地描述了关于BPM解决方案的概念以及定义了使用BPM构建的软件解决方案的主要架构块。下文将对于如何做出适当的需求评估并将其转换成恰当的解决方案架构给出一些意见和建议。

　　本文旨在为那些定义架构和试图了解BPM在现实中是如何应用的人士提供帮助。假设您了解 AquaLogic? BPM Suite，或者已经读过我 此前的另一篇文章《面向大众的业务流程管理（BPM）》，其中描述了BPM的概念。

　　BPM的神秘方法

　　希望您发现这个比喻很有趣：如果您只是要驾驶一辆汽车，那么并不需要知道引擎和传动装置的工作原理。汽车的这两个方面关注的是不同的问题。一方面，您要懂得变换档位、转弯，观察后视镜和加速。 另一方面，您要了解内燃机，传动装置和电子零件。

　　在这篇文章中，架构师犹如汽车司机， 最终用户好比乘客，而BPM是汽车。开始驾驶吧！

　　我还是没有找到我想要的东西（让我们从定义开始）

　　让我们浏览一下BPM解决方案的组件。第一步是定义BPM解决方案。

　　BPM解决方案

　　BPM解决方案是在组织基础架构内运作的业务流程。

　　BPM解决方案是完成实际工作的“活动”业务流程。解决方案提供了“执行”业务流程、与他人和系统交互所需的一切。架构师需通过定义模块规范和布局确保所提议的解决方案满足所有的需求。在此我们从一个高层次的角度来探讨一下主要的概念块。不必担心各片段的执行方式及其复杂性；我们现在来布局组件。

　　正式的定义有助于定义解决方案的内部块。

　　业务流程

　　业务流程就是一组安排在反映达成业务目标的实际的工作流程的流中的活动，。

　　这里的业务流程可视为是带有模型、集成、表现和逻辑的流程驱动应用程序。

　　业务流程是用AquaLogic BPM Studio写成的，采取BMP工程的形式。流程中的组件可以单独实现，但将会整合到Studio中，并用在BMP工程中。在这一点上，业务流程仅仅是一个定义。它是源；它并没有生命力；它需要容器来运行；还要求所有的外部依赖项联机且可用。需要基础架构来驻留业务流程。

　　基础架构

　　解决方案的基础架构是一套允许业务流程执行的服务和应用程序。

　　为了执行业务流程，需要一个BMP执行引擎，还要有客户端应用程序、管理工具等等，以便进行交互。所有这些模块都包含在 AquaLogic BPM Suite中。但通常并不能满足您的全部需求。假如业务流程调用web services，从定制数据库里读取，或者使用Enterprise JavaBeans，这时就必须确保这些服务可用，否则此流程就不能理想地工作。

　　这些服务已成为基础架构的一部分，因为业务流程需要它们。所有这些依赖项在基础架构中和BMP服务器本身一样重要。

　　基础架构定义所有的组件的通信方式、位置及其配置方式。这是从最高层次上来观察BPM：从这个角度，您可以掌握任何一个组件以便了解各组件的详细情况。从这个角度进行观察是非常重要的，因为它显示了解决方案的主要活动部分；业务流程和组织均由基础架构托管。一个基础架构通常要托管很多业务流程，所以基础架构是众多BPM解决方案中的一部分。这很关键，因为您必须使基础架构恰当地处理将在其内部运行的所有解决方案。它的优势在于无需创建一个全新的基础架构，所以就节省了很多资源和对多个基础架构的管理工作。

　　现在，当您开始定义一个架构的时候，很快就出现了两个问题：

　　什么定义了基础架构的需求？

　　业务流程定义了基础架构的许多需求，比如它们所依赖的外部系统，外部系统又定义了如何与之连接。

　　业务流程具有一种预期的使用方法，它定义预期接受的负载。使用预期用法时，您也可以了解到使用业务流程的参与者的使用概况。理解如何收集负载需求和它对于基础架构的影响是非常重要的，因为这为您合理确定基础架构的规模提供了正确的信息。

　　但是IT、企业所有者以及规章制度也可能会带来某些需求，大多数以安全性、SLA和运行服务器的平台为中心。设计基础构架时必须考虑到所有这些需求，因为它们必然会影响到组件交互的方式。

　　下面来看看开发生命周期中非常重要的一步，在此阶段必须实施许多架构决策。

　　如何将业务流程安装在基础架构中？

　　业务流程的部署包括对于组织和基础架构的映射，这称为部署拓扑。

　　部署定义流程驻留在怎样的企业服务器上。也就是说，这个流程的实例将保存在这个服务器里，使用该流程的客户端连接此服务器，自动执行也在这里完成。因此需谨慎规划业务流程的部署拓扑，以便更好地利用所拥有的基础架构。部署拓扑允许用户在服务器间分布流程，提供了一些水平可伸缩性。例如，可以将用户最密集的流程部署在一个引擎上，并将一批流程部署在另一个引擎上，还可配置各引擎使之更好地适应各部分的需求。

　　部署还定义了流程将位于哪个组织单元（OU）。也就是说，您可以在多个OU中部署同样的流程，这带来了更高的灵活性，因为每个OU都能具有同一流程的不同版本。

　　基础架构也通过提供如Workspace这样的最终用户工具为将人员与业务流程相整合的途径，而您不需要定义对于各用户来说哪些内容是可见的，也不需要定义他们对业务流程的权限。需要的是映射组织。

　　组织

　　组织是对企业中与业务流程交互的实际人员的一种反映。

　　组织反映了人员的分组方式以及各小组和个人的权限；它也反映了这个组织的层次结构。简而言之，就是谁能够为每个业务流程做些什么。这样做，就出现了两个不同的方面：可见性和权限。

　　可见性定义您能看见的流程，而权限定义允许在流程中做的事情。要处理一个流程，既需要可见性又需要权限。规划流程的部署拓扑时，这些都是很重要的工具，因为它们定义了组织是如何与流程一起运作的。

　　下面更详细地说明一下这些定义：

　　可见性由人员和业务流程层次化地安排在组织中的方式定义。

　　通常把参与者安排到一个组织单元中（organizational units, OU）。OU是在一个树结构中定义的，该树以组织为根。流程也被部署在OU中，因此参与者能根据指派给他们的OU以及流程所部署到的OU来查看流程。这就是为参与者定义一个流程的可见性。

　　权限是由指派给参与者的角色和在业务流程中定义的角色来定义的。

　　参与者具有指派给他们的组织角色，也可能是由其所属的小组直接或间接指定的。在业务流程定义中，当流程被公布时，用户也可以定义映射到组织角色的流程（抽象）角色。对于那些能够操作流程的用户来说，他们首先需要的是其可见性，但必须从映射到流程的角色中指派给他们一个。根据参与者的角色和拥有的权限，他们有权在流程上进行操作。

　　汇总

　　既然已经定义了这些概念，就该把它们与现实联系在一起。正确地理解业务和组织的需求，并把它们转换成能满足这些需求的架构，充分利用资源是至关重要的。此项任务的输出不是一份详细的项目、角色或参与者的列表；它更多地则是构建基础架构、组织和流程所需的一系列规则、指导原则或策略。

　　那么需要哪些定义来构建架构呢？

　　组织映射到BPM空间的规则

　　要将实际的组织转换为BPM，必须存在某些标准，其中包括以下定义：

　　组织单元模式

　　组织角色模式

　　小组模式

　　OU的参与者的指派

　　小组中参与者的指派

　　参与者和小组的组织角色的指派

　　基础架构的组件

　　应用程序和服务的分布以及它们之间的通信方式是架构中的关键部分。实际上，这就是是该解决方案的技术架构。以下是需要包含的应用程序和所需配置类型的基本列表。

　　BPM 企业服务器

　　类型 （Standalone、WebLogic）

　　配置 （Clustering、Location）

　　数据库配置

　　HiPer Workspace for BPM

　　配置 （Clustering、Location）

　　其他模块

　　业务流程依赖项

　　流程部署拓扑

　　业务流程必须嵌入在基础架构和组织中：这就是部署拓扑。拓扑对于基础架构和人们使用流程的方式有着直接的影响。这些定义很简单，但是要根据组织和基础架构谨慎地加以定义。

　　到组织的映射

　　配置流程的组织单元（OU）

　　流程角色到组织角色的映射

　　到基础架构的映射

　　执行流程的企业服务器

　　流程所需的外部资源

　　结束语

　　从架构师的角度来看，理解是什么定义了BPM解决方案、恰当地布设基础架构并为业务流程定义所要遵循的规则是非常重要的。在动手之前，定义不必是完备的；它会随着业务流程的构建和来自于组织的更多需求而演进。定义所有这些问题是企业用户、开发人员和IT之间的一个长期的商谈过程，从而构建满足各方需要的架构。

　　架构师的作用就是在所有这些人中进行调停，并且了解需求对于不同领域的影响。

　　我撰写这篇文章的目的就是给BPM架构师提供工具让他们更好地完成工作。我希望此简介对您有所裨益，也想倾听您的意见——敬请在下方评论中留言。