There is a question posted yesterday at the OpenRules Discussion Group: “Is there a reason why you would steer actively away from Rules and into Decision?”

A simple answer is in another question: “I’m working on a project in which the business person wishes to have a strong control on his business rules and it may not be feasible to let the technical staff edit the sheets in order to code rules.  So, I ask you if the same example would be possible to be written without “hidden rows”.  Is there any situation in which the technical specialist doesn’t need to take part in “translating” the rules to programming language code?” posted by Monique Louise just a day earlier. Monique initially looked only at our Rules tables with separated technical and business views but probably not at Decision Tables with no coding.

I believe the question “Rules vs. Decisions” deserves more explanations. When we announced OpenRules-6 with Executable Decision Models, I posted my thoughts about “business rules” history: “When expert systems came back in 1996-97 under a new name “Business Rules”, the main promise that gave this movement a new life was: “Return Control over Business Logic back to Business People!”

In OpenRules, our initial intention was to accommodate cooperative work of subject matter experts and software developers while defining and managing business decision logic.  From the very beginning, we decided not to develop (again!) a proprietary, “Excel-like” rule editing GUIs but rather let users to directly use Excel with Java snippets. Thus, our, now highly popular, “Rules” tables with business and technical views came to life. Inside a hidden technical view, developers may use Java directly (without any artificial rule language) to describe semantics of rule conditions and actions of any complexity.  In 2007 we introduced Rule Templates which allowed our users to move technical views to a limited number of templates while hundreds and even thousands of rules were created based on these templates.  It nicely separated rules management responsibilities:  IT specialists help to create templates and business specialists create and maintain rules based on them.

We did not “steer away” from this approach and continue to actively support Rules and Templates.  Many of our customers really like this approach with a nice cooperation between business and IT departments. However, it still keeps IT involved into business logic definition and maintenance.

With OpenRules-6 our customers got an opportunity to use new tables to represent  Decisions, a business Glossary, and different types of Decision Tables with zero coding. “No hidden code” also means that business people can define and maintain their business logic by themselves with no IT involvement. Now, IT participation may be limited to an integration of decision models, created and tested by business analysts, into a specific IT environment. Developers do not even have to look at Decision Tables. We certainly promote this approach as it brings all of us closer to the initial promise of the Business Rules movement.

Now, OpenRules customers have a choice between Rules and Decisions (with Glossary and Decision Tables). They even may mix both approaches: we already see the situations when customers start with Decisions but add their own Rules whenever necessary (taking an advantage of the fact that they always have an access to objects defined in the Glossary). They also may customize the decision templates (available in Excel) to add an additional functionality. And when customers have a choice, they will always find the best alternative for their particular technical and organizational environment.