I read the article reference by Ernest, and it's quite good - excellent, in fact. In light of that, I suppose one more voice will just confuse the issue even further, but, nevertheless, here goes. There are any number of good reasons to use a rulebased system (expert system, if you will) for a project AND some good reasons NOT to use a rulebased system. Let's discuss the reasons for not using one first.
1. Upper/middle/lower management doesn't like the idea of tampering with what is already working. "If it ain't broke, don't fix it." <Obviously not your problem in this particular case.> 2. Primarily the system is to be used for computational logic rather than business logic. For example, many engineering programs would fit C/C++ or FORTRAN better than a rulebase. 3. No funds have been allocated for training, which should take place before, during and after the project is implemented. Training of existing personnel and maintenance personnel is a frequently overlooked issue, as is the issue of whether to hire consultants who actually know how to do the project and who to call to do it. 4. Business logic is very simple <again, not your case> and a tree diagram of the logic can be displayed on one or two pages of paper. 5. The "business logic" is mostly data validation rather than making business decisions. 6. NIH (Not Invented Here) mind set of the programmers and any layer of management. 7. Project is perceived by other departments (on whose support you must depend) as really cool and the project belongs in their department, not yours, thereby generating internal political wars. In other words, if we can't do it then we'll make sure that you don't do it. 8. Using more than one Beta product or non-supported software on the project. 9. Speaking of training (#2 above) - training and ramp-up time for existing personnel is critical. Even really good Java and C/C++ programmers sometimes have a hard time thinking declaratively rather than procedurally. For someone new to rules, things that were done by instinct in Java take more time to do in rules. You have to allow for that time. 10. Finally, the time problem. Usually a project has a time line set using the same logic as if it were going to be done using conventional programming. The ramp-up time is not taken into consideration and the time line is extremely short. As a rule of thumb, figure 4 - 12 rules per day per person. That 4 - 12 rules per day includes analysis, rulebase design, writing and initial validation. Using 8 rules per day as an average, you should have about 80,000 person-days (64,000 person hours) allocated for the project. That's the KE's and RE's only; not the BA's, managers, technical writers, etc. that must be included on the project. Any one of these "could" doom the project but will, in any case, cause substantial problems.. Three or more spell complete doom. On the other hand, there are many reasons to use a rulebase rather than procedural or OO architecture. 1. Rules are declarative, not procedural. Tremendous advantage. Rules are stated just like you think. 2. Rules are recursive, a feature normally referred to as "non-monotonic" in nature. For example, suppose you have a listing of 20 IF - THEN - ELSE statements. Statement 5 was found to be false. ()r true, doesn't matter) Statement 17 changes the data that was examined by statement 5 so that now it is true. Statement 5 is not re-examined. Procedural logic is monotonic - one time through the loop and you're through. 3. Normally, rules can be updated, changed, added or deleted without having to re-compile the associated code. 4. Some rulebase systems have a GUI such that the Business Analysts can view the rules, which are stated in a business-like syntax, and can (usually) understand the logic. This makes initialization and trouble shooting the logic must easier and faster. 5. Rule maintenance, therefore, is normally done not by the IT department but by the BA's. (With that said, recognize that a rulebase is of the same or greater complexity as a database. You would never have the BA's design an enterprise-sized database. Ergo, you would never have BA's design an enterprise-sized rulebase, would you?) Some systems even have the capability to totally "hide" the underlying complexity of the rule syntax and have the BA's see only the English language version, which should match their documentation. 6. Normally, properly constructed, a rulebase is much, much faster doing such things as solving complex logic problems or pattern matching. 7. Debugging 10,000 rules in a rulebase is EVER so much easier than debugging 10,000 rules written in Java or (God forbid) COBOL. Finally, if you've never done a project of this magnitude, in the name of all that's holy GET HELP! I've seen rulebased project after rulebased project fail because the company went the "cheap" route and tried to do it with all in-house personnel, or maybe with only one experienced KE. And then the philosophy was, "Well, we tried to use that AI rulebase stuff. It just doesn't work in a case like ours." Yeah, right. As thought that particular company was really that special. Enough for now. Drop me a line or give me a call if you want more specifics. -- SDG jco --------------------------------- James C. Owen Senior KE Knowledgebased Systems Corporation 6314 Kelly Circle Garland, TX 75044 972.530.2895 Jeff Richley wrote: > I have a project that has roughly 10,000 business rules. Another major > factor is that there are 13 programmers (not including myself) and I am the > only one that has ever programmed in Java. The powers that be have decided > that we are going to write the entire program in Java. There are some very > good reasons for this decisions that I won't go into right now. > My question is, would JESS be a good solution for all of these rules. I > haven't really gotten a good handle on exactly what is required to use > Jess. Is this something that I would be able to give a statement like "if > all of the planes were unmanned then field x must be equal to 'q'"? Or is > it something that I would actually have to program that statement? > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - File online, calculators, forms, and more > http://platinum.yahoo.com > > -------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > in the BODY of a message to [EMAIL PROTECTED], NOT to the list > (use your own address!) List problems? Notify [EMAIL PROTECTED] > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
