Blogs on top of Blogs

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