On event driven vs. business intelligence drive viewpoints

The last few days in Israel were extremely hot, one local newspaper claimed that Friday was the hottest day in Israel within 112 years.   Now it is somewhat less hot, but still very hot.  Relief is expected later this week. 


I am playing now with the new editor of the Blog editor, which looks like Wiki editors, it seems that web editors are starting to converge into some form.


Anyway -- recently I have read some "business intelligence" stuff  - ("analytics" is now a hot buzzword in IBM, and probably outside IBM as well).    In business analytics terminology people talk about three phases: descriptive, predictive and prescriptive, while in event processing we also talk about three phases: responsive, reactive and proactive.  So I was asked - are those terms equivalent.   The answer -- not exactly.   


Let's start with business intelligence, or analytics in general.   The main starting point is:  we have historical data,  we can present it in different ways,  we can learn from it something that can provide observations, and can predict future data (e.g. by trends) and then we can propose actions to bridge gaps towards our goals.


The basic starting-point --  analyzing existing past data.  The first phase is descriptive -- describes what is seen in the data, this is the most common use of business intelligence.

The second phase is - predictive, find trends and extrapolate into the future, predicting future values of the same data.  

The third phase is prescriptive - given the predicted data, and possible gaps between this predicted data and the enterprise's goals -- propose a way to bridge the gap,  e.g. change inventory policies, change risk policies,  even getting to change business processes.  


Event processing is starting from different viewpoints - there are events happening now, and we would like to react to them -- the metaphor is  -- a dangerous bear is approaching and I need to react.

In event processing the evolution is starting in "responsive"  - in this case, indeed event is treated as data, information about events arrive using queries, search, or even applying any kind of analytics, this is the regular mode of programming, but it is data-driven rather than event-driven. It may be applicable to some applications, will not be very helpful in the case that the bear is chasing you.    Event driven architectures and programming has enabled the next phase in the evolution - reactive programming, in which predefined alerts or actions can be triggered by the fact that an event has detected, or that an event pattern has been identified. Currently the state-of-the-practice in what is defined under event processing applications fits this category. The next step in the evolution is proactive, which means that by computerized means we'll be able to identify predicted events, and then a decision of how to mitigate or eliminate the event is being taken,  for example when a bear is chasing me, I need quickly to decide whether my best bet is to hide, escape, or shot tranquilizing darts at the bear

The decision is done on-line, and has some timing constraints (depends on how close the bear is). 


Having explained the basic terminology, back to the original question, how are these terms related.  
First, the goal of business intelligence and event processing are typically distinct, however there are some points of overlap.   From the BI perspective,  reactive event patterns can be used as a component of predictive analytics.  Proactive event-driven processing can be thought as a type of prescriptive analytics.  The overlap occurs when the analytics system has real-time component, which requires that the prescriptive analytics will be done on-line and with some timing constraints, this turns it from being data-driven to be event-driven, but one can think of prescriptive system that is totally off-line - analyzing data in batch, predicting shift in trends, and change the policies for the next year/quarter. 


From event processing perspective, analytics tool can be used in populating the event patterns, but this is not that easy -- I'll write soon about some thoughts on the feasibility of patterns learning.