In Orwellian Event Processing the discussion moved away from my original intent, which was primarily to discuss the vendor-state-of-denial regarding the prior art for processing complex events, and gravitated toward a discussion on the “inefficiencies” of rule-based systems. I was surprised learn that there are professionals who believe that there is no basis in fact (or supporting literature) for saying that rule-based systems are inefficient.
The reason I was surprised at this was that I have experienced these disadvantages in operational network and security management systems for years (where it is nearly impossible to specific all possible combination of text in a string or strings and process them without false positives and negatives). I have known teams of people writing rules to update a rule-based approach to identifying hostile email bombs. I have also experienced the same type of problem with other common classification problems such as classifying text as “spam” or classifying text as “code” or “prose” or classifying log file entries as “friendly” or “foe”.
In fact, it was after experiencing these limitations that I began research into this topic. One place to start is to simply Google the phrase, “disadvantages of rule-based systems“ where, at the time of this post, this Google search resulted in:
Results 1 – 10 of about 11,800 for “disadvantages of rule-based systems”. (0.12 seconds)
Puzzled by the seemingly religious defense of rules-based systems by folks who work with these systems (as if there were no documented disadvantages anywhere on the planet) I receive an email yesterday that helps explain it, maybe. Here is an excerpt from that private message (keeping the identity of the author private):
In the past I’ve had flame wars with the Drools and other vendors over these topics. Too many people in the BRMS space hide these challenges and hate it when people bring it up.
This jives with my experience since I was involved with CEP. Regardless of my approach to this discussion, there are people out there that believe in rules so much, they lose there objectivity when we discuss the disadvantages. I never had this problem prior to working with CEP.
Moving forward, we “engineers” know that all systems (Yes ALL) have strengths and weaknesses, advantages and disadvantages. In fact, the strength of a system often defines it weakness and it’s weakness defines it strength. Advantages and disadvantages of a system are two sides of the same coin, one cannot exist without the other. So without diving into Zen or deep philosophy on “why a strong tree breaks in a storm and dies, where a soft blade of grass bends with the wind only to spring back the next day” however, “you don’t build your house out of grass“, I will gently take us to Disadvantages of Rule-Based Systems (Part 2) in the next post on this topic.
The disadvantages (and advantages) of encoding knowledge as rules and using this system to process complicated tasks has been firmly established for many years. Two of the key disadvantages are really a type of “common sense” where we don’t need 11,800 search results to find the answer, we just need to work with rule-based systems applied to complex, dynamic problems and we will quickly see the issues.
We could Google and review the numerous slides, lecture notes, papers and so forth on the advantages and disadvantages of rule-based systems, and provide links and quote to the specifics, but I suspect that the debate would still rage-on. For me rules-based systems are just one of many tools in a very large software tool box.
I like software rules. Few, if any, computing systems would work without “IF-THEN-ELSE” logic, whether declarative or programmatic. On the other hand, I always find myself using rules as mainly the “front end logic” and the “back end logic” when working on complex detection problems. The heart of the detection is (often) a statistical classifier which can “learn” and is “trainable” without writing more rules. Does that mean rules are “bad”. No! It means that system architects need more than rules in their toolbox to deal with complex classes of detection oriented problems.
In closing, I question myself as to why I am writing this post at all. To any objective person, it is obvious that there are advantages and disadvantages to using the various tools in the systems architect’s toolbox. I “guess” the reason I write on this is that I remain discouraged at the press releases and blog posts from the “event processing community” who have seemingly defined “complex event processing” as a type of metaphor for rule-based and query-based processing, seemingly marginalizing all the other well established (and very important) tools in the toolbox of the systems architect.