业务规则是指对业务定义和约束的描述，用于维持业务结构或控制和影响业务的行为。业务规则技术的基本思想是将系统处理的业务逻辑从程序代码中抽取出来，将其转变为简单的业务规则，以结构化的业务规则数据来表示业务行为，采用类自然语言来描述，并集中存储在规则库中。业务规则由业务人员创建、实时更新和调试，业务规则之间的复杂逻辑关系由规则引擎处理。业务规则技术改变了传统的、以过程形式处理业务逻辑的方式。

与业务相关的操作规范、管理章程、规章制度、行业标准等，都可以称为业务规则（Business Rules ，简称BR）。业务规则可以从宏观层面上理解可以包括业务的流程、业务条线包括的业务流程等，微观理解可以理解为具体数据项的加工逻辑，例如A指标是有B指标+C指标运算得出的。

业务规则实质上也可以理解为一组条件和在此条件下的操作，是一组准确凝练的语句，用于描述、约束及控制企业的结构、运作和战略，是应用程序中的一段业务逻辑。该业务逻辑通常由业务人员、企业的管理人员和程序开发人员共同开发和修改。它的理论基础是：设置一个条件集合，当满足这个条件集合时候，触发一个或者多个动作。以规则形式捕捉策略语句能提供极大的灵活性和良好的适应性，是企业保持竞争优势的决定性因素。

旧标准的限制

Jacob Feldman是开源BRM供应商OpenRules公司的首席执行官，他说，其实现在，我们可以直接使用 Drools、JSR-94、RuleML和Rule Interchange Format这些老的业务规则标准，但是，在编辑业务规则应用程序时，会受到一定限制。他解释道：“直到最近，不存在规则和决策表象标准，因此，每人都可以创建自己的专属环境。”这些旧标准也只能规范业务规则引擎的接口而已。其实JSR-94兼容器起到的最终作用并不大，因为，现实中很少有企业会真正地实施该标准。

只有在每一个供应商专属环境下编写规范，我们才能够充分利用BRM系统中的强大功能。结果就是，在一种平台上编写的BRM应用却不能够轻松地通过第二种平台。同样地，如果只精通一种系统的IT人员和业务专家们跳槽或者企业决策使用另外一种BRM系统，那么，这些人就需要重新学习一种新工具。

DMN并不会覆盖整个BRM生命周期，它仅仅是做一次规则互换的首次尝试。然而，该行业仍未能完全做到在这种系统中执行规则，但是却可以在其他系统上做到。

Feldman说：“对于规则表象，DMN会为我们带来一些特殊的方面。”然而，DMN却未能解决规则语义相关问题。他说，RuleML正试图代表规则语义，但是，其内部及自身都未能从决策管理方面提供特殊规则。这更像是注重规则的语义Web运动的一次发展，但是却没有被BRM供应商接收。

缺乏标准阻碍实施

Taylor说，缺乏标准对业务规则来说是个需要解决的问题。许多企业都不愿意大范围地开展BRM项目。在如何分析以及设计决策管理架构上达成共识会使该团体在企业如何广泛使用业务规则方面取得成效。

例如，抵押行业和保险行业标准团队对企业间共同的定义规则和决策非常感兴趣。这些标准会让他们采用一种规范方式进行某些事情而非仅仅是文本上的描述而已。

了解DMN的价值所在

DMN阐述了现实中实施业务流程管理（BPM）的最佳实践方式。我们完全可以将业务规则和决策模型融入到BPM系统中。Feldman认为：“DMN使BPM模型变得更加简洁强大，从某种方式上来说，DMN是BPM符号(BPMN)的一种拓展。”

Taylor说，DMN的主要应用案例都将会被直接用于企业实际运作中，而非仅在企业间进行分享。由于企业对业务规则的应用进行了扩展，因为，他们需要聘用精通特殊BRMS符号的员工。为了能够通过使用标准技术和存储库来获取那些规则的核心，企业可以聘用具有更多技能的员工。

Taylor：“我们可以很轻松地找到更多的Java程序员，但是，想要找到规则专家却有些困难。”这些标准可以让我们从专家门的身上汲取经验。他期望采用同样的方式，SQL领域也可以轻松地聘用到更多的数据库人才而不仅是局限于Oracle或者IBM专家。企业仍然对特殊BRM平台技能有一定的需求，但是，大部分工作都可以由DMN专家完成。

Taylor预测，企业用户使用DMN也会变得相对容易一些。许多BRM系统中的设计流程倾向于为许多企业用户模糊化一些规则。DMN会使那些非技术用户更容易发现问题，并能够方便地进行更改。同样，随着时间的推移，这也会形成更多业务友好管理规则。