On event model and decision model

In the article about "event model" by Luckham and Schulte, on which I have reported last week,   the term "decision model" was referenced as one of the complementary models to an event model.  This has created some discussion within the DMN LinkedIn group, the discussion was created by Paul Vincent who is one of the persons behind the DMN standard work.   I am following the DMN work, though not in an active way, and participated in the kick-off meeting in March 2011,  and also written on "decision models and event processing"  following the talk on "The Decision Model" by KPI at the same event. 

In order to view the relationship between "event model" and "decision model", we need first to understand what is a decision that a decision model is modeling 

 The DMN presentation defines decision as "A Decision is the act of applying decision logic to one or more inputs and produce one output".    This can relate to modeling a collection of business rules, which gets a request with an associated input and returns a result  ("concluded fact") or to a result of some quantitative model (such a scoring model or optimization model). 

In comparison event model is modeling event-driven logic, which is based on deriving situations or derived events based on filtering, transformation, aggregations, and pattern detection over a collection of input events.   

The question is what is the relationship between these two terms?  

we can start by looking at the relationship between business rules and event processing,  there have been long discussions about it in the past, the position I expressed was that related to a discussion with James Taylor in 2008, stated that event processing and decision management are different issues.  A decision may not be related to event, and an event processing may not trigger any decision.  However, there are also relations between them.   

In my recent presentations about event-driven applications I am using the "4 D" that coined by Jeff Adkins: 

 I found out that this is an easy way to explain both IT and business persons who are not familiar with event-based systems what it is in a nutshell.      Referring to this picture, an event model deals with the "detect" and "derive" phases.    The derived event may also by itself denote a decision (since it is obvious what to do if this situation is detected and does not require further decision),  or that the detection of this situation triggers a decision that can be modeled by a decision model (note that the situation may trigger a task, and then the decision may be embedded inside a business process model).  In the example referred to in the slide above,  the  "derive" phase detects that a traffic jam is coming, and the "decide" phased determines how to reset the traffic light policies in order to reduce the traffic jam -- in this case they are complimentary.

Another interesting point is that "decision" in the common interpretation is "request driven",  I have recently written about the distinction between "event driven" and "request driven".   One may claim that a request is an event (which is sometimes semantically doubtful), or that there is always some event that causes a person or a system to make a request (may be metaphysically true, but the event is not explicitly exposed).  However, request-driven is taking an action by request (a passive approach), while event-driven is taking an action without a specific request, due to either occurrence of event or detection of situation (an active approach).    An event can take 

Bottom line:  decision models and event model are complementary models.   I'll discuss similarities and differences in the content of what is modeled in a later phase.