In part 1, we talked about a number of ways to formalize knowledge, one being the Decision Model and Notation (brought to us by the OMG). Here we will look at some of the concepts used in DMN, and how they can be used to collaborate around the decisions of an organization.
DMN basics
The notation defines 4 building blocks: the decision, the input data, the business knowledge model, and the knowledge source.
They are represented as shown below.
Source: DMN Specification 1.0 (beta)
Simply enough, a decision determines an output based on one or more inputs. An input data block is information, used as input by one or more decisions.
To indicate that an input data block is an input to a decision, a link terminated by an arrow is drawn from the input data to the decision; it is called an information requirement in the DMN standard.
Similarly, the output of a decision may be used as an input to another decision: an information requirement would therefore link them.
With only decision and input data blocks, it becomes possible to start with a top-level decision, identify its inputs and output, and then, one step at a time, decompose that top-level decision (if required) by adding more decisions used as inputs to that top-level decision; and so on, until a proper level of granularity is reached.
Note that at this stage, we are not interested in the decision logic itself (this will come later).
Business knowledge models, knowledge sources
A business knowledge model represents knowledge that is encapsulated: basically it is a black box for whatever is able to provide a decision with knowledge. This could be a set of business rules, a decision table, an analytical model, etc. Such blocks in a decision model diagram therefore indicate how a decision is being made (given its inputs and outputs).
A knowledge source block represents the authority for a business knowledge model, or a decision: this is where the actual knowledge can be obtained (a manual, a book, a subject matter expert, etc.).
The link connecting a business knowledge model block to a decision block is called a knowledge requirement. The link connecting a knowledge source to a business knowledge model or to a decision, is called an authority requirement.
After a while
Once you have iterated over your decisions to decompose them, added the required inputs, provided business knowledge models to them, and annotated all of this with knowledge sources, you end up with a nice visual representation of your decision. It could look like this:
Source: DMN Specification 1.0 (beta)
Getting closer to the business logic
Then comes the time to actually describe the business logic, by providing “meat” to those business knowledge models (or directly to those decisions).
The DMN standard provides another simple and well-known means to describe decision logic, in the form of decision tables. The content of the decision tables can be just any piece of text, but you can optionally also decide to go with DMN’s dedicated language (FEEL).
Source: DMN Specification 1.0 (beta)
Use the DMN diagram to collaborate
The DMN diagram is meant to be a living creature during the project lifecycle: it should be continually refined as new information is discovered or provided. It should therefore be kept up-to-date not only for internal documentation, but also as a means to communicate with all the teams that are part of the project.
This would also include Business Analysts or IT, as the diagram (and the attached business logic) can be used as a reference for the actual implementation of the decisions. Similarly, should changes be made to the executable decisions, these changes would need to be retrofitted into the DMN diagram.
As the saying goes, a picture is worth a thousand words. DMN, thanks to its visual representation of your decisions, makes them easy to talk about.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
