[dkimball]

Alex Papadimoulis of the Daily WTF has an article on this -- it's his opinion that the simple, "bone-headed" approach is the best one for constraints like this, and homegrown business rule engines are dangerous:

http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Lea...

However, commercial business rule engines might work out better, provided they stick to XML or known formats of I/O in general.

[GFischer]

Thanks for the link.

IMO Alex doesn't give the best advice sometimes (not to wonder, he sees so much boneheadedness!!!), but he's quite right there... but I don't see the advice -against- business rule engines there.

I totally agree with your own advice about sticking to commercial business rule engines. In fact, I'll give Drools.net a try (any other suggestions?).

If any company -needs- a rules engine, it's the one I work for (there's a "developer" whose main reason for having work is that the business rules change a lot every freaking month)

PD: I like his linking to Yourdon's book :) - and I have a degree in "Information Systems" myself

[dkimball]

You know, on considering, I think you're right -- he doesn't advise against rules engines, just the Greenspun's Rule version. (Greenspun's Rule is that "any sufficiently long-running project includes a slow, buggy, and ad-hoc implementation of half of Common Lisp.")

I don't have much experience with rules engines, and I don't know what your budget is like; so I can't really make recommendations. That doesn't stop me from trying, though...

You might be interested in Intersystems' Ensemble. If you're anything like Alex, you'll run screaming for the hills at this point, since it's built on MUMPS (it's an extension of Caché, "postmodern MUMPS," which comes with everything from a web server to a blindingly fast SQL frontend). If you're not -- if you realize that it all compiles down to object code anyways, and what's important is programmer skill and code maintainability, not the presence of curly braces and variable declarations -- you'll keep reading. (Actually, Caché's version of MUMPS has both curly braces and variable declarations, although both are optional.)

Ensemble was designed to translate messages between incompatible healthcare databases, applying business rules in the process. It can be used for more than that; part of the training I had in the product (see below for my full disclosure) was using it to implement a simple loan acceptance protocol.

I think that its "flowchart mode" of execution might be very well suited to frequently-changing business rules. There's a video at http://www.maddash.net/videos/intersystems/ensemble/vehr/ which demonstrates this -- look at 7:15 for the flowchart (each element in it is programmable as necessary), and at 2:15 for the related flow through processing modules when something comes in.

You may be able to get a proof-of-concept demonstration -- see http://www.intersystems.com/ensemble/pilot/index.html for details. Even if not, if this looks interesting, it wouldn't hurt to get in touch with Intersystems Sales.

Full disclosure: I work at Intersystems, but I'm not associated with Sales, and I really should be getting back to work. :)

[GFischer]

Thanks for the suggestion. My first instinct is indeed to run for the hills :)

I'm watching the video and the first point is that you should fire the graphic designer :P (I suspect there isn't any, if a programmer did it, at least the screens are very clear - heck, maybe a graphics designer would murk it).

PD: after watching the video it's very clear that it's not what I need at all, but thanks for the suggestion.

Greenspun's rule is something I'm painfully aware of (the main enterprise app I work with has an ad-hoc implementation of... assembler :P ), but thanks for the reminder.

[dkimball]

Thanks for the update, and for giving it a chance. I agree that the production values are pretty bad...

Good luck in your search. I've never heard of an ad-hoc implementation of assembly language before, but while we're talking about wanting to head for the hills... :)

[GFischer]

Heh.. you don't say... it's built with Sun ONE's UDS FORTE development environment (on a language called TOOL), which stopped being supported years ago.

Fortunately I don't maintain that one very much, but yes, it's "run-for-the-hills" worthy - sadly, the current job offers job security and pays above average for my country.

I'm keeping an eye open, but I haven't found an adequate niche for me yet - my skills don't translate well to a remote environment, I'll probably try my hand at consulting.