最近一段时间，提升 SOA 实现的尝试中包括了它与 BPM 之间的整合。 James Taylor 说，在这项工作中存在被遗漏的环节，那就是对业务规则的管理：
不要只顾 BPM 或者 SOA 而忽视了规则——未来将会涉及到规则、BPM 和 SOA 三者。业务规则给了你具有灵活性和一致性的敏捷，这会帮助业务不断成长。它们会帮助你区分并暴露出你需要驱动业务的“把手”和“杠杆”。
Jim Sinur 提出规则为什么很重要的问题，针对这条发言，Taylor 发表评论，概述了管理业务规则和决策的价值：
- 通过监控警告信息并指出根本原因，防止不可接受的类型和级别的风险
- 通过监控利益干系者和影响者，最小化产生风险的可能性，从而接受执行业务的必然的后果
- 通过识别事件并实现快速响应来把握机会
在 Sinur 的发言中，他描述了 Gartner 关于规则的观点。那是具有适应性的软件的基础，它会平衡明确的规则和寻找目标的能力。它们还作为对过程的业务控制的第一驱动力而存在。
Jim 对其观点进行连续地描述——从少数将所有的规则都嵌入到系统中的公司，到大多数将规则和过程混合的半结构化的公司，直至极少完全基于规则的、动态的公司。当前，市场的曲线正处于上升的阶段，但大多数公司仍然会坚持明确的指导规则，其中带有少许更加复杂的指导。一旦市场成熟，那么一些公司就需要从过去的规则导向的过程行为转变为规则驱动的组合方式和基于规则的动态过程。
Tom Graves 对 Taylor 发布的文章做出了评论，他说：
这是一篇好文章——推荐大家阅读。我非常同意其中的观点，我们对于与业务规则相关的原则，有真实并且急切的需要…但是，读了它之后，几乎所有我的企业架构的警告都没有了。它将业务规则提升为“答案”——对于基于 IT 的业务规则引擎的大部分是那样的。
根据 Graves 的意见，这个方法与其他失败的 IT 驱动的业务——如业务过程重构——非常类似，：
- 将所有业务规则都放到自动的系统中，那会导致“适应并遗忘（fit and forget）”的态度，除非在规则维护上做了非常重的强调——大量在 BPR 中被遗忘的“人为因素”会对“IT-ise”的所有业务过程产生很大的冲击。
- 在对业务规则的识别和编写的时候，我们会假设规则可能来自于运行现有过程的那些人，这些规则是充分、不变、准确和完整的——然而，正如早期的知识管理所发现的，事情往往并非如此……
- 在制定决策的时候使用自动化的方式是否可行，要依赖于具体的环境，让我吃惊的是，似乎很少有 IT 系统设计师了解这个事实。
Graves 说，Taylor 的方法的缺点在于，当 IT 负责实现业务规则的时候，情形会非常不容乐观。IT 的主要能力在于支持基于二进制的真伪逻辑的简单业务规则。当需要处理非二进制逻辑的时候，比方说模态逻辑或者机率逻辑，人会表现得更好。IT 在模式识别方面（如人脸识别）变得越来越好，这是基于与现有的模式和图片进行比较的基础之上的，但是如果有现实环境中的干扰，那么就无法表现得尽如人意了，因为在那种情况下，模式不为其所知或者根本就不存在。因此，针对业务规则自动化的 IT 方法可能是这样的：
一切……都被降为简单的规则，按照本末倒置的想法，所有一切都应该由 IT 完成，而简单规则正是 IT 最容易掌控的。也就是说，这种前后颠倒的做法是非常危险的。试图从 IT 中提取出某些有用的信息来做决策支持已经非常不好了；但是对于所有的决策都使用 IT——那是文中显然最喜欢的理想状况——似乎更是致命的。我不是很清楚，作为企业架构师，我们能够采取什么样的措施来防止这样轻率地一味地重复在 BPR 和其他过程中已经犯过的错误，而区别就在于这次它是更明确地来自于过程的规则部分，而不是总体上的过程实现部分。
Richard Veryard 同意 Graves 的观点，他指出：
- 我们不应该假设业务规则已经是充分、不变、精确和完整的，尤其是当它们来自于运行现有过程的人。这样对业务规则的识别和编写一般就会留下一些需要请求的。（这样做的方式之一就是真正地抵制符号表现方法）
- 对于规则的维护应进行着重强调，否则就会将所有业务规则放在一个自动的系统中，从而导致“适应并遗忘”的态度。(这样做的一种方式是要求进行双重循环或者二次学习）
- 使用自动化的方式来制定决策是否可行依赖于具体的环境。
我们很难反对 Veryard 的观点。在我们的实现中包含业务规则的自动化肯定是很重要的。而决定哪个应该自动化，哪个应该由人来执行也是很必要的。
评论