Last week I was doing some analysis on the Rule Engine products available in the market.I was trying to figure out what generic features, a Rule Engine should have and against those features I was planning to compare the available products.In this post I will discuss about the basics of business rules,business processes and rules engines.
We can think of Business Process as a set of coordinated tasks performed (by human as well machines) to yield a result of substantial business value.When I say machines these can be computers or any other mechanical devices used to accomplish a task or automate certain tasks.So a business process has certain flow and based on some conditions,decisions needs to be taken to decide what will be the next step.Herein comes the Business Rules.Business Rules are the guidance or constraints that influence business behavior.In other words these are set of constraints or guidelines that determine how a particular task within the a business process will be executed.For example Loan Application Processing is a business process and there can be a set of business rules guiding or influencing the Loan Approval task.
However the Business Process and Rules should be treated seperately or not from an implementation perspective is an interesting debate.As per business rule expert Ronald Ross (author of Principles of Business Rule Approach)
"Processes are processes, and rules are rules. They are not the same. A fundamental principle of the business rule approach is that each is a primitive. Formally, one primitive can never decompose to another primitive. So processes never decompose into rules, and rules never decompose into processes…"
I mostly agree with the rationale provided by Chris Lawrence in his Business Process and Business Rules blog post series.To me it is not very wise to seperate the business process and rules as two seperate things as rules form an intrinsic part of the process.This is because my guidelines or constraints are composed of two things one is a criteria or condition.After evaluating the condition I will take a decision and perform a task.This task is inherent part of my business process.
I would like to quote Chris Lawrence regarding this:
"To that extent I agree with Ross and Burlton that business processes ‘transform inputs into outputs according to guidance - policies, standards, rules, etc.’ But I see no residue of ‘script’ which is not rules. ‘Flow’ is also ‘know’. It is completely arbitrary to see ‘Milk must be fresh’ as a ‘rule’ but ‘Combine flour, water, milk, and eggs in a large bowl’ as part of a ‘script’, and therefore not a rule - just because ‘I want both a script to follow … and rules to guide me in doing the work’ and ‘I want the script and the rules to be separate’."
Okay now let us discuss about Rules a little bit more from a simple computing/programming perspective.Rules as we have understood by now are conditions and actions performed based on evaluation of conditions.So these are basically if-else programming constructs.This is what exactly a Rule Engine also does but in a more sophisticated manner.These Rule Engines generally does the following:
- Provides facility to create and edit the rules.Some of the products offers sophisticated UI so that these rule changes can be done by System Analysts/Business Analysts with no programming knowledge.The rules created are stored in a repository to be used during execution later.
- Retrieve the rules data from store and parse the rules .
- Execute rules by applying the conditions on input data.
Thus it completely externalises the rules from rest of the application.This leads to a better maintenance and quick turnaround whenever there is any change in the rules.
In my next post on Rule Engines I will discuss about the some of the Rule Engine products available.
