工作流系统
Figure 1: Workflow vs. RDBMS positioned in the hype-curve
导致形成这种状况的原因之一，是在工作流中使用了过多的概念。在这个领域中的大量规范和工具没有一个是相似的。当然，它们相互之间有重叠并且会相互参考引证。
在介绍工作流时有一个话题必须包括，那就是工作流和业务流程管理（BPM）的关系。术语“工作流”通常描述人与计算机系统的一系列相关交互。在开发人员中，工作流经常被提及。有时，工作流的意思是指一些不同的UI界面。业务流程管理的范围比较广，相比之下工作流多半局限于技术领域。业务流程管理还从管理人员的角度涉及了非技术问题，比如分析、组织的效率。
在本文中，我首先解释什么是工作流管理系统，然后介绍业务流程管理的优点。接下来描述一下为什么工作流市场乍看起来如此混乱。本文给出的主要结论是：选择工作流系统是想用工作流系统的公司，将要面对的最困难的事情。为此，本文的核心部分描述了一个流程定义（process definition）的四个层次，为你选择工作流提供一个基础。本文还用中立的语言描述了工作流和BPM的通用概念。最后，给出了一些规范和工具的指导性描述。
什么是工作流管理系统（WFMS）
定义
工作流系统是以规格化的流程描述作为输入的软件组件,它维护流程的运行状态,并在人和应用之间分派活动。
为了后面的描述，我们先定义一些基本的术语：流程定义（process definition）和流程实例（process instance）. 一个流程定义是一个业务流程或过程的规格化描述。一个流程实例是流程定义的一个运行实体。 都目前为止，概念还比较清晰是不是？但当再深入一步时，我们就要小心使用文字了。如何阐述流程中的步骤，现在还没有一个统一的方式。这是各种工作流规范和工具之间主要的分歧。
| 为什么应当禁止使用术语“活动（activity）”... |
工作流系统另一个重要的职责是维护每一个流程运行的上下文信息。 流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。如，休假申请的开始日期、数据库中一条记录的键值、文档管理系统中一篇文档的索引等。通常在流程定义中声明这些变量，然后在流程实例生成时，这些流程变量被实例化。所有成熟的工作流管理系统都支持定制的变量类型。
目标领域（Target usage）
使用工作流管理系统的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构（heterogeneous）应用和数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订单、支付、资源计划等等。让我们称这些系统为专门应用（ dedicated applications）。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流系统的第一种使用方式就是：结合所有的专门应用，使用工作流系统构建一个EAI平台。
工作流系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。对于专注于ISO 或者CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。 不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化（如使用基于Web的应用）。
工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用（不重复发明轮子）和应用软件的可维护性。
The case for workflow
对于引入工作流的组织，能够在软件开发和业务两个层次受益。
方便开发
工作流管理系统能够简化企业级软件开发甚至维护。
- 降低开发风险 - 通过使用状态和动作这样的术语，业务分析师和开发人员使用同一种语言交谈。这样开发人员就不必将用户需求转化成软件设计了。
- 实现的集中统一 -业务流程经常变化，使用工作流系统的最大好处是：业务流程的实现代码，不再是散落在各种各样的系统中 。
- 加快应用开发 - 你的软件不用再关注流程的参与者，开发起来更快，代码更容易维护。
业务流程管理 (BPM)
在自动化业务流程之前，分析并将它们规格化是一件艰苦但会有很好回报的工作。e-workflow.org对于分析流程能够带了的益处有不错的阐述：
- 提高效率 - 许多流程在自动化过程中会去除一些不必要的步骤
- 较好的流程控制 - 通过标准的工作方法和跟踪审计，提高了业务流程的管理
- 改进客户服务 - 因为流程的一致性，提高了对客户响应的可预见性
- 灵活 - 跨越流程的软件控制，使流程可以按照业务的需要重新设计。
- 业务流程改进 - 对流程的关注，使它们趋向于流畅和简单
我认为他们还遗漏了一个使用工作流系统最重要的因数：提高对迭代开发的支持。如果软件中业务流程部分不容易更改，组织就会花很大的精力在开发前的业务流程分析中，希望一次成功。但可悲的是，在任何软件项目开发中，这都很少能实现。工作流系统使得新业务流程很容易部署，业务流程相关的软件可以一种迭代的方式开发，因此使用工作流系统使开发更有效、风险更低。
缺失的一环（Missing link）
我确实认为工作流系统是企业应用开发中缺失的一环。将企业业务流程逻辑在企业级软件中实现的缺省方式是分散的。这意味着业务流程逻辑散布在各种系统中，如EJB、数据库触发器、消息代理等等。这样得到的软件难于维护，结果，企业只能将改变业务流程软件作为最后的选择。他们经常能够做的是，改变流程以适应软件。上述问题也适用于采用大型外部ERP软件包的企业。进一步，假设我们认识到这个问题，并打算将一个流程相关的代码都集中起来。对于一个流程来说这很不错，但当你要实现多个流程时，你会看到管理状态和流程变量的代码被到处复制。最后，我们会整理这些代码放到一个集中的库中。好，...这就是一个工作流管理系统了，不用费心自己来实现，你可以从本文后面的列表中选择一个。
A closer look
WFMS interfaces
一个工作流管理系统以流程定义作为输入。在这里，可以将流程定义看作UML活动图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报价、...之后，工作流系统负责维护这些流程定义的执行状态和上下文。为此，需要通知工作流系统状态的变化。运行流程的状态变化可以记录下来，以备监控管理。
Figure 2: Interfaces of a WFMS
- 定义 工作流系统的定义接口使流程开发人员能够部署流程定义。注意，这里的“流程开发人员”可以是业务分析师和软件开发人员的组合。
圈套（Pitfall）
许多工作流管理系统的开发商想使你相信，通过使用他们的图形化流程开发工具，只要业务分析师就可以生成流程定义。这种幻想源于“编程很难”这样的事实。开发商的销售人员喜欢说“看，你不用写一行代码”。不用写代码是好事，可大部分开发商在这点上走的太远，忽略了在某些场合提供一种将代码集成到流程定义中的机制是很适合的。在将工作流系统作为EAI平台时，必须在流程中集成代码。开发流程定义需要业务分析师和软件开发人员的合作。一个好的图形流程设计工具应该能够支持这种合作。 - 执行 执行接口使用户和系统可以操作流程实例。流程实例是流程定义的执行。流程定义的控制流通过状态机描述。执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态结束了。
- 应用 应用接口代表了由工作流系统发起的工作流系统和外部系统之间的交互。当一个用户或系统操作一个流程实例的运行时，会生成一些事件（如一个迁移的执行）。流程定义中可以指定一段响应一个事件的可执行代码逻辑，这段代码和组织内外部的其他系统打交道。
- 监控 管理人员通过监控接口获得流程运行的确切数据。有时，运行日志也可用于审计。