When IT systems become bigger and more complicated, it’s getting harder to maintain complex business logic just through a raw implementation in the code.
Changes in hard-coded logic can be costly and time-consuming. When such problems occur, that’s the signal that we should consider passing control over such logic to business users.
How can they control and change the business process without re-implementation?
Well, it can be done through many ways. The most known approach is to define such a process in the form of workflows or business rule engines (BRE). Usually, both of them eventually affect changes in some store like a database. However, this could also be a volatile database in memory. Regardless of a state persistence, we call this domain a working memory.
Workflowsand business rule engines are familiar concepts, but as they could be used interchangeably as a tool to achieve some goals, it’s often hard to distinguish between them.
First, let’s try to describe how they work.
Workflows
Workflows present a business process by dividing it into a structure of smaller activities (work to do) and connections between them. The business user creates a workflow, probably in graphical UI, by selecting desired activities and matching connections between them. For each connection path, he should define conditions stating when which path should be taken.
For activities that join several paths, some synchronisation strategy could be defined to decide if given task has to wait for a result from all of its predecessors or not. Workflows are very good for modelling any state change flow as it’s easy to determine the sequence of activities through workflow chart.
Let’s consider a classic example – a bank client wants to withdraw money from a cash machine:
Rule engines
They are a set of rules, sometimes referred as business rule engines (BRE), which when complied, will execute some specific task. These rules are constrained by conditions called patterns. Such rules are created by business users/experts and called a knowledge base. We can distinguish two types of rule engines:
1. Inference engines
They allow for obtaining new knowledge based on given knowledge base, which in fact makes them an expert system. They can be used to solve complicated problems that are hard to decipher algorithmically. Usually, they use rules defined in the form of “If… Then…”, so such a sentence is the combination of antecedent and consequent:
They can support forward and/or backward chaining.
- Forward chaining inference is a situation when we have particular knowledge base – we can obtain new knowledge by applying data to possible antecedents. Eventually, It results in some consequents, and each consequent can be used (chained) further as another antecedent.
For example, let’s say that we have such a knowledge base:
If an animal has wings then it’s a bird.
If an animal is a bird then it can fly.
Forward chaining rule engine can infer that if an animal has wings, then it’s a bird, which can fly.
- Backward chaining inference is a situation when the inference flow is being reversed. If we have the same knowledge base as above, such an engine can infer that if the animal can fly, then it is a bird, so it has wings. It’s also called goal-driven.
Inference engines can utilise both forward and backward chaining at the same time. However, there can be some rule collisions like that one when we add another rule to our example:
If an animal is a chicken then it’s a bird.
Because chickens are birds that don’t fly, it causes a collision which states that an animal with wings is a chicken and it can fly.
Nevertheless, inference engines can handle such situations as in this example by adding specific priority or other fuzzy logic solutions.
2. Reactive rule engines
They are continuously checking if any rule has been complied. If yes, they execute the required task. In such engines, rules are called event-condition-action (ECA), which may consist of three parts:
- Event that is triggering rule test
- Condition to check
- Action to take place when specific condition occurs
The exact structure may vary and may take some mixed form. But reactive engines can make great use of forward-chaining to trigger actions that are dependent on previous action results. However, in such a case, each operation should generate some state change in our working memory.
After understanding different approaches to rule engine types, let’s try to define some rule set, that could potentially mimic our credit card. For example:
And as it seems to be event-driven, it would be used by the reactive rule engine.
Workflow or rule engine?
We have achieved the same result with rule engine as with a workflow but in a different way. The latter approach gave us a tree structure, which seems a bit unreadable when compared to workflow graph, though the same goal could be achieved. Instead of using activities, we have used event-driven rules, but we should remember that we need some state persistence in working memory for actions of our events. Nevertheless, such a working memory could also be volatile in long-term like cash machine RAM is.
If they could be used interchangeably, which one we should use? Well, that’s hard question, but workflows seem to be more suited for short-living processes, and reactive rule engines for long-lasting event-driven ones. But this isn’t some rigid rule, and it depends on a process.
On the one hand, workflows are an excellent tool for modelling business processes as a whole, and on the other hand, rule engines allow to apply business conditions that take specific actions efficiently.
Regardless of which one we will choose, both are an introduction to some level of flexibility to our systems, which eventually, could be forged into cutting on costs and increasing usability.
Learn more about business processes and BPM software
