Well, my buddy Mark Proctor has been really busy blogging about ruleflow and (slight oblique reference to Drools documentation on that subject) work flow and how the two things make it easier for business guys to state their problem. I agree with the ruleflow documentation in that a ruleflow is only PART of the overall solution. So, where's the catch?
If you give a man a fish, he will eat today. If you teach him how to fish, he'll never go back to work. OK, bad analogy. How about having a hammer and everything looks like a nail? If you give business people spreadsheets - what we call decision tables but it's still a spreadsheet to them - or a ruleflow - what looks like a typical workflow engine to them - then THAT'S what they will do (and only that) because it is very familiar and it just "feels right". What can I say? We gave them the gun, they shot themselves in the foot with it, and then we blame them for doing it. And we, the rulebase community, claim that we told them the right way to do and that they just messed it up.
OK, all of the above is procedural programming. You can't get around it. It's just another way to do Java or C++ or COBOL or VB or C# or whatever else procedural language is being used. And that is NOT a rulebase because a rulebase is, primarily, declarative programming. Why, oh WHY can't we, the guys who are supposed to know better, still pushing decision tables, decision trees and ruleflow as answers to complex problems. It probably IS an answer to a specific business problem, but not all problems can be solved that way - which is why we invented a rulebase in the beginning; to solve complex problems that defy conventional, procedural programming.
Bottom line? Don't use a hammer when a screw driver is better suited for that purpose. Sure, the hammer will work to drive a screw into a wall, but it won't hold up very long. A screw will work better. (Don't get snarky on me - sometimes a screw is just a screw and not anything sexual.) And PLEASE do say that I'm against ruleflow, decision tables, decision trees, work flow, etc. I'm not. But a rulebase project just HAS to have it boundaries and applications just like any other tool. Use it properly or it will backfire and kill you.
OK, maybe it's off the subject of what Mark was originally trying to write about. But we just HAVE to draw the line somewhere and it's up to me, Mark, Peter, Dr. Forgy, Haley, ILOG, Fair Isaac, etc., etc., to start drawing and try to write "quality" business - projects that have a chance of being extensible, expandable, and all of the other "-able" handles. BTW, here are the links to Marks stuff so you can read it for yourself. You might start with the first two. The others are along the same lines.
The blog link
http://blog.athico.com/2007/11/vision-for-unified-rules-and-processes.html
The Drools documentation
http://docs.jboss.com/jbpm/pvm/
Another blog on same subject
http://www.dzone.com/links/a_vision_for_unified_rules_and_processes.html
And yet one more - pretty much the same thing in a different wrapper
http://digg.com/software/A_Vision_for_Unified_Rules_and_Processes
SDG
Yaakov
Posts
Who stole my spring??
-
After a nice 20C degrees day yesterday, I woke up this morning to this:
10 years ago
4 comments:
I still don't get it. Are you saying that rules are declarative, but the very same rules presented as a decision table are somehow less declarative? Please clarify
Snshor:
Decision Tables are nothing more than each row representing an IF-THEN construct under the covers with no forward nor backward chaining; pretty much just Java rules shown in a spreadsheet-like format. Not all rules can be expressed in this highly structured format - only simple business rules that would best fit into a policy manual. (OK, some systems CAN do chaining in a spreadsheet but not normally.)
Declarative Programming is discussed in exquisite detail in most of the books at http://www.kbsc.com/aibooks.html - one of the better ones being Giarratano and Riley, whatever edition you can get. In a nutshell, Declarative Programming is simply putting the rules in as IF-THEN statements in random order and expressing the complex logic wherein each rule is incrmentally independent of the other rules.
In a spreadsheet, the rules are examined and fired as shown in the spreadsheet. If the system is Compiled Sequential then the problem is even worse. In a declarative approach, the rules are fired according to a pre-determined conflict resolution process, sometimes called meta-rules.
SDG
Yaakov
Yaakov,
I have to disagree. Most rules in a business world are structured and already presented in some form of table - for example, how business users communicate the requirements to a BR developer - most probably in Excel spreadsheet. I've seen real pricing rules for auto-insurance nicely fit into less than 20 decision tables. Yes, you might need to provide some "logic glue" to make them work together - but this does not change the fact that the bulk of the rules is table-based.
The idea that unstructured and and "random" rules are somehow better for users and developers strikes me as completely wrong. You advocate development and maintenance nightmare where only a couple of highly paid geniuses can support the system. And plagued is their customer when they leave.
Drools decision tables support chaining (the tables are transformed into drl files), does it change anything? Just the opposite, most of the users want them to be executed exactly in the order they are defined - because business logic depends on it. The problem is not in some randomly defined terminology - like "declarative" or "procedural", but how better capture and efficiently execute user's intent - and if this intent is expressed as a decision table - the worst you can do is to split it into bunch of loosely related "declarative" rules
I blogged in response to Mark's post also - check out this post.
JT
PS Please add www.smartenoughsystems.com/wp to your blogroll as I blog there a lot
Post a Comment