OMG convened in the murder capital of Florida this week, possibly to add some excitement to the normally dour world of IT standards. There are, as we have recorded before, a number of ongoing standards initiatives that are relevant to event processing, with 2 in particular at OMG in progress:
– PRR (the Production Rule Representation) currently at version 1.0 and working towards a 1.1 tidy-up; ECA rules can be covered under PRR, although the current scope is not event-specific [*1]
– DMN (the Decision Modelling Notation), currently starting up as an initiative [*2].
This week DMN took a significant step forward in the standards process, when it gained as a supporter the world’s foremost “decision table” expert, Jan Vanthienen from Katholieke Universiteit Leuven in Belgium. Jan presented “decision tables” to the OMG’s Business Modelling and Integration group.
Jan explained how “decision tables” are just another representation of business rules, enabling completeness (every possibly input combination is covered) and exclusivity (every possibly input has ony 1 possible outcome associated with it) constraints to be enforced.
Decision Tables can also be used in several ways: from an IT perspective we tend to view them as an executable decision service (given inputs, determine a decision output). However, they can also be used in a goal-driven way: what input is needed to achieve a particular output. For the CEP community, of course, the “implicit invocation event” can be an explicit table condition…
There are several variations in decision tables defined as models, too: the most useful for business analysis is the one that defines all outputs as binary (boolean) results and it effectively is a lookup for outputs against inputs. Again, in IT systems these are normally truncated to a form where the output is the appropriate *action* (value being updated to some expression).
As one who has been preaching decision tables for many years, Jan has a number of reasons why people should use decision tables as a business rule representation for decisions:
– compact but powerful visualisation
– easy to verify (check) to avoid errors
– modular, compatible with hierarchies of decisions
– easy to make fast and efficient execution engines.
As an example, Jan used some text from a sports page on predicting some sportsperson’s tennis ranking based on the possible outcomes for the some future tournament results. Placing this logic in a decision table allowed the outcomes to be easily seen, and the specification inputs (what Jan calls business rule specifications) to be analysed for completeness and contradictions. As such it could be thought that a decision table approach contrasts with use of the OMG SBVR standard (Semantics of Business Vocabulary and Rules), where one defines business terms and constraint rules in a formal, well defined fashion. However it seems that in reality decision tables complement SBVR by providing a structured mechanism for defining fragments of SBVR terms and rules as used in decisions, and combining general rules, exceptions, modalities and timings.
So, effectively, a Decision Table is a relation between states and possible outcomes.
The methodology for defining decisions based on decision tables – a type of decision modelling – is well covered in a particular way by KPI’s book “The [KPI] Decision Model” [*3]. But the process is similar:
1 – interactive exploration of exceptions
2 – starting from text, built up possibilities and populate table
And in an “ease of use survey” Jan undertook, they found a strong preference for tables over trees, and the same for trees over text, for a sample complex rulebase.
Notes:
*1 = TIBCO BusinessEvents uses inference rule agents that exploit production rules for identifying event patterns and making inferences.
*2 = TIBCO BusinessEvents includes decision table modelling and deployment, for decisions and reactions post-pattern-detection.
*3 = Opher Etzion, EPTS chair, has commented on this book from a CEP perspective.
