Deciding on a Complex Event Processing(CEP) platform for an Event Driven Architecture solution?
Recently I was consulting with a leading Cargo shipping company for a legacy modernization program. While debating on the technology choices there was an interesting debate which happened around Event Driven Architecture and which products should be selected in achieving this architecture. The main debate revolved around Rules engine Vs a Complex Event Processing engine to analyse and further act on the events.
There is quite a bit of overlap in these technologies and in certain situations both of these may be leveraged to do the job whereas other scenarios may strongly point in one direction. Both these technologies work by analyzing the input data and taking some action. In my view the following aspects would help in deciding which way to go:- Usage of BRMS: Typically BRMS systems are more focused around empowering business users to have a better control on the automation of Business Rules. BRMS systems provide the business users with functionality to author the rules and also maintain the rule life cycle. BRMS is generally implemented in automating the business rules which come into play during the normal execution of business scenarios. For e.g. calculation of a premium amount for an insurance policy, assigning the query resolution SLA based on the card type (Gold vs Platinum), Calculation of freight charges for a logistics company etc. All these are examples where Business Rules engine would fit in. In contrast CEP is mostly targeted at identification of unusual scenarios which occur in business process execution. Such rules are typically very complex in nature.
- Usage of CEP: If the requirement is to correlate different events and then decide a final course of action, then it would most probably lie in the CEP space. CEP, unlike BRMS, is generally used for correlating different events to find out if something unusual has happened during the execution of the process. This is generally referred to as needle-in-the-haystack identification. CEP execution requires lots of input data streams related to events and the correlation can happen on the following dimensions:
- Absence of event: This is detection of some event which was expected at some time but did not happen. For e.g. Shipping container was expected to dock @ 11 AM but has not arrived. The detection of absence of this event could lead to an alert to time keeping office to take remedial actions of reassigning the cargo unloading team to some other task.
- Correlation over a period of time: This involves detection of some kind of pattern in the occurrence of event over a period of time. For e.g. A chemical reactor involved in an exothermic reaction the rate of rise of temperature more than x®C /hour may need addition of some chemical to slow down the reaction, An x% increase or decrease in a stock price compared to the last day closing price may need a sell or buy call on the stock, Credit Card swipes across locations wherein the ratio of the distance between location in miles to the time lag in Hrs is more than 200 may need to be highlighted to fraud detection team etc.
-
Correlation between multiple different events: Sometimes the single event itself may not be significant but when it is juxtaposed with some other event it becomes important to be acted upon. For e.g. An equipment in a port has broken down and would take a week to fix, there is a priority load booked to be dispatched from the port which needs this equipment. A CEP system can detect the correlation between these events and raise a trigger to rebook the load on a different route avoiding the port.
In the case of the Cargo shipping company we realized that the events which were to be handled were very simple in nature. Further the events were discrete and didn't require any correlation. In our deep dive sessions with the client there were hardly 10-15 simple events which were identified. We also felt that once the business folks are exposed to event driven architecture they would be in a better position to articulate more such use cases which might be more complex than the ones being considered. For the current situation it did not make commercial sense to invest in a CEP engine. So our recommendation was to create an architecture which was enabled for event driven actions. Thus while the applications in the architecture would be publishing events, the event analysis and action would be handled in BRMS to start with. In future if the event requirements increase and become complex, investments can be made to introduce a CEP platform.




