There is divided opinion on the value of using a Rules Engine. Being able to deliver business rules with no-code approach implemented by business users themselves is certainly an advantage.
However, many of these initiatives fall short. This is because a Rules Engine on its own is not enough.
The dynamic that delivers the value of a Rules Engine is that it creates an abstraction layer for the Business Logic to be implemented without requiring programming skills. But the Business Logic is embedded in a Business Process. Therefore, we also need to be able to create an abstraction layer for the Process Logic. In this way, we can have business users build the Process Logic that contains the Business Logic.
As the advert goes, “But wait, there’s more!”.
For the Business Logic, within the Process Logic, to be able to execute its rules it needs data. This means we need an abstraction layer for Data logic (i.e. Information Requirement Diagram), where the data abstraction layer is usable by business users to enable data connection and composition.
Now we are good to go. We have the Data Logic, feeding the Process Logic, which is executing the Business Logic. Right? Well maybe.
It depends on how we have implemented the Business Logic abstraction layer. If we have done it just at the Rules level we can run into the problem of a “big bucket of rules”. That is, we have too many rules, which makes it difficult to keep track of the priorities and dependencies. This means it is easy to create overlaps and conflicts. Therefore, within the Business Logic layer we need a Decision Logic layer, or in the Decision Management Notation standard, a Decision Requirements Diagram that sits on top of the Rules layer.
Now we are good to go.
With the capability of Process Logic, Data Logic, Decision Logic and Rules Logic we can now deliver on the original value proposition of no-code approach and implementation by Business Users. This is not true if we just use a Rules Engine because we find we are doing much more coding in all the other areas.
Fortunately, this is the strength of FlexRule. FlexRule provides Process, Decision, Rules & Data Engines which deliver all the abstraction layers required to deliver no-code platform for business users. Oh, and did we mention Workflow Engine? We will talk about that in another post.
Having all this capability and building blocks is why we often describe FlexRule as “Minecraft™” for Business Processes!
™ Minecraft is a registered trademark of Mojang Synergies AB