驰骋 bpm_实际BPM的协作方法

驰骋 bpm

我们已经在业务流程管理（BPM）领域中工作了多年，很有趣的是，最近对它的关注日益增加。 引起这种兴趣的催化剂可能是工具的日趋成熟，BPMN标准的新2.0版本，由更多出版物引起的更好的理解或BPM方法的改进的先决条件，仅列举了BPM中最重要的几个发展。

供应商提供了越来越多的高级图形工具，这些工具可以使业务流程实现自动化，而无需任何编码甚至开发人员。 但是，我们发现这些以“供应商为中心”的“传统”方法存在问题：它们无法兑现这些承诺！

让我给您一些示例，以支持我们先前项目中的这一说法。 没有命名具体的工具，因为大多数工具都存在相同的基本问题，因此这是不公平的，同事不得不使用小型Web GUI来实现简单的过程。 该工具引入了自己的魔术拖放GUI设计器，在一开始似乎很方便，但是当我们几乎完成该项目时，表单中存在一些小的数据验证要求，而这并不是魔术工具设计的。 为了克服这些限制，我们花在设计人员身上的时间比在纯JSF中实现整个GUI所需的时间还要多，而最终我们还是这样做了。

对于另一位客户，一位开发人员告诉我：“尝试建模某些特殊需求花了超过两天的时间，而这些需求他可以在半小时内直接用Java编写！” 另一个客户试图使事务和有状态服务运行，不幸的是，这需要将调用服务作为Web服务。 在尝试了WS-Addressing，WS-AtomicTransaction并尝试修补几个框架之后，他基本上放弃了并丢弃了整个BPM工具。

下一位客户在较早的推销中就踢出了一家供应商，因为他们想要额外的钱来提供Java API。

所有这些示例都有一个共同点：该工具使开发人员的生活更加艰苦，而不是更加轻松！ 他们没有减少开发时间或金钱。 他们对Business-IT-Alignment毫无帮助，因为所需的技术模型过于复杂，根本无法与业务流程模型保持一致。 您是否看到任何BPEL模型与商人的原始图纸有任何共同之处？

那么，BPM不起作用吗？ 业务IT联盟会不会成为神话？ 当然不是！ 但是，我们必须重新考虑我们进行BPM项目的方式。 在过去的几年中，我们做到了这一点，并找到了BPM如何在现实生活中工作的方法。

简而言之，这更多地是关于协作和对不同角色的尊重，以及让人们按照自己想要的方式工作。 因此，它不是以工具为中心的，因为即使我们需要工具，它也必须适应我们的工作方式。 我们必须制止工具迫使我们以供应商规定的方式工作的情况。 不同的角色将使用不同的工具，因此不会只有一个工具。 即使这看起来很明显，许多工具仍然试图做相反的事情。

我们开发了一种方法，该方法使用BPMN（业务流程模型和表示法）来获得有效的Business-IT-Alignment。 它是关于将流程模型用作协作中心，我们在其中讨论和链接需求，业务规则或其他工件，可视化开发状态，指定业务驱动的测试场景等。 它不仅要对可执行过程进行建模，而且还要对周围池中的组织方面进行建模以使业务和IT视图保持一致。

因此，BPMN提供了很大的可能性：池。 这样就可以在一个模型中对“仅业务”方面和技术方面进行建模，并在它们之间设置正确的关系。 我们在书中对此进行了更详细的描述，并为BPMN官方示例文档提供了示例 。 为了得到我所说的例子，您也可以查看我同事的博客条目 。 总体而言，我们将所有这些视为BPM的真正价值，而不是业务人员的“绘制”可执行流程。

我们已经与一些客户（甚至使用Microsoft Visio）执行了该方法。 但是，在过去的几个月中，我们还开发了工具，以支持一些试点客户，最重要的是，这是德国一家大型电信公司的一个大型项目。 目前，我们以camunda fox的形式发布所有开放源代码，其第一版将很快向公众发布。 我们希望分享我们的经验，通过讨论获得新的想法，并帮助BPMN正确地采用。 然后，它可以为每个人而不是仅向工具供应商的银行帐户传递真正的价值；-)希望我们可以跳过Gartner炒作周期中看到的“幻灭低谷”，尤其是对于BPMN 2.0。

让我们更加具体，看看我提到的电信客户项目。 我们在这里面临的环境基本上是使用大量EJB，一些JMS和少量JBoss ESB服务的Java EE。 流程尚未得到一致的记录，业务部门主要使用事件驱动的流程链（EPC），而IT人员则使用从UML到Power Point的所有内容。 目的是引入BPMN作为业务和IT的建模符号，并作为保持模型的技术和业务流程同步的桥梁。

我们最终实现的目标！ 但是一步一步...

从技术上讲，“ Bopeds” JBoss SOA平台已经到位，这意味着可执行流程已部署到著名的开源流程引擎JBoss jBPM 3.2。 jBPM的决定是在BPEL进行了一些失败的尝试之后做出的，但是这并不适合技术环境。 主要原因是基本上没有服务可以作为Web服务使用，工具还不够成熟，价格太昂贵，缺乏专门知识。 因此，jBPM是使现有Java开发人员参与进来且对开发过程的干扰最小的好选择。 我想在这里指出一个重要方面：像JBoss jBPM或最近的Activiti这样的开源过程引擎更像是开发人员的框架或库，而不是完整的产品套件。 可以轻松定制它们并将其集成到您自己的体系结构中。 它们允许进行单元测试，并且易于理解。

切记：我们希望为不同的角色提供必要的工具。 开发人员对Java，Eclipse，JUnit，Subversion，Maven等感到满意。 因此，他们应该能够继续使用这些工具！

业务分析师拥有商业版Signavio版本 ，这是业务分析师满意的工具。 开发人员没有被迫使用它，因为它足够开放以不同方式访问存储的模型。

问题是：“如果我们有使用不同存储库的不同工具，如何同步模型？” 解决方案很简单：我们在不同的工具和存储库之间创建了一个胶水“层”。 这种胶水包含一个简单的Web应用程序，该应用程序可以访问Signavio存储库以获取过程模型以及SVN来获取技术工件。 根据工件类型，我们可以执行特殊操作。 例如，从Signavio BPMN模型创建jBPM模型。 该胶层成为金刚狐的一部分，稍后显示。

保持业务流程模型和技术流程模型同步非常重要，因为这是保持业务流程模型最新的唯一方法。 这不仅对于文档目的非常重要，而且对于报告业务流程模型级别的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已在业务部门接受，并且对最新的过程文档表示赞赏。 轻量级的Open Source Process Engine在开发中非常方便，并且对于Java开发人员来说是直观的，我认为这是最重要的一点。 两者之间的粘合增加了两者之间缺少的联系。 同时，我们在另一个项目中与另一位客户一起尝试了这种方法，并且在该方法中也很好用。 但是请记住，这种方法只是一个示例； 如果您想以不同的方式工作，请以不同的方式工作并调整工具以适应您的需求！

接下来我们尝试收获另一个“低垂的果实”。 因为我们在不同模型和该胶合层之间建立了联系，所以我们可以有一个中央入口点，以提供有关过程的概述。 我们可以看到存在哪些版本，在业务方面发布了哪个版本，在BPMN版本上将其作为jBPM流程部署在引擎上，在引擎上并行运行了哪些不同的版本，等等。

即使在引擎上，也可能会并行运行不同的版本。 这些链接也可以用于显示在BPMN级别上在jBPM引擎中测量的KPI。 下图显示了这种情况的示例。

老实说，我们在这里所做的只是冰山一角！ 以此为起点，有很多可能性来扩展该胶层。 一个有趣的方向是支持诸如离岸项目等分布式团队。 在那里，您需要更多的协作功能。 诸如讨论流程模型和归档链接的电子邮件讨论等功能。 与拥有对存储库和工件的通用访问权并能够将它们标记并链接到流程模型或彼此之间的想法仅一步之遥。 这允许从用Word编写并保存在网络驱动器上的项目订单到BPMN图到技术模型的可追溯性。 我们目前正在引入某种标签和虚拟文件夹，以改善用户体验和概述。 如果要给它留下另一种印象，您可以查看Activiti Cycle Vision ，它在此边缘上朝着相似的方向前进。

正如我在博客文章中所述，在即将到来的客户项目中，我们要解决的一个更有趣的方向是为流程测试添加更好的支持。 我是否提到过我们正在开发一个原型，以便能够动态显示在BPMN级别附加到流程的Java类中使用或生成的已处理数据的数据流？

如果您实施高度自动化的流程来“仅”调用服务，这将特别方便，您将最大的时间花在了以下问题上：“我在哪里拥有哪些数据，谁创建了这些数据？” 最后但并非最不重要的一点是，我发现将流程和规则结合在一起的巨大潜力。 不是新的？ 开放的粘合层使您可以轻松地在业务级别的决策表中创建规则，并将其链接到BPMN流程模型。 在可执行过程中，这归结为Java代码的一小部分，例如调用了出色的开源规则引擎JBoss Drools。 尽管一些大型供应商已经提供了类似的功能，但我们的方法还将把该功能也带入开源世界。

我希望我给了您关于我们如何使业务流程模型和技术流程模型同步的想法。 我要概述的是，有一种实用的方法可以构建一些简单的工具来支持所需的方法。 此外，由于它是开源且可扩展的，因此您可以采用它并实现自己的想法，从而扩展工具以满足您的个人需求。 我们已经在草图方法方面拥有非常好的经验，并且我们将继续与客户合作并通过正在进行的试点项目来研究和开发Camunda Fox。

当然，camunda fox也不是灵丹妙药；-)但是，如果您的项目涉及（Java）开发，我认为值得您花时间尝试camunda fox并给我们反馈！ 我们每天仍在学习很多东西，我很想知道我们最终会走向何方。 但是，我坚信，所有投入的精力都将导致在开发以流程为中心的应用程序方面出现根本不同的方法。 好消息：我认为这对每个人都有益:-)

翻译自: https://www.infoq.com/articles/collaborativeBPM/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

驰骋 bpm