A decision tree, often also called a decision table, is a specifically formatted table designed to define and preset specific types of inputs, outputs, and the rules that determine which outputs are true when an input is given. In most cases, a decision table is used for informing business decisions, be that the decisions of a person (a business process manager, for example) or a program (like a rules engine). Decision tables do have a specific format, which is designed and agreed upon as a standardized, unanimous methodology by the Object Management Group, or OMG — the same entity that popularized and standardized business process modeling notation for the modern business world. With that in mind, it’s important you know how to develop one yourself, so read on for your own personal decision table tutorial.
Define Your Possible Output(s)
It may seem counterintuitive to start this way, but think about why you’re making a decision table: you’re trying to make a decision, aren’t you? Well, if you’re already aware of the decision you need to make, chances are, you’re aware of your possible outputs. If that’s the case, then you should write them down. You don’t have to add them to the table just yet, but to understand where your decision is going will help you determine what your inputs for said decisions need to be. You won’t use unnecessary triggers and inputs for decision-making if you know where they’re headed!
Identify Your Possible Inputs
In every decision table, it’s essential to have an input field. Whether it’s one input per decision, or various inputs that each have rules and qualifiers of their own, the input should be whatever goes into the decision point in a process. If the decision table embodies the beginning and end of the process as a whole, then you’ve got your work cut out for you in the beginning, with the input of the process filling that far left field on the table. However, if there are multiple decisions to make within a process, it’s all the more likely that you’ll have multiple decision tables, and for each one, you’d need to be more specific with your input. What does the information in a process look like before it enters the decision point? Whether it’s a weather condition, a dietary preference, or another piece of information, there’s always something that gives your decision table an “input”, if not more than one.
Outline Your Rules And Conditions
There’s more than the input field that comes from the process: your decision table’s input also has to involve rules. Whether it’s a predefined condition that can be verified as true or false, or whether it’s a mathematical qualifier like a “Cost” value greater than 8, you have to involve some sort of validation in order to determine what the input fields of the table mean — and to what output they will give way. The rules that you include in your table can be as simple as a 1:1 transfer from a given unique input to a given unique output. Alternatively, they can be increasingly complex, with a new line added for each possible “input + rules” outcome. However complex or simple they prove to be, though, they must allow for a specific output for each individual input — whether that output is unique or not.
Recalculate Your Outputs Based On The Logic
Now that you’ve provided your inputs and your rules, you have to finish the table. Every decision table ends with a column on the far right that provides the end outcome, the decision of the rules in place. So, if it’s a simple 1:1 conversion, Input A will equal Output 1, Input B will equal Output 2, and so on. You can also see the same thing, but with far more variety, when tacking on more rules to determine the specific outcomes that Input A can amount to. Regardless, your decisions always come down to the output, so again, use what you wrote in the first place. Remember what decisions you thought you’d have to make, what outcomes were possible: that’s what you have to put down in this part of the table. If this part of the table no longer matches the outcomes of the decision you wrote down before starting your table, then you should look again. After all, the outcomes of the decision are what you’re looking for — so it’s imperative that you keep those in mind when writing your possible inputs, and when looking at the rules that define your available outcomes.
Check Your Formatting
It’s important, believe it or not, to have the right formatting in a standard decision table. While a personal one doesn’t need quotation marks, mathematical symbols, or field types like “string” or “integer”, it’s all too important when developing your table for business decisions, as these are likely to be created by business analysts, used by developers, and implemented through rules engines. The standardization with the formatting you see in a decision table is there to inform how software uses these fields to enforce the logic of the table in your own business process. Without honoring that, you’ve just got a table that can’t be made into anything useful, much less handled by an application to keep order in your production environment. Whatever you do, keep consistent with your tables, and stay vigilant with the formatting. Your team will thank you.
