面向大众的业务流程管理（BPM）

　　摘要

　　业务流程是一个组织及其合作伙伴的人员及系统所完成的工作的一种正式表达， 它旨在给内部或外部客户提供产品或服务。业务流程管理（BPM）是正式化和自动化业务流程的技术。AquaLogic BPM Suite（ALBPM）是一个完全允许端到端业务流程管理的业务流程管理系统。

　　这篇文章将介绍该产品的功能， 以及转用BPM时需要考虑的一些重要事项。本文未对BPM的概念进行完整的描述， 但将给出AquaLogic产品提出的BPM愿景。

　　本文适合想初步了解此产品及技术的读者，也为解决方案架构师和负责设计准备转移到基于BPM的解决方案的软件系统的人员提供了重要信息。同时，开发人员和高层管理人员也能在本文中受益。

　　准备工作 (开始之前)

　　开始之前，希望您先问一下自己以下问题：

　　什么是BPM？

　　您认为业务流程在现实中应怎样实现？

　　您是否认为您的组织中的流程在应用程序中得到了很好的反映？

　　您能够很轻松跟踪组织内部的流程吗？

　　使用BPM是否能够改变组织中人员的工作方式？

　　读完这篇文章时，再问自己一遍同样的问题。然后对比答案，看看您是否能够有解决这些问题的更好方法。 这篇文章的目的并非回答这些问题，而是让您自己能够很好地阐述这些问题，并得出自己的结论。

　　理论介绍（一些定义）

　　业务流程是一个组织及其合作伙伴的人员及系统所完成的工作的一种正式表达， 它旨在给内部或外部客户提供产品或服务。业务流程最简单的表达形式就是一组活动，它们表示流程的不同步骤，通过一些转换连接在一起。活动可能需要人为干预，也可能是全自动的。对于需要人为交互的活动，可以在流程中定义一个角色，标识允许谁在这里与流程交互。流程起到定义的作用，而流程中的实例就是完成整个流程的实际项目，从一个活动转换到另一个活动。实例总是开始于流程的Begin活动，而结束于流程的End活动。实例的路径完全取决于实例的数据以及外部环境。

　　转换是活动之间的直接连接, 许多的转换进出一个活动.。一旦某个实例完成了一项活动件，外发转换将被评估， 其中之一被选中，以使实例转向下一活动。条件转换包含一个布尔表达式，该表达式将被计算，要使实例继续沿流程前进，结果必须为true。有些转换是基于时间的，这就意味着如果到了预期时间，实例还在那里，这些转换将会触发到目标活动的自动路由。流程也可以有状态：可为流程定义属性，接受每个实例的一个值，这能帮助您保持实例状态，以转换到不同的活动（例如，报价总数>X，那么就执行该活动）。.

　　从纯建模的角度看，这就是BPM。但要执行流程，这里的定义是不够的；您还需要与其他系统沟通，将流程反映到基础架构中。这就是集成发挥作用的地方了。对于流程中的每一个活动，您都可以定义任务，这些任务基本上是由一个实例抵达该活动时所执行的代码组成的。任务可以通过多种方式实现。当某个实例抵达一个自动活动时，为该活动定义的任务就会被执行，实例将根据执行结果移动到下一活动。

　　对于人为交互的活动，任务的执行是由最终用户通过客户端工作空间触发的。AquaLogic产品内置了集成功能，可以应用于任务代码之中（这一特性将在以后的文章中更全面地加以介绍，它也是本产品最重要的特性）。任务更新流程状态、访问和更改外部系统，并与最终用户交互等等。任务就是将一个简单的流程模型转变为一个流程驱动的应用程序。

　　业务流程管理是正式化和自动化业务流程的技术。要想成功地进化为一个面向流程的组织，您必须使用合适的工具来设计、执行和监控业务流程。这就是业务流程管理系统的构建目的。也是AquaLogic BPM设计的目的所在。

　　时间问题（转移到BPM之前）

　　如果组织想要获得更高的敏捷性，就需要适应业务运转所用到的软件。从概念的角度来看，变化最频繁的不是后台应用程序、不是访问客户的web服务定义、不是EJB的位置，也不是它们所基于的ERP的版本。业务需要适应的最重要的变化就是流程本身：业务必须以某些标准为依据，添加一条更快捷的途径，来自动地认可顺序，从而修改提高或降低认可率的参考值。组织需要处理认可，并平行地检查活动；需要改变执行某项活动的角色；需要手动处理一些异常；需要实施新的业务规则。处理此类变更是BPM的核心内容，允许在不更改任何底层组件的情况修改业务流程。

　　下节将介绍一些我认为对于理解BPM的真正价值十分重要的东西。

　　业务流程管理背后（流程尽在控制之中）

　　通过接纳BPM，也就具体化了业务中的一个重要片段。问题是，如果用户的流程模型不可执行（即它只是纯粹的模型），那么最终您是不得不将其映射到一个应用程序、转换它，就像从“分析”到“设计”再到“实现”时的转换一样。这使得将业务流程映射到生产中真正运行的部分非常困难。采用AquaLogic BPM Suite，您可以构建出一个完整的流程驱动的应用程序，将任务附加到活动，而这些活动就是业务流程内部发生的真实操作。任务是流程的代码，既可以是用户驱动的，也可以是系统驱动的。任务的执行是流程中状态改变的主要驱动力。因此，这个流程切实地驱动了应用程序，直接实施了流程中允许的流、任务和操作。

　　编写流程驱动的应用程序并不会改变您编写代码或实现服务的方式，您仍然是在以相同的方式编写Java类、Web services和JSP。主要的差异在于这个应用程序是流程驱动的。也就是说，所有的代码是通过活动任务触发的，所以您只需专注于这些任务的代码即可，剩下的事情都可由AquaLogic BPM Suite处理。用户工作空间中提供了一些开箱即用的基本流程操作。

　　设身处地（为最终用户着想）

　　对于您的最终用户（即您所构建的解决方案的用户）来说，最主要的变化就是他们有了一份待完成任务的单一列表。他们可以在收件箱中查看待处理的实例以及对于各实例来说可执行的任务。

　　以前，用户必须在不同的页面、系统和应用程序上查看需要执行的任务。幸运的是，如果有新的待执行任务，用户会接收到相关通知，但他们很有可能不会在一个单独的视图中发现这样的通知。而BPM可以将工作分配情况很直观地展现在用户面前。

　　对于最终用户来说，最重要的改变就是呈现在他们面前的将是更加面向任务的工作视图。他们能够很容易地了解，他们有等待通过执行为相应活动启用的任务而许可的待处理事项单。只要清晰地定义流程，您就可以创建出对所有参与实体（如其他系统和人员）来说都很清晰明了的工作单元。

　　有了流程和实例后，您就需要一个用户前台来管理实例（类似CRUD的基本操作）。对于BPM，这些操作将是创建、搜索、执行、取消、委托和路由。AquaLogic BPM Suite通过HiPer Workspace（以任意风格）或直接通过使用API（基于Java或Web服务）提供了所有这些特性。用户无需再构建这些功能，它们已经存在了。

　　BPM是波澜壮阔的SOA运动的一部分，在其中发挥着非常重要的作用。下面分析一下它是如何发挥作用的。

　　我眼中的世界（BPM眼中的SOA世界）

　　许多知名人士对BPM和SOA之间的关系做了定义。

　　Bruce Silver的BPM Watch有一篇非常出色的 文章，标题为BEA's take on BPM-SOA。

　　Alfred Chuang 在Exec2Exec时事通讯中撰写了一篇 文章，也提供了很好的描述。

　　我对SOA的观点是：它与构建封装的、可重用、去耦的服务有关。SOA涉及两个主要“方面”：构建去耦服务和以简单的方式将它们绑定在一起。在SOA企业中，所有服务都将在不同级别上自顶向下地连接在一起（否则就不能使用这些服务）。一些绑定极为静态，而另一些绑定却非常动态。BPM试图提供一种工具，来建模变化最大的层次——业务层。流程利用SOA服务作为构建块，它将在底层系统中反映您的业务流程。这些核心服务将在所有流程中重用，提供了真正的重用价值。这些流程将业务、数据和表示服务绑定在一起，实现价值产生因素：真正的业务流程。

　　如果没有流程层，您最终就要在表示层或业务层里连接这些服务调用，业务逻辑的某些变更将决定哪些服务器要修改，并重新根据新的业务定义来连接服务。下面通过一个例子来详细描述：您拥有一个Web应用程序，它具有双层架构，即业务组件和表示。某些表示组件包含应用程序的排序逻辑。商业用户决定改变业务流程，改变某些操作的顺序及一个业务组件的使用。那么您应如何将这样的业务需求精确地映射到需要更改的代码呢？如何才能知道在哪里修改？为什么需要了解更改流程所需的实现？

　　使用业务层，您拥有明确的空间来利用可用服务，这里流程层就扮演了这些服务的胶合剂，使它们在业务流程的范围内能够起作用。因此，当业务发生改变时，只有一个地方发生更改：流程，而不是服务。

　　在BPM的上下文中提到重用时，有多个级别需要考虑：

　　外部系统的低级重用，这里有许多业务流程要访问同一Web服务。

　　BPM的中级重用，这里您可以在共享流程和组件模板，重用代码和流程模型的最佳实践。

　　流程的高级重用，这里您可以公开一个流程，该流程可供组织的其他部分使用。

　　前面已经介绍了什么是BPM、它怎样适应新环境，下面将深入介绍推荐的产品。

　　准备工作（使用AquaLogic BPM Suite）

　　AquaLogic BPM Suite是一款涉及业务流程的整个生命周期的产品。它提供了解决方案所有时期所需的工具：开发时、运行时及演进时。对于每一个阶段，必须执行一些任务来完成生命周期，后面介绍如何使用ALBPM时，我将对这些任务进行说明。

　　享受沉默（和BPM可以替您做的事情）

　　AquaLogic BPM允许您设计、模拟、开发、执行、监控、操作和更改业务流程。下面将逐一加一解释。

　　开发时

　　这是将您的想法转变成一个应用程序的时候，将想法变成可执行的东西涉及许多使应用程序活动起来的任务：表示、流程、集成，所有一切都打包在一个BPM工程源文件中。

　　业务流程设计——ALBPM Designer允许您以图形化的方式构建实际业务流程、定义流程角色和活动以及活动之间的流。您还可以把要在其他系统上执行的操作做成文档。这里，您可以定义业务的运作方式、建立依赖项，SLA，异常处理等等。设计的结果就是业务流程模型。在流程生命周期的所有其他步骤中，这个模型同样也是核心，即便是在运行时。这个模型对于最终用户是可见的。

　　业务流程模拟——ALBPM Designer能够模拟业务流程的执行。对于流程中的每个活动，您可定义其资源、成本、时间和各种转换的分发。模拟将会利用这些信息，并生成时间、瓶颈、总成本等信息。这使您能够知道流程的问题所在。

　　业务流程开发——可以利用ALBPM Studio来构建一个完整的流程驱动应用程序。对任务进行定义，定义流程中的每个活动和各任务要执行的内容。任务实现包括业务流程逻辑、集成代码和表示。其结果是一个可执行的应用程序。这就是声明和使用对于外部系统或流程所需资源的集成点的地方。您在这里定义支持业务流程、流程UI和与外部系统交互的应用程序。当然，也可以使用SOA基础架构的任何组件，包括其他BEA产品。ALBPM有着广泛的集成能力，允许您使用任何具有可交互接口的外部软件。开发的结果是业务流程驱动的应用程序。为简单起见，下文将其简称为“流程”。

　　运行时

　　一旦有了应用程序源代码，就可以把它们转换成一个活动的实体、向最终用户公开BPM工程、创建实例、与其他相关系统连接等等。

　　业务流程执行——ALBPM Enterprise是业务流程的运行时环境。它提供了流程引擎，该引擎运行流程和众多作为最终用户前台的客户端应用程序。要构建一个带有运行的流程和与之连接的用户的BPM环境，您只需要使用该产品即可。它还提供了基础架构管理应用程序。这是我们的核心产品——BPM解决方案的“心脏”。产品的架构确保提供所有企业级特性，如可伸缩性、性能及可用性。此产品构建用于支持具有多用户、多流程等特点的大规模安装。

　　业务流程操作——流程引擎记录流程中各实例所发生的事件。它存储用户或系统执行的任何操作的时间、用户和结果。此后在审计实例已经过的步骤时，可审查这些信息。这种功能表明了在许多情况下不可追踪的因果关系。您还可以使用灵活的标准来搜索实例，查看它在任意时刻的状态；也可以重写错误流，捕获一个处于错误状态下的实例，并将它发送到正确的地方。还提供了开箱即用的面想流程的基本操作，如实例的创建、取消、路由、委托和分配。所有这些操作都是以为用户指派的特权和流程定义为基础启用的。

　　业务流程监控——以流程引擎中可用的信息为基础，您可以轻松构建指示板（dashboard），以所有者的角度为您提供与业务流程所有者相关的信息，如整个流程需要占用多少时间，由于处理延误有多少资金待收取等等。对于每个流程，您都可以定义哪些度量标准与业务相关，需要定义什么样的维度来确保正确下钻。所有这些信息都将用于构建指示板，它将在随后的运行时公开，并提供流程当前状态的相关信息。

　　业务流程演进

　　业务流程投入使用后，变更总是不可避免的。变更的原因有可能是市场的变动、新业务定义的增加，或是您发现了现有流程中的不足之处。所以就重新进行设计开发，并在流程中实现这种变更。ALBPM Enterprise能处理多个版本的流程，也可用另一版本的流程替代现有流程。流程的不同版本彼此独立，不会互相干扰。

　　业务流程管理

　　根据以上的描述，您可以管理业务流程的整个生命周期，从初始阶段到运行时。ALBPM Product Suite就是在这个理念下设计出来的。它的基本概念已产生至少有10年之久，正是一个纯粹的BPM产品。

　　图1给出了AquaLogic BPM Suite中主要组件的概览

　　图1. BEA AquaLogic BPM Suite 组件

　　一切物有所值（结束语也是）

　　如果您正在寻找合适的工具，帮助您采用面向流程的方式为企业构建软件，那么ALBPM就是一种理想的方式，它能使您在工具的协助下完成流程的生命周期。ALBPM是一种从零开始的设计，其设计使流程和集成成为一个成功应用程序的绝对关键。我想强调以下两点，它们是完全理解BPM的基础。

　　ALBPM将改变您对解决方案的看法。

　　ALBPM将改变最终用户的工作方式。

　　本文描述了BEA对未来软件蓝图中基础部分的展望，它描述了未来应用程序、开发环境——最重要的是——业务的驱动方式。