很少有人比BRCommunity的执行主编Ron Ross先生更了解业务规则，同时他也是业务规则解决方案的负责人和业务规则论坛会议的联合主席。他说当你与大部分公司讨论业务规则时，他们都会说自己已经实现很多年了。但问题是他们是怎样来实现的。

　　他们的基本观点认为，业务规则是制订业务决策的标准。尽管多数公司都有这个标准，但他们并不是非常规范。一个现代的方法是把它从代码中分离出来，插入到引擎中，然后开始解释、编辑并执行。照这样，业务用户可以更快地编辑规则来使流程更符合变化中的业务需求。

　　Ross说：“他们必须从程序化的人工产品——应用代码和过程模型——中取出来， 为了保证业务规则的有效性，首先最重要的一点是通过声明来表达规则的某些公约。”可以采取决策表甚至英语句子的形式来表示。

　　这个想法是以一种业务用户能根据需要快速领会和编辑的方式,在一个储存库中保存所有的业务规则。通过使用这种方法，业务规则在流程模型和数据模型之间充当起了一种协调力量。

　　Ross说如果你考虑过SOA，就会很自然地想到它。他说从架构的立场出发，业务规则应该看成是一种服务。

　　业务规则引擎在企业计算领域已经有很长的历史，最近的有些开发却没有价值。在2009年一月，IBM以3.4亿美元完成了对ILOG的收购，把它的商业规则管理系统（BRMS）引入到Websphere中。在2008年十月，Oracle买下了业务规则竞争对手Haley， 它以能够与Oracle的Siebel CRM在一起良好工作而著称。Oracle拥有两套其他的规则引擎，LogicalApps和RuleRurst。再看2007年，SAP购买了BRMS的提供者YASU，加强了它的Net Weaver 集成平台。FICO（原来的Fair Isaac）已经从2002年开始就提供了流行的Blaze Advisor BRMS并于去年发布的6.7版。Pegasystems，这个领域的另一个强大的选手，提出了以PegaRULES业务规则引擎驱动的SmartBPM。

　　根据这个以及最近一些BPM相关的收购，让Ross备受鼓舞的是爆炸性增长点变得更近了。

　　Ross表示：“我想我们和像IBM这样的公司撞到了一个分水岭，IBM既有业务规则引擎也有业务流程管理系统，还要考虑他们为了更有效的服务该如何结合。”

　　当真正地实现业务规则的时候，Ross推荐名为增量设计的流程。在这种模型下，一个业务开发了一些初始的规则，并能向这些规则路由特别的工作量。久而久之，当更具体的用例变得清晰时，业务可以开发更具体的规则。照这种增量方式，越来越多的工作量就移交给BRMS来自动化处理。