Rudolph,
thanks for very concise article. I have been using rule engines in
teaching and research for several years, but I rarely find explanation of
this type.
Could you tell us, if this is from your experience or there is some
reference to thes e rules.
At 08:36 AM 6/2/00 -0700, you wrote:
>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]
>---------------------------------------------------------------------
>
* Dusan Sormaz, PhD 280 Stocker Center *
* Assistant Professor Athens, OH 45701-2979 *
* Ohio University phone: (740) 593-1548 *
* Industrial and Manufacturing fax: (740) 593-0778 *
* Systems Engineering Department [EMAIL PROTECTED] *
* http://www.ent.ohiou.edu/~sormaz *
*********************************************************************
