Anyone know of best practices for rules engines. The only thing I
could find was at:
http://blogs.ittoolbox.com/eai/leadership/archives/002172.asp
Good site.
See Chapter 8 of my book, Build Your Own .Net Language and Compiler,
for a discussion of one way to implement declarative rules cheaply.
This book was published by Apress in 2004.
This approach is best for small business since within the procedural
context, it can implement declarative structures.
However, it imposes an unfamiliar requirement on the developer, and
this is learning how to build small parsers.
I do address the consistency and completeness problem in this chapter.
I deliberately target small business because my experience in the
large enterprise is that the technology is so black-box as to create
opportunities for contradictory and incomplete rules which can't be
audited.
The advantage of my approach, in which the developers are language
designers and implementers and the end users manage the rules, is that
there is less opportunity for last minute changes to the rules of
which the users are unaware.
In environments using a commercial rules engine, an "expert" on the
engine becomes in effect a coder with the ability to override the
user's changes.
Whereas if the developers are tasked instead with providing languages
to express the rules, their focus is on improving the end user
experience. The end user modifies the rules with better assurance that
the actual rules are being followed.
It's always amazed me that new development projects start with a
committment to cast TODAY's rules into concrete. Large, "Enterprise"
systems are built like old Soviet sports palaces...for the ages...when
change is the name of the game.
I show techniques for managing knee-jerk changes by the empowered end
user to the rules by enforcing full evaluation and consistency, which
of course needs tuning when scaled up, and therefore I propose that
rules engine developers take a look at compiler optimization theory
for ways to pre-evaluate the rules (by means of symbolic
interpretation) for consistency and completeness.
In a scenario, the manager of my hypothetical firm gets mad at his
tenant and in a credit application adds the rule "deny all
renters"...which contradicts other rules that accept renters.
The rules engine points out the contradiction.
In procedural "thinking", an occupational hazard of end users as well
as programmers, the rule If rents->deny should "override" because it
is last in the list and furthermore it is today's priority because the
boss is hopping mad at his renter.
In "declarative" thinking, the end user is held to previous decisions
even if he forgot that yesterday he wanted to do business with
renters.
Part of my motivation was the fact that I'm troubled by a split in the
language of the business rules community.
On the one hand you have terribly abstract discussion of business
rules which gets "deep" only in the area of performance AS IF the
problems of contradictory or non-compliant rules were solved.
On the other you have equally abstract discussions of very advanced
inference engines which are treated as a black box and built by ivory
tower types who have never approved a credit application or reviewed
an immigration application for compliance to the latest rules. We live
in a world where people get Associate degrees in medical billing, but
too often, developers of rules engines somehow think that actually
RELATING their technology to the real world is beneath them.
It's only in the area of small business that you can combine the two
forms of discourse. In the USA, small business is at a disadvantage,
but, working in China, I see it in areas like microcredit as having a
powerful advantage and a need for a rules-based, as opposed to a
procedural-based approach.
