一种适用于真实世界BPM的协作方式
我们在业务流程管理（BPM）领域里摸爬滚打已经很多年了，最近看到人们对它的关注不断提升，这是非常有趣的一件事。对这一趣事儿起催化作用方面的有，工具的日渐成熟、新BPMN2.0规范的形成、以及更多更好的相关出版物带来的人们对BPM的进一步理解，它们代表着BPM领域内最重要的进步。
厂商提供了越来越高精良的图形化工具以及由其承诺的业务流程实现自动化，无需任何编码甚至开发者参与；然而，我们也发现了使用这些“传统”的以厂商为中心方法的一个问题：它们并未履行任何承诺！
我们以前的一些项目可以佐证以上观点。公平起见，既然这些工具大都会面临相同的基本问题，就不具体点名是什么工具了，有个同事不得不使用一个小的Web界面工具来实现一个简单的流程。这个工具提供了一个特有的、神奇的可拖放界面设计器，刚开始用似乎还比较方便，但当我们项目快要结束时，出现了一些需要对表单上的数据进行细微校验的需求，而这个“神奇的”工具并不提供该功能。为了规避这些局限性，我们花了比使用简单的JSF实现整个界面更多的时间去搞这个设计器，不管怎样，我们最后还是搞定了。
在另外一个客户那里，某个开发者曾告诉我说，“他花了两天多时间尝试对一些特殊需求进行建模，而他本可以用Java在半小时内直接实现的！”还有一个客户尝试运行交易服务和有状态服务，而这不幸需要以Web服务方式调用服务。在使用WS-Addressing，WS-AtomicTransaction等标准进行实验并试图拼接一些框架之后，基本上他放弃了整套BPM工具。
而下一个客户在竞标初期就将厂商踢出了局，因为他们需要更多的资金以便自己提供一套Java API。
所有这些例子有一个共同点：工具使得开发者的工作更困难而非更简单！这些工具没有减少开发所需的时间和金钱。它们对使得业务和IT相契合并没有提供进一步的帮助，这是因为所需的技术模型非常复杂以至于不能和业务流程模型完全相一致。你有看过BPEL模型（所制作的流程图）和业务人员最初所画的流程图有任何共同之处的吗？
那么，BPM不起作用吗？难道业务和IT契合始终是一个神话？当然不是！话虽如此，我们却不得不反思我们做BPM项目的方式。经过过去几年的不断反思，我们找到了BPM在真实项目中的运作之道。
简单说来，BPM更多地关注流程的协作以及充分考虑协作过程中参与的不同角色，并使人们按照他们期望的方式工作。因此，它不太以工具为中心，因为就算我们需要用工具，也应该是工具来适应我们的工作方式。我们必须结束那种工具强迫我们按照厂商规定的方式来工作的情况。不同的角色使用不同的工具，所以不存在独一无二的工具。虽然这看起来显而易见，但许多工具还是试图与此背道而驰。
为了能够使得业务和IT相契合，我们开发了一种使用BPMN（业务流程建模和标记）的方法论。它以流程模型为中心实现协作，我们可以进行讨论并将需求、业务规则或其他物件连接起来、使开发状态形象化、使业务驱动的测试场景得以细致明确等等。它不仅仅可以对可执行的流程进行建模，而且还对周边“池”中的各组织的视角进行建模，以使业务和IT视图相契合。
因此，BPMN提供了一种很大的可能性：“池”。“池”的使用为用同一种模型来构建“业务特有的”和技术的两个方面，并为设置二者间的正确的关系提供了可能。在我们的书中对此进行了详细的描述，并且在官方BPMN样例文档中提供了一个例子。你也可以通过我同事写的一篇博文弄明白我现在所表达的意思。总之，我们把那些看作BPM的真正价值，而不是业务人员“描画”可执行的流程。
我们已经在一些客户那里实践过这种方法，有些客户甚至还在使用Microsoft Visio工具。当然了，在过去几个月里，我们也开发了工具在几个试点客户那印证这种方法，其中最重要的一个大项目是为一家大型德国电信公司做的。目前，我们以通过camunda fox开源项目发布所有资料，其第一版本将很快会公之于众。我们希望分享我们的经验，通过讨论吸收新观点，并帮助BPMN规范以得以正确采用。那样它就会为每个人创造真正的价值，而不仅仅是为那些工具厂商的银行账户增值;-)，如果顺利的话，我们可以跳过Gartner的技术成熟度曲线理论中所谓的“幻灭期”，尤其针对BPMN 2.0而言。
让我们更具体一点看看我刚刚提到的那个电信客户项目。当时我们所面临的环境仅仅是使用了许多EJB、一些JMS以及有限数量的JBoss ESB服务的Java EE。流程还没有进行统一文档化，业务部门大多采用事件驱动流程链（EPC）的方式，而IT人员尽一切所能使用了UML、Power Point等等。我们的目标是针对业务和IT，通过引入BPMN作为建模标记，使其成为保持模型的技术化和业务流程同步的桥梁。
我们最终达到了我们的目标！但当时是举步维艰，必须按部就班……
技术上讲，一个“超级棒”的JBoss SOA平台启用，这意味着可以部署可执行流程已到JBoss jBPM 3.2这一著名的开源流程引擎上。我们在几次不成功的尝试使用BPEL（其实并不适合技术环境）后做出了使用jBPM的决定。主要的原因根本在于那些服务不能作为Web Services来用，工具也不足够成熟，价格太昂贵并且也缺乏技术诀窍。因此，jBPM是一个不错的选择，它可以让现有的Java开发人员很快上手使用，并且对开发过程的影响也非常之小。在此我要特别要指出非常重要的一点：类似JBoss jBPM或者不久前的Activiti ，这样的开源流程引擎对开发人员来说更像是某种框架或库，而不是一个完整的产品套件。它们可以容易实现客户化定制并集成到你自己的架构中。它们支持单元测试，理解起来也很容易。
记住：我们希望给不同的角色提供其所需的工具。开发人员乐于接受Java、Eclipse、JUnit、Subversion、Maven等工具。因此他们应该能够继续使用这些工具！
业务分析人员有一个商业化工具Signavio edition 在手，这是这些业务人员乐于使用的工具。而开发人员并不一定要使用它，因为访问存储模型的方式是多种多样的，你可以任意选择。
问题是：“如果我们用不同的工具而它们使用不同的存储库，那么如何才能使这些（工具产生的）模型同步呢？”解决办法也很简单：我们在不同的工具和存储库之间创建了一个粘合“层”。这一粘合包含了一个简单web应用，它能够访问存储流程模型的Signavio存储库和存储技术工件的SVN的。基于工件的不同类型，我们做不同的特殊处理。比如从Signavio BPMN模型生成jBPM模型。这种粘合层已经成为了camunda fox的一部分，下面将对此展开具体讨论。
保持业务流程模型和技术流程模型一致是非常重要的，因为这是保持流程模型版本最新的唯一方法。这极其重要，不仅仅出于归档目的，也是为了在业务流程模型一级报告KPI（关键性能指标）或类似指标。当然，我们可以使用相对容易的粘合层达到该目标，而无需所谓的高度精良的零代码工具。
为了说明粘合层怎样发挥作用，我会列举几个截屏来演示。试想某个业务分析师创建了一个业务流程模型，并且已经完成了第一次迭代。他想要将其递交给IT团队以便实现该流程。他通知了技术项目头头告诉他可以开始工作了，这只需通过电子邮件发送一个链接就可以轻松搞定。好了，那现在该项目的头儿有活儿可干了，他需要对BPMN模型做一个操作以便在SVN中创建一个开发项目。这一操作可以通过项目模板来完成，而此模板是由一个从BPMN模型所创建的jBPM流程定义来生成的。我们通过一种自己实现的“特殊的映射”来实现该模板。所涉及的基础映射可以延展到全公司、整个部门、甚至是某个具体项目的规范和模式。即便是BPMN 2.0，使用映射也是有意义的，在我的博客中你也许能找到其中的原因。
接下来，开发人员开始工作，完成所有那些另人繁琐的技术细节，在流程中加入所谓的ActionHandlers，它在流程运行的整个过程中负责执行Java代码。这感觉基本上和其他Java开发项目没什么区别了。
流程没有必要一定要部署到SOA平台才能测试，正常的JUnit测试、持续集成等等都可以。总之，常规的Java和jBPM开发都没问题。
你可能已经猜到Signavio和jBPM模型之间的连接在后台保存。所以一旦开发者有更改行为，我们就可以在camunda fox（web应用）中看到。并不是所有更改所引起的变化都应该合并在BPMN模型中，所以开发人员需要向业务分析人员发送邮件或安排一个切实的会议进行通知。他们可以使用fox GUI来发现简单的区别并将这些更改复制回Signavio存储库中。
事实证明那种方法很奏效。在项目最后，我们所使用的描述性的BPMN图和可执行jBPM流程实现了同步。而大家喜欢它的原因各不相同：BPMN在业务部门得到认可，而这种及时更新的流程描述确实大受欢迎。这种轻量级的开源流程引擎在开发过程中很实用，并且对Java开发人员来说很直观，我认为这是极为重要的一点。正是两者之间的粘合增加了原本缺乏的关联。与此同时，我们在另一个客户的不同项目中也尝试了该方法，并且结果证明同样非常有效。但是请记住这种方法只是个样例；如果你尝试不同的做法，尽管去尝试——使用适合的工具来配合你的需求！
接下来，我们尽力争取另一个“唾手可得”的硕果。因为在不同的模型和粘合层之间有了一个链接，我们就可以有一个中心入口点去提供流程的概貌。我们可以得知有哪些流程版本，哪个版本发布在业务端，哪个BPMN版本作为jBPM流程来部署到引擎，以及在引擎上并行运行着哪些不同的版本等等。
就算在引擎上，也可能存在不同版本的流程同时运行。这些链接也可以显示一些用来测量运行在jBPM引擎上的流程在BPMN级别的KPI。如下图所示。
坦白地讲，我们在这儿所做的只是冰山一角！将此作为出发点，有无限的可能对粘合层进行扩展。一个有趣的方向是对分布式团队（比如离岸外包项目）进行支持。这种情况下你需要更多的交互功能。这些功能包括比如讨论流程模型并归档关联的讨论邮件。这离构建一个通用访问点访问存储库和工件，能够让它们互相标示、连接或与流程模型连接起来的想法只有一步之遥。这使得以Word文档记录的项目订单实现可追踪性，并且可以在网络硬盘上保存BPMN图形和技术模型。目前我们正在开发一些不同类型的标示和虚拟文档以期提高客户体验和整体感觉。你可以通过查询Activiti Cycle Vision继续了解这方面类似的发展方向。
一个更有趣的方向，也是我们想要在接下来的客户项目中攻克的是提供更好的流程测试支持，这在我的博文中有所描述。还记得我提到过我们目前正在做的一个数据流原型吗？它能够动态显示被处理数据的数据流，该数据在BPMN级别上依附于流程的Java类中使用或产生。
这种数据流原型会特别便于使用，如果你要实现“只需”调用服务的高度自动化流程，你会花大量时间纠结于这么一个问题：“我需要哪个数据，而这个数据是由谁在何处创建的？”最后，也是最重要的是，我觉得将流程和规则相结合具有巨大的潜力。不是什么新鲜事儿是吧？开放的粘合层使得你很容易地在业务级别通过决策表来创建规则，并且把规则和BPMN流程模型关联起来。在可执行流程中，这归结为Java代码的一小部分，比如说，JBoss Drools，一个绝妙的开源规则引擎。虽然一些大的厂商已经提供了类似的东西，但是我们的方法也将会把这一功能引入到开源世界中。
希望我已经描述清楚了如何使得业务流程模型和技术流程模型同步这一想法。我想要概括的是有一种实用的方式创建一些简单的工具来支持你所需要的方法。此外，既然它是开源的，并且具有可扩展性，那么你就可以利用它来实现你自己的想法，扩展它以满足你的需要。我们已经有了使用这种方法的良好经验，而我们也将会继续开发camunda fox，在未来不断的试点项目中与客户携手一起努力。
当然，camunda fox也不是什么灵丹妙药 ;-)但是如果你的项目里用到了（Java）开发，那我认为值得你花时间去尝试使用camunda fox并给我们提供反馈意见！我们每天还在学习很多新东西，而我很好奇我们最终会在哪里停步。我坚信，不管怎样，我们投入的所有精力终将会得到一个截然不同的方法用以开发以流程为中心的应用。好消息是：我认为这对大家都有好处。
