First: BRMS could technically be nothing more than a sheet of paper. More sophisticated systems could be nothing more than SQL-driven database or a spreadsheet, whether electronic or manual. A "Rulebase", on the other hand, is something that is NOT strictly business related, but could be used by R&D, Engineering, Mathematics, Business, Doctors, Psychology, Philosophers - pretty much anyone who had a really complex problem that need solving.
Unlike SQL and BRMS that are fairly procedural in the thought process, a rulebase is characterized by two things; the rules can be incomplete AND the rules can be entered in a random process sometimes called Declarative Programming. This is how the mind operates, not how a business operates. A rulebase was originally developed to emulate how the mind thinks - ramdomly and adding or deleting rules as needed to solve a particular problem. This is what is know as non-monotonic nature of a rulebase.
Now, why write about something so mundane when there still exists the P != NP / P = NP problem? Well, it's because WAY too many people in our world seem to think that a BRMS is the same thing as a rulebase. They aren't! The BRMS is a special case of the rulebase and, fortunately or unfortunately, it's the BRMS that pays the bills. Unfortunately, the business guys (you know, the ones with all of the money) are the ones who dictate the direction of the rulebase world.
So, it's high time for the Geeks to take control and make the rulebase once again predominate. The business guys have had plenty of time to screw things up - and BOY! Have they ever! Project after project after project has failed because the business guys or the IT Java geeks got control of the project and turned it into something that the originators never though would happen; a project that was driven by just dumping rule after rules after rule into the pot without any "real" thought process whatsoever. To even suggest that the company rules are in error is usually met with scepticism and derision. But, my experience has shown that the thought "process" of business rules is normally in error. I have tried on project after project after project to direct the process to the "why" rather than the "how" of a solution.
So, the next time someone mentions using a BRMS for a new project, ask them WHY they want to do this? If it is so that the business department can control the rules, RUN!
SDG
Yaakov
Posts
