I don't think anyone really captures their requirements as Decision tables, but many requirements are captured as Excel tables
The BRMS Blog

OpenL Tablets Apologia

OpenL Tablets Differentiators

On the first sight one is tempted to classify OpenL Tablets as a "table processor". In some sense it is a table processor. It takes documents (Excel, Word or clones), extracts tables and then makes them available to access from your Java program. Other programs do it too, so what features set OpenL apart from the competition?

1) OpenL Tablets removes the gap between business documents (rules and policies) and software implementation
2) OpenL Tablets makes this process transparent to Java developers. For example, Decision Tables become available as Java methods and Data Tables become accessible as Java data arrays through familiar getter/setter Java Beans mechanism. All this is done automatically without any manual effort. This feature makes integration with any Java application a snap.
3) OpenL Tablets checks all data in project documents for syntax and type errors providing convenient and detailed error reporting. It's ability to point to the problem directly within Word and Excel document is unique among other similar products
4) OpenL Tablets provide calculation explanation capabilities, making it possible to actually drill down any calculation result with showing all the source arguments within original documents
5) OpenL provides cross-indexing and search capabilities within all project documents

Critics may say, this is all nice, but other products have full-blown rule engines, based on sophisticated super-fast algorithms like Rete III, and OpenL does not, all it does just process the tables. This article is an attempt to explain in detail, why OpenL approach is better for real-world business applications. But, in case if you already are tired of reading, here is the brief summary of this explanation:

90-95% of business logic is table-based

Most of it is already maintained in Excel files

Most of business logic is either Decision or Lookup Tables

If you believe that above statements are correct, then should you choose the tool that takes the best care of the 90-95% of your business logic or the one that handles better the remaining 5-10%? And are you sure that other guys actually do a good job with the remaining 5-10%? If you want to know the answer, continue reading.

OpenL Features

OpenL Tablets is built on top of OpenL - the Open Source framework for developing program languages. It brings to OpenL Tablets the following features:

1. Type Safety

We consider this one of the necessary requirements for modern software tool. Increased complexity of software systems implies that a programmer should get as much help as possible at development stage. Compile Time type checking does its part.

2. Extended Type System.

Most programming languages work nice within their semantic paradigm. For example, Java and Java tools provide very nice support while you are within Object/Class world. Once you step outside and start to deal with external entities like database tables or web forms, you find yourself in a completely different world - you have to work through APIs that mostly understand only strings and numbers. OpenL allows you to extend Java type system by custom type systems, that can be accessible at compile time and therefore become an integral part of your application. Examples of such system could be already mentioned database schemas, XML files (schemas), OWL/RDF types or (as in OpenL Tablets) Excel tables.

3. Syntax/semantic flexibility.

OpenL makes it possible to have customized syntax for your programming needs. At current stage we came to the conclusion that the optimal syntax would be somewhat limited Java syntax (it makes it immediately familiar to anybody with C++ or C# background) with following extensions: operator overloading, extended type syntax.
Having Java syntax/semantics at the core of the language greatly reduces the learning curve for developers. Having the ability to overload operators simplifies code for formulas. Extended type system provides compile time type checking and allows to incorporate external APIs and data structure directly within familiar Java syntax. This is important, because business logic is independent of implementing APIs.

OpenL Tablets Advantage

OpenL Tablets treat tables in Excel and Word files as a source code. It means that Excel and Word documents become source code files, same as .java files for Java program. This approach may be unusual, but it has it's own unique advantages, in particular it allows to close the gap between business world and IT world. Let's consider a typical scenario where Business Analyst (BA) creates design documents, includes there business model, business rules and business processes. In most cases it results in a set of Word and Excel documents. Then, IT specialists, architects and data modelers translate business documents according to their understanding into software artifacts - in most cases into UML model. In general, there is no formal link between the original documents and resulting model. Therefore, the only way to keep software consistent with the model is through tedious error-prone manual process. While OpenL Tablets approach does not solve this problem completely, it allows to reduce significantly the costs of this translation in following areas:

Business Rules - in most information-intensive businesses (insurance, finance, banking etc.) 95% of business rules are either already presented in Excel (or Word) tables or can be easily presented as such

Lookup Tables

Data Tables for reference data and test cases

Finite State Machine (FSM) Event Transition Tables for business process/lifecycle modeling

Our experience shows that these areas cover significant part of development efforts, and these are the areas where OpenL Tablets indeed outshines the competition. Let's imagine scenario where most of your business knowledge is presented in form of the tables mentioned above. For our competitors Excel tables are just an auxiliary tool to import data, their support for the tables is minimal, usually through "import" function in menu. Needless to say, that this treatment of the medium where most of your business knowledge is contained is neither sufficient nor acceptable. OpenL Tablets provides both business user and IT specialist with a rich and comprehensive set of tools to make maintenance of your business knowledge presented in Excel and Word documents a simple task. Business User has a choice of working either in familiar Excel application or through the Web interface. IT specialist will prefer using Eclipse Plugin that will provide it with nice error navigation display during compile or run time, Java integration tools that automatically generate Java wrapper classes, unit tests, debug facilities, version control etc.

OpenL Tablets vs. Traditional BRMS

It has been a common knowledge for a while that a "real" BRMS must have

Rule Engine based on Rete Algorithm

Rule Language (universal and domain specific)

IDE to capture rules and organize them into rule sets

Rule Storage Format - i.e. files where rules are stored

Each of this "must haves" has its own implications. The industry cheerleaders will tell you only about positive ones, so we will concentrate only on the negative ones.

Rete Algorithm

The article from http://en.wikipedia.org/wiki/Rete_algorithm states that Rete Algorithm provides an efficient implementation of pattern-matching algorithm for production (expert) systems. It provides a significant (orders of magnitude) performance advantage over the naive implementation.

This statement is definitely true. Also, the truth is that Rete algorithm provides a significant performance/memory overhead over implementations that take advantage of having rules in structured form like decision or lookup tables.

In addition, the dynamic nature of Rete algorithm (strictly speaking, it's not the algorithm itself, it is the semantics of the production systems it is built to implement) makes it difficult to debug programs due to the fact that many problems become visible only in run-time. You have to worry not only about business logic but also about some obscure "rule salience" factors.

It does not mean that production systems are bad, there are areas where they can be used with a great success, for example to expand OWL/RDF axioms etc. Unfortunately they are less suitable and less efficient when we deal with "modern business process". Modern Business Process is

a) Streamlined to the point where no "deduction" is necessary; one can come up with a few exceptions to this statement, but they are definitely not mainstream
b) Most of decisions are table based, because rules must cover all the "input space". Nobody creates a single rule for 23 years old driver, instead there is a rather big decision table that includes all driver age ranges usually in combination with other factors, also in a range mode to cover all the possible combinations of possible input data.
c) The process itself is rather sequential, it consists of well-defined stages that follow each other in strict order, for example, insurance application processing order is
1) data validation -> 2) calculation of discount/surcharge factors for individual drivers/cars -> 3) calculation of integral discount/surcharge factors such as multi-car discount -> 4) calculation of the entire policy or rejection based on previous calculations

It is possible to use production system for this kind of problems, but is it necessary? For example, instead of explicit sequencing, people often use so called rule salience or priority to do the job. Needless to say that this approach looks as transparent and fresh as line numbering in first Basic.

In addition to performance overhead, you will need a very qualified "knowledge engineer" a.k.a. "business rules expert" who will be able to take care of all the problems with performance, debugging and sequencing. But should you have these problems in the first place?

Rule Language

All BRMS use some rule language to express the rule logic. There is no standard for this language even though there are attempts in this direction like RuleML (it is not so much a language, rather rule-interchange format). So goes your rules portability. In OpenL your business logic presented as tables in Excel is platform-neutral. Plus you have the following advantages over other approaches: it is easily to distribute your rules, anybody who has an Excel or Open Office (and who does not??) can read them; you can easily export them to any other system including PDF files or database. And, finally, if you later switch from OpenL to competition for some unknown reasons, they all provide some ways to import these tables into their systems.

So let me summarize, when you write rules as text, the logic is dependent on the rule language, when you use tables, the logic is language-neutral.

There are some attempts to use "natural English language" to define rule logic, some of them are really impressive like Haley's Authority. Others chose the path of DSL or Domain Specific Languages that basically are the set of parameterized language constructs that also look like natural language to the end user. But the real question is, what is better, to have your rules in this form (a bit pre-fabricated example, but anyway, it demonstrates the problem):

Rule  CF1
When
	Driver has gender "male" AND Driver has age at least 16 AND at most 20 
	AND Car mileage is at least 0 miles AND at most 10000 miles AND Car use is "pleasure"
Then
       Set Factor with name "classification" for Coverage named "Bodily Injury" to 3.90 
       AND Set Factor with name "classification" for Coverage named "Property Damage" to 3.90 
       AND Set Factor with name "classification" for Coverage named "Medical to 2.10 
       AND Set Factor with name "classification" for Coverage named "Collision" to 4.45 
       AND Set Factor with name "classification" for Coverage named "Comprehensive" to 2.95

Rule  CF2
When
	Driver has gender "male" AND Driver has age at least 21 AND at most 24 
	AND Car mileage is at least 0 miles AND at most 10000 miles AND Car use is "pleasure"
Then
       Set Factor with name "classification" for Coverage named "Bodily Injury" to 2.00 
       AND Set Factor with name "classification" for Coverage named "Property Damage" to 2.00 
       AND Set Factor with name "classification" for Coverage named "Medical to 1.50 
       AND Set Factor with name "classification" for Coverage named "Collision" to 2.55 
       AND Set Factor with name "classification" for Coverage named "Comprehensive" to 2.20

Rule  CF3
When
	Driver has gender "female" AND Driver has age at least 16 AND at most 20 
	AND Car mileage is at least 0 miles AND at most 10000 miles AND Car use is "pleasure"
Then
       Set Factor with name "classification" for Coverage named "Bodily Injury" to 2.80 
       AND Set Factor with name "classification" for Coverage named "Property Damage" to 2.80 
       AND Set Factor with name "classification" for Coverage named "Medical to 1.90 
       AND Set Factor with name "classification" for Coverage named "Collision" to 2.90 
       AND Set Factor with name "classification" for Coverage named "Comprehensive" to 1.60

.....................................
50 or more rules of similar nature

Or like this:

.....................................
50 or more rows of similar nature

For me the answer is obvious and I rest my case.

Rules IDE vs. Excel

OpenL Tablets provides the programmer with Eclipse Plugin that takes care of programming needs such as compiling, building, running, version control and error reporting. There is also a web interface that provides project navigation, search and other advance capabilities. As an editor we recommend using Excel. There is a common opinion that Excel provides less control and gives end user too much freedom. We agree with this statement, and our approach is to use programming tools and organizational methods to neutralize possible negative effect of this "freedom" and maximize benefits from Excel flexibility, features and ubiquity.

The Road Ahead

The following is the list of tasks OpenL team will concentrate it's efforts in a near future. They will provide user with even more advanced capabilities and enhanced experience:

Improve Web Admin Interface

Use Tables Meta-Information to provide features like Effective/Expiration Dates

Add Advanced Lookup Tables (multi-dimensional)

Add Database Connectivity module

Enhance Rules Data Type Library

Add code-generation capability to OpenL

Add generics and convenient Smalltalk-like Collection and Iterator operations

Add RDF/OWL Type Library, inference engine, move configuration to OWL format

Conclusion

At the end we recommend you to take a close look at your application. If you see, that a lot of business logic is already presented as tables, or can be easily presented as one, you owe to yourself to give OpenL Tablets a try.

Origins

Main Entry: tab�let
Pronunciation: 'ta-bl&t
Function: noun
Etymology: Middle English tablett, from Anglo-French tablet, diminutive of table
1 a : a flat slab or plaque suited for or bearing an inscription 
  b : a thin slab or one of a set of portable sheets used for writing 
2 a : a compressed or molded block of a solid material 
  b : a small mass of medicated material "an aspirin tablet"

We believe Webster guys are going to update the entry soon:
 
3 Tablet - executable decision or lookup  table of well-defined structure. (comp. slang). See applet, servlet, pagelet

And if they are not, there is always Wikipedia

Disclaimer

In all OpenL Tablets documentation you can freely substitute table for tablet and vice versa without loosing any bit of useful information, we just think that tablet is cool and table is square (or rectangular).