如何让CMMN发挥出它的潜力。

如何让CMMN发挥出它的潜力。

 

在对象管理小组（OMG）在2014年发布CMMN规范之前，Camunda就已经开始构建CMMN引擎。在随后的几年中，我们投资了符号支持，建模功能和管理工具。

但是，几年后，我们决定不再向Camunda添加任何CMMN功能，并且将对其进行简单维护，但不会得到完全支持。这篇文章是关于Camunda及其社区对CMMN标准的体验，以及如何导致我们做出选择的，首先拥抱，然后与CMMN保持距离。

CMMN的承诺

案例管理模型和表示法（CMMN）的引入是业务流程模型和表示法（BPMN）的广泛普及的直接结果，旨在解决不可预测的流程的概念。

BPMN标准旨在对可预测，可重复的过程进行建模。但是，这被解释为一个死板的符号，无法正确表示主要由人类“知识工人”精心策划的不可预测的过程。

CMMN旨在解决此问题，它是一个刚刚成立的小组创建的非常成功的建模标准的专用注释。发布时，有关CMMN的宣传大肆宣传，并且会议上充斥着行业专家，他们谈论着现在可以对不可预测的流程进行建模的情况下，存在哪些创新可能性。

实际上，炒作太多了，以至现有的BPMN供应商（包括Camunda）都在迅速探索为其实现工具的方法。像BPMN一样，标准将是具有可执行元模型的可视模型，以便图形模型中构建的内容可由引擎执行。建模人员和引擎需要构建并推向市场，但是由于非常热情的观众在等待CMMN，这似乎是一笔可观的投资。

Camund对CMMN的拥抱

意识到可执行的案件管理解决方案的潜力，Camunda自己的Falko Menge加入了OMG的CMMN工作组，并与其他成员一起制定了标准。

我们迅速采取行动拥抱CMMN，作为一家以Java BPMN引擎而闻名的公司，我们决定从CMMN引擎开始。与BPMN一样，我们假设其他供应商正在构建CMMN建模器。知道它们都符合标准后，用户可以在建模工具中对CMMN图进行建模，然后使用Camunda Engine执行该模型。在发布标准的同一年，我们发布了引擎。

构建bpmn.js，该基础项目在许多BPMN和工作流项目中无处不在。在已经看到成功的前提下，我们开始构建cmmn.js，以便在具有引擎实现的同时，以具有功能齐全的建模器为目标的可视化表示形式，早在1.1版的最终实现Camunda Modeler。

难题的最后一部分是在运行时使用的工具。为此，我们在管理工具座舱中添加了CMMN查看器，以便管理员可以查看部署的案例正在发生的事情和已经发生的事情。

在发布CMMN规范仅短短几年之后，Camunda就拥有：

1. 开发了开源CMMN引擎
2. 开发了CMMN建模器和查看器
3. 创建并提供专家培训
4. 开发了管理工具，使CMMN在生产中更容易实现

可以公平地说，我们不仅希望CMMN取得成功，还积极争取使CMMN在各种会议上成为主题演讲的主题，并渴望找到成功的案例。

CMMN的缺点

随着时间的流逝，CMMN的问题慢慢出现了。 很明显，即使是最复杂的案件管理流程，仍然具有很多可预测的部分，而CMMN显然很不擅长。这意味着在现实的用例中，必须将CMMN与BPMN结合使用。

表面上没什么大问题，您已将BPMN用于可预测的可重复部件，而将CMMN用于不可预测的动态部件上。实际上，IBM甚至采取了一些CMMN功能并将其添加到自己的BPMN中。

在对CMMN进行人员培训时，很明显，该符号具有陡峭的学习曲线，BPMN相当直观且易于遵循，与BPMN不同，即使我们经过非常基础的培训，CMMN还是很难立即掌握。比如人们对从何处开始阅读CMMN都会感到困惑。更糟糕的是，由于其设计，要预测给定模型在给定情况下可能发生的事情实际上是非常困难的，原因是因为：很多行为都隐藏在CMMN规则中，而不是明确地建模符号。例如，知道哨兵将如何触发的唯一方法是设计人员是否偶然向其添加了文本注释。

之所以会有这样的问题，是因为可执行图形模型的基本思想是，它可以作为通用语言，充当开发人员和设计人员之间的桥梁。BPMN之所以成为标准，主要是因为这两个团队都接受BPMN。但是，在很多情况下，CMMN太难理解了，学习起来也困难，尤其是对于那些已经学习BPMN的人而言。

因此，在发布引擎后不久，我们就与客户联系以征询他们对CMMN采用经验的反馈。我们发现，人们不必使用来自Camunda的引擎，而必须使用其他供应商的建模工具。因此，我们预计在发布建模器后会看到价格上涨。不幸的是，那从未发生过。因此，我们回头问我们的客户，他们认为采用CMMN缺少什么。这次的反馈很明确-我们需要在CMMN中使用与BPMN相同的管理功能。 、

不只是我们。自从使用CMMN并开始运行以来，最初的热情似乎已经烟消云散，与CMMN互动的人越来越少。

Camund离开CMMN

在2019年9月，我们的联合创始人发布了Real-Life BPMN的第四版，他们选择删除CMMN上的章节。他们描述了为什么做出这种选择：

我们给CMMN腾出了两年的时间，但是在那段时间内，我们在项目中从CMMN中获得了有限的价值，尤其是当您将其与BPMN或DMN比较时。例如，一种观察是，如果某些活动是可能的，不可能的，强制性的或不必要的，则CMMN模型中的大多数逻辑都隐藏在复杂的规则集中。这些规则通常在其他地方表达，也没有以图形方式表示。有点夸张，CMMN模型变成了一种图形的项目符号列表。因此，我们决定从本书中删除CMMN，以免使刚开始BPM之旅的任何人感到困惑。相反，我们想强调如何使用BPMN处理非结构化流程……并指出这种方法的局限性。

值得一提的是，我们可以得出结论，实际上，人们不希望使用我们的软件（而不是CMMN）。但是大约在同一时间，DMN发布了，我们突然了解了为一个充满活力和动力的社区构建工具的感觉。

尽管遵循相同的采用路线图，但DMN的使用体验却完全不同。我将再一次介绍我们采用DMN的故事。因此，我们面临一个简单的问题：我们是应该花更多的时间来尝试发展CMMN社区，还是应该向DMN投入更多的资源，DMN的社区已经在更快，更热情地采用该标准？避免浪费时间在不需要的功能上也是我们对客户和社区的责任。

此时的决定与我们是否应该停止支持CMMN无关。

人们仍然将Camunda用于CMMN，但是大多数人只是将他们的CMMN案例重新构建为BPMN模型，这是我个人非常喜欢的事情。

Camunda现在的未来是BPMN和DMN，这是社区为我们做出的决定。正如我们之前建立的那样，我们的决定很大程度上是根据我们从您自己这样的社区成员那里获得的反馈而做出的。