Jess 7 Features
Related Web Sites
About This Site
, the Rule Engine for the JavaTM
Some Guidelines For Deciding Whether To Use A Rules Engine
by George Rudolph
Assistant Professor of Computer Science, The Citadel
- 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
- If however, the algorithm involves significant conditional branching or
decision-making, then consider using a rules engine.
- 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
- 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
- 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
- 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
- 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).
- 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.
- 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
- 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.
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
- 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".
Last modified: Thu Jul 10 14:12:27 EDT 2008