Rules of Engagement

6th of May 2016

Rules have been always been a part of business processes. They present a way to evaluate decisions that need to be taken so that a business process instance can be guided down the proper execution path. And ever since the Decision Modeling Notation (DMN) had its first formal publication in September of 2015, we are moving towards a more formalized way of describing these decisions. We even have Bruce Silver publishing a book giving this new notation the method and style treatment. However, this is not the first specification of the Object Management Group surrounding this topic. In the past, the Semantics of Business Vocabulary and Rules (SBVR) specification was the go-to model for business people to work with decisions, more often than not part of a business process.

So how do these two specifications relate to each other? Has SBVR become obsolete or is it complementary to DMN? SBVR has had a its most recent publication in May of 2015 without any mention of DMN in its texts, and DMN only lists SBVR as a non-normative reference with some obscure reference to it being more expansive than just some way to constrain a business rule task from BPMN.


Quoting from the DMN specification, its raison d'être reads as such:

The primary goal of DMN is to provide a common notation that is readily understandable by all business users, from the business analysts needing to create initial decision requirements and then more detailed decision models, to the technical developers responsible for automating the decisions in processes, and finally, to the business people who will manage and monitor those decisions. DMN creates a standardized bridge for the gap between the business decision design and decision implementation. DMN notation is designed to be usable alongside the standard BPMN business process notation.

Max Tay, BPM Architect over at NBN Australia, sees SBVR as a structured business speak of decisions, which form business artifacts (such as corporate policies), which in turn guide the design of business processes, and are represented as DMN rules. He provides a nice diagram (see below) to sketch out all the dependencies between the specifications.

The FEEL component of the DMN does seem to have a stronger inclination to IT people (being very similar to pseudo code or even actual code) than the almost natural language of SBVR (which creates a significantly lower threshold for business people to adopt it). And since neither is executable at this time, I see no reason to drop the usage of SBVR in favor of FEEL.

Also to consider: Most documents seem to be using the terms “decision” and “rule” as interchangeable things, whereas specifications such as RuleSpeak tend to explain the difference between the two.

Business Rule: A rule under business jurisdiction, a guide for conduct or action. A standard on which a decision or judgment may be based.
Business Decision: A determination requiring operational business (or strategic or governance) know-how or expertise. It is the resolving of a business question by identifying some correct or optimal choice.
This seems to indicate that rules will always lead to production of knowledge, with the results of a rule being traceable and understandable by informed business people responsible for running some business. Decisions tend to take a more elusive approach. We will have deterministic decisions, providing the right answer, and inferential decisions, providing the best answer out of several, and finally probabilistic decisions stating that there is probably an optimal answer.

My feelings on the matter seems to veer towards the battle of standards not yet being fought to its conclusion, and remind me strongly of an XCKD comic to such effect. If I were a betting man, I would put my money on DMN, provided that they mature into a completely executable notation, which as I mentioned earlier, at this point still isn’t the case.

Thought BPM Decision Management