OpenL Tablets Apologia
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 Engine Differentiators
OpenL Tablets is a full-blown rule engine based on optimized sequential algorithm which is considered to be the best choice for business rules. Sophisticated pattern matching algorithms like Rete III are not included into OpenL, they are inappropriate for business and are for general purpose rules, e.g. biology simulations (so we believe).
As the simpliest classification one can temper to say OpenL Tablets Rules Engine is a "table processor". At some extend it is a table processor. It takes documents (Excel, Word or clones), extracts tables and then makes them available to access from your application. What features set OpenL apart from the competition?
- OpenL Tablets removes the gap between business documents (rules and policies) and software implementation
- OpenL Tablets checks all data in project documents for syntax and type errors providing convenient and detailed error reporting. Its ability to point to the problem directly within Word and Excel document is unique among other similar products
- OpenL Tablets provides calculation explanation capabilities, making it possible to actually drill down any calculation result with showing all the source arguments within original documents
- OpenL provides cross-indexing and search capabilities within all project documents
- OpenL Tablets makes this process transparent to developers. For example, in Java wrappers Decision Tables become available as methods and Data Tables become accessible as data arrays through familiar getter/setter Beans mechanism. All this is done automatically without any manual effort. This feature makes integration with any application a snap.
This article is an attempt to explain in detail, why OpenL approach is better for real-world business applications. Here is the brief summary of this explanation:
- 90-95% of business logic is table-based or can be presented as table
- Structured information is easier to understand and mantain
- Most of it is already maintained in Excel files
- Most of business logic is either Decision, Lookup or Spreadsheet 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 Tablets is built on top of OpenL 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 user 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, business user extensions.
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 treats 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 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
- Spreadsheet Tables - for Excel-like calculators
- Data Tables for reference data and test cases
- Datatype Tables - to define problem domain inside rules files
- 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 can also use Maven Plugin that will provide it with nice error navigation display during compile or runtime, 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 BRMS must have:
- Rule Engine
- 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.
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
- data validation ->
- calculation of discount/surcharge factors for individual drivers/cars ->
- calculation of integral discount/surcharge factors such as multi-car discount ->
- 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?
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 us 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):
Or like this:
|Gender||Age||Marital Status||Mileage||Use||Bodily Injury||Property Damage||Medical||Collision||Comprehensive|
50 or more rows of similar nature
For us the answer is obvious and we rest our case.
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 - on the way (5.9.0 introduces new UI)
- Use Tables Meta-Information to provide features like Effective/Expiration Dates - done (extremely powerful versioning is avalable starting with 5.5.0)
- Add Advanced Lookup Tables (multi-dimensional) - done (since 5.3.0)
- Add Database Connectivity module
- Enhance Rules Data Type Library
- Enhance Domain Model defininition - - done (more convenient than custom java code, since 5.7.2)
- Add code-generation capability to OpenL - partial (Datatypes are generated as java bytecode since 5.7.3)
- Add generics and convenient Smalltalk-like Collection and Iterator operations
- Add RDF/OWL Type Library, inference engine, move configuration to OWL format
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.
Main Entry: tab·let
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
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).