“When should we, or not, use BRMS?” is the Question that arises almost every time Business Rules Management Systems are under discussion. Well, that’s a decision making, which may be handled by rules, in the form of a Decision Table…
The proposed rules to answer that question are not only based on technical aspects of BRMS, but also on organizational ones. In fact, those organizational aspects are often more important than the technical ones in the adoption of BRMS. Of course, those rules are not well formalized and their “Right Hand Side” (“then” part) may vary depending on the case. However, we hope that the following table could help in choosing or not a BRMS to develop an application.
The pluses and minuses of using BRMS:
| When | And | Short Term Benefits | Long Term Benefits | Classical Programming | Comments |
| Specifications in the form of | Data Sheet | +++ | +++ | – – | Most BRMS are mainly based on Decision Tables |
| If / Then (/ Else) | ++ | ++ | + | “If” may become “when” (“else” is a rules anti-pattern) | |
| Natural Language (DSL) | + | + | – | Some BRMS allow rules in the form of Natural Language | |
| BRMS already in place | & supporting team | +++ | +++ | Let’s go! | |
| & future supporting team | ++ | +++ | Use what you already have, before improving the expertise | ||
| & no future supporting team | ++ | + | Well, long term maintenance is compromised, specially since initial bad choices may be taken | ||
| No BRMS already in place | & supporting team | ++ | +++ | The supporting team will first put in place the BRMS. | |
| & future supporting team | – – – – | ++ | Well, you will have to wait till expertise is available… | ||
| & no future supporting team | – – – – | – – – – | No Infrastructure, Nobody, No Go!!! | ||
| Needs for | Hot Deployment | ++ | +++ | – – | Deployment of rules is usually easier than of standard code |
| Explanation / Traceability | +++ | ++ | – – – | “because of such (intelligible) rules… “ | |
| Fast Code Changes | ++ | ++ | – | Rules are self sufficient pieces of code | |
| (Unit) Testing | ++ | ++ | – | Sets of Rules defined in a Rule Flow can be unit tested | |
| Evolution of Non BRMS Existing Application | +++ | ||||
| Number / Complexity of Rules | High | ++ | +++ | – – – | Long term benefits regarding maintenance |
| Medium | ++ | ++ | – | ||
| Low | – | – | ++ | ||
| Data Matching | Small size | ++ | ++ | – – | RETE is an efficient pattern matching algorithm. |
| Large Scale | – | – – | – – – | See Record Linkage | |
| Cases available instead of Rules | – – – | – – | – – | Instead use Case-Based Reasoning | |
| Organisation | Rigid | – – | – – – | +++ | BRMS may dramatically change the balance between BA, developers and production |
| BA involved | ++ | ++ | – | ||
| Management | Supporting | ++ | ++ | ||
| Opposed | – – | – | |||
| Sense of Security / Confidence | – – | ++ | ++ |
Of course, that table is not complete nor rigid and your comments to improve it are welcomed.
