JT on EDM

Jan presented on Rules in tables, spreadsheets and diagrams: Towards High Definition Communication. Decision tables are ways to represent sets of rules and there are many ways to represent sets of rules including trees and graphs. Some ways of representing rules are clearer than others and some are better for validation of the rules. You need ways to represent rules that work for specification, execution and verification/validation.

Conceptually a decision table is

“a table represent the complete set of mutually exclusive conditional expressions in a pre-defined area. Each situation has a single representation in the table”

(Jan’s definition). Decision tables can be horizontally or vertically oriented. Developing a table from a list of rules can be an effective way to find the missing rules – a complete decision table often has more rules than the specification of it as it helps identify the gaps and issues. Jan gave a couple of nice examples where apparently simple rules resulted in a table that immediately showed some gaps and problems. Consistency by construction.

To deliver consistency by construction it must contain the correct columns and all the relevant ones. Jan draws a distinction between multiple and single hit tables. Multiple hit tables – where multiple cells match a situation – are either first hit analyzed left to right or all hits where you must evaluate all the possible ones before knowing the answer. Jan does not like multiple-hit tables and additive scorecards are the only good example of this I can think of. Single hit tables are preferred because they are more declarative – sequence to columns/rows does not matter. Ensuring completeness by construction means laying out the structure of the table so that it can be validated without business know-how – the structure tells the story. Each condition is layered so that every possible combination becomes a column. Once every column has an outcome, and just one, it can be simplified but every possible situation must be covered and covered once.

In addition, Jan reminded us that business rules constrain and determine the process so, as several speakers have noted already this week, hard-coding rules into process designs is a bad idea. Processes are prescriptive or procedural but business rules and decisions are declarative.

Jan has done some research on which formats people like. Decision tables come first, decision trees second and textual description is third. Complex (oblique) rules come last.