One of the interesting and useful things about the Decision Model and Notation (DMN) standard for decision models is how it handles the data required by a decision. Simply put, a Decision in DMN may have any number of Information Requirements and these define its data dependencies – the Decision requires this information to be available if the decision is to be made. These Information Requirements may be to Input Data (what DMN calls raw data available”outside” the decision) or to other Decisions. Because making a decision creates data – you can think of making a decision as answering a question, producing the answer – Input Data and Decision outcomes are interchangeable in Information Requirements. This has lots of benefits in terms of simpler execution and isolation of changes as models are developed and extended.
Recently a group I belong to was asked (indirectly) if an Information Requirement can be met by a Decision in one situation and an Input Data in another. The context was that a specific decision was being deployed into two different decision services. In one case the information this decision needed was supplied directly and in the other it was derived by a sub-decision within the decision service. For instance, a calculated monthly payment is required by an eligibility decision that is deployed in two decision services – in one it is calculated from raw data input to the service and in the other it is calculated and stored before the service is invoked and passed in to the service.
This question illustrates a critical best practice in decision modeling with DMN:
If the information is ever the result of a decision then it is always the result of a decision.
The fact that it is calculated inside one decision service (because the decision is inside the execution boundary) and outside the other (the decision is outside the execution boundary and supplies information for a decision that is inside it) does not change this. This should be shown in every diagram as a decision. If it must be decided then it’s always a Decision and if it just input as-is to the decision-making then it’s Input Data. The fact that its value is sometimes stored in a database or passed it as an XML structure and then consumed as though it was a piece of data does not change its nature.
Why does this matter? Why not let people use Input Data when it is “looked up” and a Decision when it is “calculated”? Several reasons:
- Having two representations makes impact analysis and traceability harder – you will have to remember/record that these are the same.
- More importantly, there is an issue of timeliness. Showing it as a piece of data obscures this and would imply it is just “known” instead of actually being the result of decision-making.
For instance we had a situation like this with a Decision “is US entity”. This is a decision taken early in an onboarding process and then stored as a database field. This should always be shown as a Decision in a decision model, though, as this makes people think about WHEN the decision was made – how recently. Perhaps it does not matter to them how long ago this decision was made but perhaps it does. - DMN has a way to show the situation described. A decision service boundary can be defined for each decision service to show if it is “passed in” or calculated.
I would never show this level of technical detail to a business user or business analyst but it matters to IT. The business modeler should always see it as a Decision (which it is) and simply notes that they have another Decision that requires it. They can treat it as a black box from a requirements point of view so it does not make the diagram any more complex – it just means its a rectangle (Decision) not an oval (Input Data).
This is the kind of tip Jan and I are working to bring to our new book, Available now! Real-World Decision Modeling with DMN.
