those early 2000's must have been the very brief golden age of rules engines/expert systems... but coincidentally, i was just recently thinking about doing some research on the current state of rules engines to see if there might be a viable option today for matching candidates to jobs.
my very first consulting project (yes, i had absolutely no experience), around that time, was implementing blaze advisor (now owned by fico: http://www.fico.com/en/products/fico-blaze-advisor-decision-...) to migrate a mainframe-based automated life underwriting system to a j2ee client/server system.
performance was a major concern, so i read Forgy's 1982 paper about RETE (that i didn't quite understand frankly), but the key takeaway (for me at least) was that all the hard work happened during compilation so running performance shouldn't be an issue. from what i dimly remember, the algorithm iterates through the rules set building something akin to a decision tree until the tree reaches a stable state. if it never reaches stability, it will throw a compile error. once the tree is built, matching is very fast.
the holy grail was that "business analysts" (remember when that title was in vogue? =) could write the rules, saving you months of precious time and thousands of dollars by not paying programmers (it did not turn out that way of course).
A lot is known about matching. A lot of the work boils down to min cost network flows on a network with arcs with costs per unit flow and a maximum flow that is an integer. The problem, then, is integer linear programming but in this case the old linear programming simplex algorithm returns integer results for no extra effort. A nice modification is due to W. Cunningham, one of my profs, later Chair at Waterloo's Department of Combinatorics and Optimization.
are you talking about codifying the matching rules as cost functions and then optimizing that as a linear system of equations? that's something i remember doing in college, but it's been a while. =) are there any existing software tools out there that helps in that regard? i'm not sure it fits my use case, but it's good to explore.
i'm working on a platform that helps hourly workers find jobs. today that matching is fairly straightforward, but it will get more complicated over time as we get develop better heuristics for matching candidates. it would be nice to be declarative about the matching rules and let the system figure out how to do the matching.
I wonder how many developers nowadays will consider a rules engine or decision tables to implement those underwriting rules. It gets pretty complex pretty quick when you look at the rules in the financial services industry (pensions, loans, etc.). I also see the application of DSLs as well, with the same idea of being more productive with less code.
my very first consulting project (yes, i had absolutely no experience), around that time, was implementing blaze advisor (now owned by fico: http://www.fico.com/en/products/fico-blaze-advisor-decision-...) to migrate a mainframe-based automated life underwriting system to a j2ee client/server system.
performance was a major concern, so i read Forgy's 1982 paper about RETE (that i didn't quite understand frankly), but the key takeaway (for me at least) was that all the hard work happened during compilation so running performance shouldn't be an issue. from what i dimly remember, the algorithm iterates through the rules set building something akin to a decision tree until the tree reaches a stable state. if it never reaches stability, it will throw a compile error. once the tree is built, matching is very fast.
the holy grail was that "business analysts" (remember when that title was in vogue? =) could write the rules, saving you months of precious time and thousands of dollars by not paying programmers (it did not turn out that way of course).