On March 4 we announced the launch of our new major release OpenRules 6.0.1.  It is a very important event in the OpenRules history and probably beyond.   It actually brings us much closer to the initial BRMS promise.  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!”

Since then the progress was tremendous:  solid methodological approaches, super-fast rule engines, powerful rule languages, human-friendly rules management GUIs for business and technical people have been developed by various BRMS vendors.  Successful rules-based applications indeed extracted business logic from code, and business people got much more control over it.

However, real-world BR practitioners frequently say: “well… probably not real control but at least now business people got a good understanding of what’s going on in their IT systems.”   The common wisdom even among the biggest decision management promoters came to the acceptance of the cold reality when “IT writes rules in a way that BUSINESS understands and may change them”.

In 2003, when we started OpenRules, we had already used the best available BR tools for years helping major corporations to develop large rules-based applications. We even created (and then sold) our own BRMS.  So, we were well aware of real-world limitations of the BR products and our intent was to break barriers for BR acceptance by business analysts.  We asked ourselves: what are the technical factors that prevent subject matter experts from really creating and maintaining business rules? Our answers were:

1. The necessity for business rules semantics to be expressed in a rule language
2. Proprietary rules management GUIs.

How did a newly born OpenRules address these questions at that time? First of all, we decided not to develop (again) a new rule management GUI – even the best BRMSs were trying to reproduce “Excel-like” interfaces and to hide underlying rule languages.   Proprietary rules management GUIs force users to go through a lengthy learning curve – their users must acquire a completely new and unique kind of knowledge.  Our solution was to use Excel directly as de-facto the best business interface for rules management!  Anyway, in real world most business rules are initially presented by business people in Excel, but different BR systems force their users to move rules from Excel into their proprietary environments (even if a direct import from Excel was added by many vendors later on).   The OpenRules Engine from the very beginning was able to execute rules directly from Excel files. The proposed Excel-based OpenRules decision tables had two views: Business and Technical.  The Technical View was considered by us as an unavoidable “evil” that at the same time can help to express the exact semantics of frequently very complex rules.  The Technical View consisted of “Java snippets” but no new rule language was required.  These snippets were placed directly into decision table rows, which could be hidden from business people by using handily available Excel Outlines.   Using Java snippets avoided the introduction of a new rule language and permitted a simple and direct integration with existing Java-based systems.  This practical approach together with “open-sourceness” quickly gave OpenRules a wide popularity.

In 2007 OpenRules 5 introduced very powerful 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 rules based on them.

That brings us up to the present.  With our newly announced Release 6 we have managed to eliminate the need for technical views altogether.  Not only Java snippets become obsolete but we also eliminated the need for complex rule signatures with strictly typed parameters that previously made rules to look like Java methods.   You do not have to create custom rule templates either – one universal template provided by OpenRules 6 satisfies most needs for even the most complex rule families.

OpenRules 6 implements so called “Executable Decision Models” that allow business analysts to create and execute (!) decision models without IT involvement.  The new release effectively removes any programming from the representation of decision tables and allows business analysts themselves to specify their decisions directly in Excel.  Now business analysts can define business glossaries and test cases using predefined Excel tables; they can then execute these decision models to validate their accuracy.  Once a decision model has been validated, it can be easily incorporated into any Java or .NET environment.  This integration process may involve IT specialists but only to map OpenRules business glossary to a specific business object model.  The business logic itself remains completely in the hands of subject matter experts!

I do not like to use words like “breakthrough” or “watershed” especially when it comes to software development.  But if somebody told me a year ago that what OpenRules 6 does today is possible I probably would be skeptical. I would like you to judge for yourself that what I am saying is not another marketing statement.  You may want to go through this detailed example and download OpenRules 6 to run it.  You always may start with a free evaluation version, but for a nominal fee OpenRules customers receive a complete Release 6.0.1 including software, documentation, sources, along with access to the Priority Support, the Inside Track Program, OpenRules Dialog, and more.

And, finally I want to thank Larry Goldberg and Barbara von Halle whose book and personal discussions inspired us to eliminate unnecessary coding inside OpenRules decision tables.