What is a Decision Requirement Diagram (DRD)?

In the last post, we discussed how to use different decision tables in an orchestration as a decision flow. In this post, we are using the same bases on the implemented decision tables, but this time we will link them together using a Decision Requirement Diagram.

Decision Requirement Diagram

DRD or Decision Requirement Diagram is a graph model that allows you to define a hierarchical decision. This graph works based on dependencies of nodes and is part of the standard called Decision Model and Notation (DMN). It simply connects multiple decisions (and other type of nodes in the graph) to each other based on their dependencies.

The model shown below is a sample Decision Requirement Diagram (DRD) for calculating a car premium. The “car” and “High theft probability auto list” are the “Input Data” for this DRD:

Dependencies and Implementation

In the above model, the top decision is “Car Premium” which depends on “Base Premium” and “Auto Premium” and then the “Auto Premium” depends on “Car Style Premium” and “Determine Rating” and lastly “Determine Rating” Depends on “Potential Theft Rating” and “Potential Occupant Injury Rating“.

Now each of the Decision nodes (i.e., blue rectangles) and business knowledge nodes (i.e., cross cut green rectangles) can implement the logic using Decision Table, Tree or Sub-tree, Natural Language, and so on.

Hosting as a Service – Decision as a Service

The whole Decision Requirement Diagram (DRD) model can be hosted as a service. This is called Decision as a Service which allows any other applications and/or systems (e.g., BPM) communicate with this DRD by passing the input parameters. Then the DRD will be executed on the server side, and returns the result back to the caller. To publish a DRD as a REST API service, FlexRule Server is used.

Once a DRD is published as a service, all other aspect of it can be managed (i.e., security, permissions and roles, versions, time based scheduling , etc.).

Orchestration of Data and Reusability

A Decision Requirement Diagram (DRD) can be used as part of a flow task. In the following orchestration, “Premium Calculator DRD” is a DRD task that is linked to the above model.

Flow tasks for a DRD allows reusability of the model. This reusability is not only possible via a task in a flow but as a function across all other models.

Conclusion

A Decision Requirement Diagram (or in short, DRD) is a graph model that allows you to model hierarchical decisions using a graph. This enables a higher level communication with stockholders and allows one to approach the decision modeling in an intuitive way, rather than thinking in rules initially and trapping yourself in the big bucket of rules problem.

So next time you start modeling rules, first think of which business decisions you are trying to make, and how those decisions will impact other decisions.

Read More

1. Natural Language Business Rules Modeling in DMN
2. Assessing Borrowing Capacity Using Decision Automation
3. Why Automate Insurance Pricing Model?
4. Insurance Premium Calculation
5. Import DMN models – XML 1.1
6. Boxed Expressions – DMN
7. Decision Model and Notation – DMN
8. Reusable DRD or Sub DRD in Decision Model and Notation (DMN)
9. Decision model and Notation – Policy Example
10. Reuse Business Decision as a Function

Last updated October 6th, 2020 at 06:33 am, Published April 21st, 2015 at 06:33 am

Arash Aghlara

CEO and the founder of FlexRule – He is an expert in architecture, design, and implementation of operational decisions, business rules, and process automation. Created Decision-Centric Approach, a methodology that brings People, Data, Rules, and Processes together to automate operational business decisions.

This approach is recognized by Gartner as the missing link to provide business value to organizations.