与业务相关的操作规範、管理章程、规章制度、行业标準等，都可以称为业务规则（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会使那些非技术用户更容易发现问题，并能够方便地进行更改。同样，随着时间的推移，这也会形成更多业务友好管理规则。