Figure 1: Process with embedded business rules
The 2 gateways and 3 activities in the process in Figure 1 can be represented as a single decision diagram in DMN:
Figure 2: Discount Decision in DMN (1)
Figure 1’s business process is idealized from the standpoint of true business practices. In reality, discounts and loyalty programs are more complex. They involve many rules and are often bound by a legal agreement that precedes participation in ‘loyalty’ programs. This usually overwhelms simple decision tables and the solution is developed by programmers. Managing this complexity this is precisely the rationale behind many of the features of DMN. Complexity often involves lists of data: orders have details, interactions have a stream of historical events. With the introduction of the multi-instance decision (MID), there is yet another level of process simplification that is taking place: Services that were routinely scripted in one or more activities can be modeled in DMN.
Figure 3: Discount Decision in DMN (2)
In this scenario an order is received from a customer. The order has multiple items and each item has a requested quantity and a quoted price. The order process checks for the existence of promotions for discounts to match marketing and advertising. In the Compute Prices script activity, computer code prices each order line and the total. If a product discount has been assigned, then this is matched to the order line and a discount is applied. With the introduction of multi-instance decisions, the script activity, Compute Prices, in figure 3 can be replaced with a decision model in DMN. The DRD that performs this is shown here:
Figure 4: Discount Decision in DMN (3)
Within the customer order input data, on figure 4, is a complex-type that includes a list of Order Items. The order items include the item number (SCU) and quantity requested. The MID extracts each record in the order line and exposes the quantity for pricing. The multi instance decision is defined with the enclosing shape:
The MID iterates with decisions and expressions over the selected list. The list is contained within the input data-where the input data is either a list or a complex type. The customer order in figure 4 is a complex type that contains a list of order lines. The input data element, Order lines, is automatically placed inside the box when you configure the MID. If a problem has multiple dimensions, the MID can be inside of an MID. You frequently need static data, data that does not change as records are iterated. For instance you might be comparing a number against all the records. To do this the input data should be outside of the MID box. For instance the Special Discount input item in figure 4, remains constant.
The simplified process appears here:
Figure 5: Simplified Process showing the decision connected to the rule shape, ‘Compute Prices’.
The Benefits of the MID
Without the MID, the prices for the customer order would likely be computed in ‘Java Script’ and the solution would look something like:
function compute_prices () { var len = order_items.length var total_price ... for {1=0 ; i < len; i++} { total_price=total_price+order_lines.quantity * order_line; } ... }
This code fragment is not easily understood by the business analysts, let alone created and maintained. There is a little more complexity in the MID as opposed to the simple decision table; however, for the business analyst and other stakeholders there can be these benefits:
- Understandable, control of the business logic of the scenario
- Increased simplicity of business processes
- Simplified SDLC
Often the MID can replace multiple activities and gateways and it can create more powerful solutions.
Discussion
A DMN model is better than code because it uses understandable graphical notation and logic in decision tables and expressions. Decision tables in the Signavio Decision modeler have been designed with many of the familiar controls and concepts of Excel. Surrounding the basic logic of a single item with a MID simplifies the concept of the loop in code. The MID concept is easy to understand and to apply. In addition, simulation and testing allows the designer to precisely create the desired logic. There are many decision use cases that can utilize the MID:
- Many companies have item lists with tens of thousands of items (SCU’s), and they often manage discounts, promotions and configurations with these lists.
- Financial firms had trading floor policies that need to be checked against individual trades and aggregate measures of trades, inter-related logic checks for commissions, market abuse, and other compliance issues
- Decision Logic must decide among sets of supplier bids, scored market strategies a
In the past logic that required lists were relegated to computer coding or scripted process activities. One reason for this was that these type of data sets have not been easily addressed by decision tables or production rules. The MID overcomes this and greatly expands the problems that can be addressed by DMN.