业务规则引擎可以分离出流程的关键决策逻辑，用比应用代码更加有好的业务语言。抽象概念层更快速简单地交换规则，但是增加了系统复杂性。

　　使用业务规则引擎，你可以避免在一个小的IT项目中编辑每一个规则。本文探讨节省时间等的利益，提供专家、用户和分析师使用规则引擎的优势和困难的意见。

　　业务规则可以植根于流程，接触跨系统数据和服务。根据顾问、作者和开源传道者Jeff Genender所述，如果这些规则是硬编码到应用程序本身，开发人员可能需要花费一些时间，确保在各接触点认可的变化。

　　Genender解释到业务规则引擎用很小的决策点，遍布整个工作流程的应用，使它们通过一个集中的语法层。用户可以通过一个通常使用的界面访问规则，在声明语句呈现他们，如：“客户利益优先地位，如果帐户的总价值>十万美元。”

　　这种方法可以用于与业务流程管理（BPM）系统，虽然不是通常的情况结合。

　　Genender表示BPM系统在许多方面上类似规则引擎，但是没有抽象出语法层。如果一个公司想要业务用户管理和更新规则，该层或许很重要。

　　Forrester研究分析师John Rymer指出一些业务规则比其他的改变的更加频繁。

　　Rymer说：“你不会一时兴起改变自己的账户策略，如果你在适当的地方调整策略存进银行，像Patriot Act，这些事情不会瞬间改变。但是他们进行了改变。”设计策略的区域像折扣、促销和销售可以经常改变。

　　不幸的是，还没有明确的规则标准，Rymer表示，在像“SQL规则”之前，还需要一些时间。

　　缺乏标准，这使得小心选择一个规则引擎变得重要。分析师和用户都都提出了这样的问题：很难从一个引擎移植规则到另一个引擎。通常情况下，很难采用规则，甚至从一个内部的应用环境下的另一相同的规则引擎。 Rymer说，他已经听到许多公司的抱怨，这些公司部署了规则引擎，从来没有得到比在其第一个项目中更广泛的使用。

　　系统设计师Nicolai Josuttis在他的著作《实践中的SOA》中写到，自从面向对象编程成为主流，“有一个共同的业务对象模型（BOM）成为总目标。”业务对象是一个实体的业务领域的编程表现，如客户订单。规则通常用于执行公司与这些对象相关的政策。不幸的是，BOM的竟然给大系统造成了灾难，Josuttis补充。

　　“由于是大型分布式系统通常有不同的所有者，很难达成协议，”他写道。“要么你没有满足所有的利益，或者你的模型变得过于复杂，或者它只是从来没有完成。”

　　斗争就变成确定如何对您的业务逻辑处理，通过集中决策点，对比与内部个人域。虽然应用程序运行时为同样的规则重复检查的性能支付罚金，Josuttis写到，消除冗余，更多的工作对企业来说是值得的。

　　在实践中，Josuttis建议业务规则中心地带频繁改变，规则引擎就派上用场了。

　　选择BRE或者不选择BRE

　　一些公司发现，通过集中的数据结构，他们可以从他们的系统消除对规则引擎的需求。当北加州电力机构（NCPA）首先加强了其面向服务的架构，它包括了IBM公司的ILOG规则引擎。将几个项目捆绑ILOG后，NCPA结束了建立自己的规则管理系统，IT经理Mark Myers说道。

　　NCPA的企业架构使用Zachman框架作为项目的一部分。跟随着这个框架，Myers表示团队采用一个非常正式的方法来定义术语，业务流程的确立和规则的分类。从这些中，公司将详细设计文档放在一起。

　　“要做好规则项目的关键是正确的词汇识别和书写正确的规则，” Myers说。该公司发现，足够好的设计文件，规则引擎并不是完全的SOA需要。

　　在批发电力市场，Myers表示业务规则不是频繁地改变，因此，企业用户并不真正需要一个集中界面改变来时刻的通知他们。

　　有一次，而NCPA正在发展SOA，IBM公司发布了ILOG的新版本。Myers说，当业务规则迁移到新版本时，他的小组做了大量重编码。不用说，重写所有这些规则的工作量是不太欢迎。Myers说，“a ha”时刻到来时，在一个架构会上，有人问：“那么，为什么我们需要一个规则引擎？”

　　因此，他带着很多的工作流逻辑退出ILOG。

　　在这一过程中，Myers说，重要的是保持在“数据对象”和“规则对象”间的抽象概念层，每一种在整个系统中可分开重复使用。对于构架在ILOG仍然运行的部分，规则对象可以通过，而不必修改到规则引擎。大多数规则现在大约需要一天时间来改变。