CEP and the alphabet soup (Part 2): BI

Reading Time: 4 minutes

BI stands for Business Intelligence, which to some will sound suspiciously similar to Groucho’s famous comment. But in reality BI is more to do with providing the right “Business Information” to people who need it (i.e. business analysts), and therefore relates to sophisticated visualization and reporting tools for views of historic data from a datamart or data warehouse. BI users will use a variety of technologies, ranging from the ubiquitous Excel(R) to TIBCO’s recently-announced-acquisition Spotfire.

So how is BI (as in business “information” – we’ll come to the “intelligence” part later) related to CEP? Well lets look at the sorts of capabilities and technologies deployed in a typical BI solution:

– some kind of datamart or data warehouse, storing historical records of transactions (which by the way are the results of responses to events)
– the BI tool for dissecting and analyzing the data, allowing the data to be collated and graphed in such a way that trends can be identified and then analyzed
– a business person to infer what action to take based on the data presented: note that while there is skill involved in the data segmentation and analysis part, the “intelligence” in the system occurs in the user(s)’ actions in responding to the information.

BI in a generalized software system

Therefore BI technologies are mostly about sophisticated reporting. The reports are used to make strategic and/or tactical decisions that are *hopefully* viewed as “intelligent“. An example would be the targeting of a particular audience segment for a marketing campaign based on (a) identification of that segment and (b) analysis of the buying patterns of that segment. The idea is that, providing other variables can be minimized or compensated for, some future analysis will determine that the resulting business change was successful (or not, as the case may be), and the process of viewing / analyzing / making changes can be repeated ad nauseum.

So BI is used over multiple business cycles using historic data and requiring the manual selection of strategies, tactics and decision processes [1]. This is fine for things like “trend discovery”: identifying what is going on (that we don’t know about but should). However, there are also some types of analysis where one has a good idea of what likely trends/results *could* be, and these may be able to be handled in real time through CEP by matching events to behavior. An example of this would be personalization strategies for customer retention: if a customer registers a new employer in their bank profile, then browses your mortgage information web site, you don’t need to be a brain surgeon (or need sophisticated BI reports) to deduce that they may be considering moving house with the new job, and that proactive behavior from the bank (like an email explaining that their existing mortgage is in fact portable) could be beneficial to both parties… Here the business is acting “intelligently” by using event correlation and event-driven business rules to “understand” and respond appropriately to the customer’s behavior. [2]

CEP in the role of BI in a generalized architecture

Interestingly, one could implement additional rules that update the event processing rules themselves – i.e. “metarules” that update other rules’ parameters based on past behavior and results – sort of like an expert system using some of the simpler rules of thumb extracted from your business analyst. For example, on online pricing engine could adjust pricing rules based on current demand and individual trends (within certain constraints, of course!). In this case the business is acting “intelligently” by modifying (carefully!) its own processing rules automatically – effectively “machine learning”. Of couse, this sort of behavior has to be defined very carefully, and would represent some subset I expect of any “regular adjustments” a business analyst would make to a business process when doing “conventional BI”.

So lets recap: BI (as normally understood) is “long-term” and about deriving information, and CEP-driven BI is “real-time” and about automating intelligent business behavior, and both (can) provide “business intelligence”. Of course there is no reason why you cannot combine the 2 (for example, allow BI users to update some business rules in your CEP engine or event-driven rule engine, as well as apply CEP to business events to respond in real-time). And if you do both, I am sure you will be able to demonstrate truly “intelligent” business behavior to your customers…

CEP and BI modifying CEP rules in a generalized architecture

Notes:
[1] The traditional BI industry is reacting to the need to do more than just inform its users about historical data – leading to the concept of using advanced BI reporting tools against the operational data store as in Operational BI.
[2] Some may also consider this behavior BAM or Business Activity Monitoring. Of course in this case we are not simply monitoring business-driven events, but responding to external customer events too. So this is a nice segue to another alphabet soup spoonful, CEP and BAM.