最近John Raynolds提出这个问题：“为什么Java开发者憎恨BPM?”

从自己和他人的经验中，他得出这样的结论：

BPM套件[……]抢走你的创意[并]指挥你如何开发应用软件。BPM套件让编程成为一件烦人的事。它们迫使你使用点击拖放工具来设计过程图、数据模型和窗体。

更糟的是它们竟然鼓励业务人士自己去构建过程模型和设计窗体……

他声称：

Java开发者（大多数）宁愿使用像Struts和Spring这样的框架，也不愿承受来自BPM套件的限制……用Spring或Struts，你可以构造几乎所有东西（如果你已经掌握了Java的错综复杂）。它们是轻量级的、敏捷的，而且在你的履历中看起来很迷人。

我们已经用Java构建了不少工具，这些工具使得通晓Java本身变得并不那么重要。同时也使那些没有学习Java多长时间的人们与我们展开了竞争。

我们成了自己成功的受害者……这正让我们蒙受损失。

这也就是Java开发者憎恨BPM的原因。

读者们也表达了其他不同的理由。例如下面这个读者憎恨BPM是因为：

坦白说，我不认为BPM会是一个有所作为的应用工具……——NetBeans有免费的BPM工具，但它看起来仅仅像一个简单的Web Service自动化工具。它对我所遇到的业务需求和关注问题完全没有用处。即便是更为花哨的工具，例如花哨的高级过程脚本工具，也没能提供多大价值。——没有一个好的BPM套件是免费提供给开发者们使用的，所以很难对之进行试验。它们价钱不菲，我的老板是不会买它们的。

哪里有成功的案例？我非常乐意倾听：给我看一下这种技术在现实中的应用吧。

另一位则认为：

我们憎恨BPM，原因是我们不应当去使用它。BPM的[……]观念是让业务人士去做建模任务，但事实上业务人士并不用它，因此最终我们[在]用。

这位读者对于经常宣传的貌似简单的“点击运行”并不买账：

现实情况是即使给出最简单的过程，那些过程实际上还是在计算机上运行。而电脑……只懂得“做我说的”，而不会“做我的想要的” 。

不管那些线框图表示什么，都需要对这些线框组合所代表的现实有一个基本的了解。很多很微妙的细节包含在“张贴发票（Post Invoice）”泡沫中，并且这些细微之处将突显并影响它们周围的内容。

最终，需要创造这些图表的人还是需要了解电脑和计算技术。这些人是程序员，而且编程要求特定的思路和技术知识。

……所以，虽然在图上可能只显示为一个单一的盒子，但你最好真正了解这"100行J2EE代码"实际在干什么。不管这个小盒子的颜色或形状是什么样的，复杂度依然存在。

作为一个开发者，我……迷惑不解，“什么时候我的系统变得足够大，值得将这一大堆基础设施放入其中——我需要一个本身占用1G内存的脚本语言解释器和运行时” 。

长期以来，抽象很明显已经让我们所有人过得更好。从二进制代码到汇编程序到C再到Java。“一行Java代码代表10行Java字节码，代表100行机器语言指令”。但最好的Java程序员能了解这100行机器语言指令是怎么运行的。新手程序员则因对此不了解而时常受到惩罚。

Robert Perkins曾经使用过BPM工具，他解释了自己不喜欢BPM套件的原因：

去让你的工程师使用如visio这样的流程图工具来编写你产品的下一个版本。他们将被限制使用javascript。他们将没有自动回归测试系统。他们将没有一向所依靠的eclipse或Intellij Idea的任何特色功能。这里也不会有任何构建部署脚本，部署工作将陷入手工拷贝文件。噢，他们将不会有版本管理。

你含沙射影地说那些想使用这些工具而不用能为业务创造最大价值的工具或产品的开发者是为了一己之需。

这确实有些道理。我认为有很多非技术的企业都会相信这一点，它正在制造开发者和企业之间的不信任。我知道我现在的公司就有这个问题，我想很多厂商和销售团队都在利用这一点。

而且就成功的案例而言，我不知道应该信多少。我的公司被列为一个“成功案例”。而现实情况是该项目是一个灾难，最终用户还在抗议中，并且截至今年3月整个开发团队还在继续开发中。

问题不仅仅在于BPM，而是更为普遍。在很多地方，企业是个性化一些业务或表达逻辑的最佳位置。最近Mark Proctor就统一规则和过程引擎是否有益提出疑问，他认为许多过程定义需要更有表达力的规则引擎，而且规则能受益于过程引擎的状态管理能力。Mark补充说：

统一建模环境的一个美景在于你可以选择想要的方式对事物进行建模。

Dave Wright认为这一切都有千丝万缕的联系：

你可以说，在给定的相似的数据模型和条件及事实模型下，规则和数据相比规则和过程而言要更加紧密地联系在一起。我知道你不想分离过程和规则平台，你也想去掉分离的数据平台吗？

Pierre Bonnet关于敏捷链管理系统（ACMS）的分析证实了这一点，他认为MDM, BRMS和BPMS之间有着非常强的联系：

• 主数据管理（MDM）。 引用数据和参数的简化管理，允许服务配置模式的实现将执行置于上下文中。
• 业务规则管理系统（BRMS）。 规则依赖于引用数据和参数。组织服务的前置、后置条件位于规则管理系统中。
• 业务过程管理（BPM）。 过程使用规则来驱动不同阶段的活动。编制服务被MDM和BRMS置于上下文中。

Peter Evans-Greenwood赞成使用一种新途径来定义应用语义:

规则和过程之间的分离只是技术所带来的一种人为结果，并不是我们希望它们如此。分离规则和过程引擎带来了庞大的花费（这是我们可以免除的）。

更富有成效的做法可能来自这个问题的反方向。让我们由上而下来调查人们是如何认识和处理业务逻辑的，然后创造出能够模仿我们的做法的工具和技术。