Standardising Decision Models for fun and profit
Posted by Paul Vincent
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.
Tags: decision table, DMN, KPI Decision Model
Complex Event Processing (CEP), Rules | 25 March 2010 |
4 Comments
Other Links to this Post
RSS feed for comments on this post. TrackBack URI
By Tom Debevoise, March 28, 2010 @ 06:40
Hi Paul,
Excelent Post and congratulations on your OMG work.
As far as Jan’s comments go, there is a relevent post from Dan McCoy at Gartner on this (http://blogs.gartner.com/dave_mccoy/2009/03/10/business-rule-representation-a-tradeoff-of-complexity-and-linguistic-power/#more-1263)
Do you believe that decision points in business rules should be expressed as decision tables?
Tom
By Paul Vincent, March 28, 2010 @ 16:18
Hi Tom - thanks.
Decision models are of course a superset of decision tables - and the DMN will likely follow the path of PRR:
) types
1. Define a high level metamodel for “decision models” of all (within reason
2. Deliver an initial first-example decision model, probably the most popular - i.e. decision table…
Notes:
a. The above is “IMHO” at this stage.
b. You could easily argue that decision graphs, ruleflows etc are in fact the most used form of decision metaphor, not because of specialist tools like Innovations’, but because of the multitude of business analysts modelling decisions as being embedded in processes with BPMN…
From a CEP perspective, it is clear that decisions at some point in a process - lets call these “decision points” - and therefore the location / requirement for a decision is dependent on some (process) state, and the latter is somewhat representable as a (sequence of / complex) event. Other than that:
i. the attributes of an input event can be an input parameter to a decision model, just like any other data
ii. the IT implementation of a decision model can be not only specified as an SOA service for a particular decision point, but generated as declarative terms for more dynamic business processing (translation: decision models are useful for declarative EDA models as much as for conventional SOA models).
Cheers
By James Taylor, April 13, 2010 @ 18:28
Paul
Another interesting post, thanks. I think the discussion about metaphors for representing rules is an interesting one but that different groups are always going to find certain kinds of representation more or less helpful for various situations. The key, indeed only, criteria is how well the metaphor allows those who understand the rules and those who are responsible for the system in which the rules execute to collaborate. If it enables this, it’s a good metaphor. If it doesn’t then it’s not.
That said I am not surprised that tables outdid trees which outdid rules - a compact yet graphical representation that does not expose too much geekiness is always going to garner more votes.
JT
By Paul Vincent, April 15, 2010 @ 09:43
Hi James - too true.
The interesting opportunity here is to provide a “filler” between the worlds of rule documentation (aka SBVR, RuleSpeak etc) and rule execution (aka PRR and BREs). We are planning a DMN RFP meeting in London on May 4 - if anyone else is interested please let me know - with the idea of presenting the draft RFP at the OMG MN technical meeting in June, and submitting it in the OMG September meeting.
Cheers,