Showing posts with label event driven. Show all posts
Showing posts with label event driven. Show all posts

Sunday, February 3, 2013

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. 

Wednesday, December 26, 2012

More on request driven vs. event driven




In the table above (taken from a recent presentation I am working on) I have summarized some of the main differences between request driven thinking and event driven thinking.   It is interesting to note that many of the activities we are doing in life are event driven,  however, we are programmed to think that computer should be approached in request driven way, and I have noticed that even if the application itself is event driven by nature, people will tend to convert it to request driven.  Event driven action is being activated not due to explicit request but since an event has occurred, or a derived event was concluded.  This may happen in unknown time and unknown frequency.  Furthermore, a request getting into a system should always entail response (which can be error message),  an event getting into the system may be ignored, since it is out of context, just increment internal state, or close the circle of detecting derived event which can be either internal to the system, or trigger external action or notification,  Note that only the last case has visible response to the outside.    One of the challenges is to educate people to think in event driven way rather than request driven.  I'll write more on event driven thinking in the sequel.