業務規則

與業務相關的操作規範、管理章程、規章制度、行業標準等，都可以稱為業務規則（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會使那些非技術用户更容易發現問題，並能夠方便地進行更改。同樣，隨着時間的推移，這也會形成更多業務友好管理規則。 ^[1]