Maybe the following will help.




Some Guidelines For Deciding Whether To Use A Rules Engine
----------------------------------------------------------
----------------------------------------------------------

1. Is your algorithm primarily compute-intensive or is there significant
decision-making capability involved?
· If your basic algorithm is compute-intensive or a table-lookup, without
much conditional branching or decision-making involved, then don't use a
rules engine.
· If however, the algorithm involves significant conditional branching or
decision-making, then consider using a rules engine.

2. Once, you've determined that your algorithm involves significant
decision-making capability, you ought to be able to write some rules
specifying the decisions that need to be made.  Are the decisions that need
to be made relatively simple, or potentially complex?
· If you find that you can't write the decision rules, for whatever reason,
then stop here until you can, or use some other tool instead that will help
you discover the rules you need.  Put another way, if you can't state some
rules, don't use a rules engine.
· If you have 2, or fewer, conditions in your rules (or, for example, a
block with 2 nested if-statements or less), don't use a rules engine-it's
probably overkill. 
· If you have 3 or more conditions in your rules (or, for example, a block
with 3 or more nested if-statements in pseudo-code), then consider using a
rules engine.

3. Once you've determined that the decisions are complex enough, is your
algorithm basically static, or are the rules likely to change reasonably
often over time?
· If the rules/logic are well-defined and static, then don't use a rules
engine-you probably don't need the overhead or flexibility.
· If the rules are likely to change over time due to the nature of the
application, then consider using a rules engine-the flexibility is worth the
overhead.

4. Once you've determined that rules may need to be flexible, are you going
to maintain the code or finished product over time, or is this effort a
one-shot effort?
· If the code is not going to be maintained over time, then don't use a
rules engine-you probably won't gain any significant advantage from it.
· If the code is going to be maintained over time, consider using a rules
engine-the ROI will be worth it (see question #6).

5. Rules engines continue to get faster and faster, but some applications
simply require every bit of speed and performance optimization you can
reasonably give.  Does your customer require a custom solution or do you
need to hard-wire the algorithm for absolute high-end performance, or can
the solution accommodate a rules engine?
· If you need to optimize for speed and memory, or your customer requires a
custom solution, then don't use a rules engine.
· If the performance requirements will accommodate a rules engine solution,
then consider using one.

6. If you answered all the other questions appropriately, can the
project/product line afford the overall cost of using a rules engine over
the project/product lifecycle?

There are a number of costs typically associated with using rules engine
tools:
 * Licensing fees for development and deployment of the engine
 * Training developers and (if necessary) end-users (time and money)
 * ROI (return on investment)-financial analysts have shown that you don't
begin to break even monetarily on the typical investment in rules engine
technology until at least 1 year after deployment to your customer.
However, at that point, the flexibility and ease-of-maintenance begin to
show significant returns.

· If the project schedule or product lifecycle can't accommodate the cost of
a rules engine, in terms of time and money, then don't use one.
· If you can't afford to wait at least a year to break even and begin to see
a significant ROI, don't use a rules engine.
· If you can't afford to train your developers and end-users, and you can't
afford to hire a consultant, don't use a rules engine.
· If, however, your project/product lifecycle costs can accommodate the use
of a rules engine, it would be well worth the investment, so use one.


Additional Note
---------------
A rules engine tool can be very helpful during software development,
regardless of other considerations:
· For simulation and prototyping.  
· In cases where you find you may not really know or understand the rules
you are trying to encode in your algorithm, a rules engine can provide a
flexible way to encode and modify the rules over time as they are
discovered.  
· A rules engine architecture also provides a convenient structure for
separating "business logic" from the rest of the system, aiding in the
effort to clearly "separate concerns".

-----Original Message-----
From: Sachin [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 02, 2000 4:52 AM
To: [EMAIL PROTECTED]
Subject: JESS: Need of Rule Based Systems !!!


Hi,
I read all the documentation of rule based systems, but am sorry to say that
i am still not able to appreciate its importance in a business. Can any body
give me some specific example and then quote out by comparing the difference
between the procedural and rule based approach. After all what is wrong with
encoding business knowledge in business objects of business level middletier
layer. Kindly quote an business example !!!
Thanks
Sachin


---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify
[EMAIL PROTECTED]
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------

Reply via email to