Should We Simply Rename CEP BRMS?
Seemingly inundated with blog posts about CEP and BRMS, it seems we should simply rename the current CEP space, BRMS. All of the current self-described CEP products on the market today are rules-engines, this includes the continuous query stream processors and the RETE engines. Furthermore, a quick review of Wikipedia says BRMS is, as follows (direct quote):
A BRMS or Business Rule Management System is a software system used to define, deploy, execute, monitor and maintain the variety and complexity of decision logic that is used by operational systems within an organization or enterprise. This logic, also referred to as business rules, includes policies, requirements, and conditional statements that are used to determine the tactical actions that take place in applications and systems.
The definition above does not say that processing events is not permitted. Also, the description does not state that connectors and adapters to the event sources are not permitted in a BRMS. In fact, Wiki goes on to state the following,
A BRMS includes, at minimum:
- A repository, allowing decision logic to be externalized from core application code
- Tools, allowing both technical developers and business experts to define and manage decision logic
- A runtime environment, allowing applications to invoke decision logic managed within the BRMS and execute it using a business rules engine
The top benefits of a BRMS include:
- Reduced or removed reliance on IT departments for changes in live systems
- Increased control over implemented decision logic for compliance and better business management
- The ability to express decision logic with increased precision, using a business vocabulary syntax and graphical rule representations (decision tables, trees, scorecards and flows)
- Improved efficiency of processes through increased decision automation
These are all the same arguments we repeated read from software vendors in the CEP space.
Why not rename the current CEP rules engines BRMS?
(The reason is quite simple, based on my experience.)
If software companies called all these new rules engines (all from players without a mature BRMS product) “BRMS” the marketeers would be required to compete head-to-head with the mature BRMS products and companies on the analysts magic charts and waves.
IBM has publicly called this space “business event processing”. Since all the current generation, self-described CEP products on the market are types of rules engines, should we not ask the analysts to simply categorize all the current CEP products on the market BRMS?
Filed under: Business Rules, CEP News and Events, CEP Terminology, CEP Tutorials, Complex Event Processing, Event Processing, Event Stream Processing, IBM
It is an interesting idea that I would like to develop further. I would tend to think that CEP is another technology that is part of Decision Management but not necessarily part of BRMS.
My main concern is confusion for the practitioners. There may be some technology overlap in how we execute or maintain the rules but the purpose is fundamentally different in the sense that we either want to make a decision or correlate/filter events. I really see complementarity here as you may want to make a decision as a result of an event being posted. On the same token, you may need to filter a flurry of events prior to invoking a decision service. But I would argue that they are used with a different objective in mind.
What is your opinion on this subject?
Carole-Ann Matignon
VP, Product management at Fair Isaac
Dear Carole-Ann,
Thanks for visiting and for commenting.
Frankly speaking, I do not see the distinction you are attempting to make. CEP is not about just filtering and correlating events. It is about effecting business decisions based on detecting complex situations in real time.
Your post appears to reduce CEP to “filtering” … Filtering is a part of a most CEP applications, a precursor to situation detection; no different than it is in a BRMS application.
Honestly, I don’t see any difference in objective, as you would argue. On the other hand, I don’t have enough information to draw any conclusions or firm opinion, and look forward to hearing and reading more!
See also:
More on The Value of (Production) Rules
http://www.thecepblog.com/2008/11/21/more-on-the-value-of-production-rules/
Yours sincerely, Tim
Hi Tim,
I am using an analogy to the nervous system to better illustrate how to position those decision management technologies. You can find it in my latest blog entry (http://www.edmblog.com/weblog/2008/11/an-attempt-at-demystifying-cep-bpm-and-brms.html).
I am looking forward to your comments.
Thank you,
Carole-Ann Matignon
VP, Product Management at Fair Isaac
Dear Carole-Ann,
(Reposted comment from your blog)….
You are simply (and incorrectly, in my view) reducing CEP to low level event (sensor) processing, which was never the intent of the technology or the architecture.
I covered this in detail in my 8 part series, What is Complex Event Processing?
http://www.thecepblog.com/what-is-complex-event-processing/
and in particular, to analogy to the human body (in Part 1 of 8):
http://www.thecepblog.com/2007/05/14/what-is-complex-event-processing-part-1/
Hope this helps!
Your sincerely, Tim
Tim, I often feel a keen disconnect with your use of the term ‘rule processing’. You say (with irony, I believe) “Since all the current generation … [of]… CEP products … are types of rules engines, should we not … simply categorize all the current CEP products on the market (as) BRMS?”
Rule-processing is just a style of computation. Of course it is used in BRMS, but it is also used in CEP. CEP systems typically employ rules-based processing to infer higher-order events by matching patterns across many event streams within the event ‘cloud’. BRMS’s use rule processing to match patterns within data tuples representing business-orientated data. CEP systems may support the use of advanced analytics to manage predictive analysis, reasoning under uncertainty and other requirements in relation to the event cloud. Some of the better BRMS’s offer similar analytics in regard to processing business data.
So, if it is true that some products billed as ‘CEP’ are really just BRMS systems with some extra event processing features, this problem is not defined by the use of rule processing, but by the orientation of these products and the problem domain(s) they are designed to address.
Given that the underlying processing approaches are so similar, there is bound to be a) confusion and b) a degree of technology convergence. It is actually possible that we will see products emerge that can be used as both BRMS’s and CEP systems. Carole-Ann had a point, I think, in saying that ‘decisioning’ is an area in which both BRMS and CEP have a role to play. I’m glad, personally, that CEP is having such a profound effect on the evolution of BRMS technology. Thanks, though, for bringing your readers back again and again to what is truly distinctive about CEP.
CEP denotes a class of applications, those that are dedicated to processing events and detecting patterns in the time (or in the space, etc). It can use several technologies, such as neural nets, Bayesian networks, etc. I do agree that in the current market, the CEP systems are rule-based or query-based.
BRMS is a category of systems that provides capability to express rules and to execute them. Rules can be production rules, goal-driven rules, or in its wider acceptation some constraint expressions. A neural net cannot be called a rule, nor a Bayesian network, it’s indeed more appropriate to call them “models” (versus rules). (I made a comment about this here: http://www.thecepblog.com/2008/07/15/modelling-situations-for-event-processing/)
Some BRMS may offer the capability to build CEP systems, those BRMS could be flagged as “CEP Capable”. Some CEP systems, when they are based on rules and offer the appropriate level of tools to let business users to edit and manage business rules, could be called “BRMS”. So CEP and BRMS have an intersection, but are different. Note that we should distinguish between “rules” and “queries”. A rule is generally a statement with a premise and a conclusion, while a query expresses only the premise part with no conclusion. In particular, most of the EPLs in the ESP systems are queries-based, not rules-based.
Hi Changhai,
Thanks for stopping by, and for the excellent, insightful comments.
Yours sincerely, Tim