We have been asked a lot about when to use Workflow and when to use Business Rule Engine (BRE), so I decided to post a blog on this topic.
Let’s consider from the outset the definitions of both workflow/process and business rule.
Workflow and/or business process is an orchestration (order or sequencing) of a collection of tasks (e.g. activities, actions, operations, etc.) in which the sequence is important. The process or workflow manages the sequencing (order and timing) of tasks to be carried out with the right actor at the right time, using the right tools.
Generally, you can use Workflow/Process designer to create a template (process/workflow template) and let an engine (workflow/process engine) run an instance of the template for you.
Also, workflow/process engines are capable of handling long-running processes (i.e. long-running business transactions). So, a workflow/process may take days or even months to be completed. It stores the state of workflow/process in a durable condition and reloads this when it needs to resume from the last point. It also allows you to consider some external events in order to start or resume a workflow/process.
The sequencing (order and timing) of tasks can be parameterised and become conditional by using decision points in the process/workflow model. So a case that is being processed by a process or workflow can be routed to different paths.
On the other hand, Business Rule is a criterion used in business operations to guide behaviour, shape judgements and make decisions. Structurally, a business rule consists of a set of conditions and a set of actions. When those conditions are met, the actions are taken. As you can see from the definition, these are not about orchestrating tasks, but are about the definition of criteria by which they guide behaviour or make decisions (the ‘actions’ part of the rules).
For example, the following statement is a business rule:
If a car has no airbags then car 'rating' of 'potential occupant injury' is 'extremely high'
This defines the rating of a potential occupant injury in a car.
A set of business rules, called a ruleset, can be modelled in a tabular form (Decision Table) or Tree form. For more details, please visit our previous posts.
When multiple rulesets (i.e., tree, decision table) support a scenario (guide a decision) a Decision Model and Notation (DMN) can be used for modeling these and managing the dependencies between them.
We have seen many situations when a Workflow/Process Engine is used to replace the behaviour of the Business Rule Engine (BRE), or the other way around. There are some similarities between them. For example, the Workflow Engine or Business Rule Engine allow a non-technical end-user to change some behaviours at runtime without requiring any change to the code. However, they have many more differences than similarities.
For instance, just for fun, try to implement these business rules in a process/workflow model as a set of decision points and tasks (actions). Make sure your process/workflow model does not have duplication of any nodes (neither actions nor decision points). I bet you will give up half way through this exercise!
It gets very complex, very quickly. The number of check points you need are multiples of all available condition values.
For example, if you have
* Condition A: Y, N
* Condition B: 1, 2, 3
* Condition C: Y, N
In this example, A and C have 2 values, and B has 3 values. Therefore, the number of scenarios to cover are 2 x 3 x 2 = 12
A workflow/process is not for implementing the logic of how things are done. Rather, it is for orchestrating the timing, order and sequence of tasks (when a task should be done and by whom). If you do implement the “HOW” in the process template (workflow), then it becomes too convoluted and impossible to understand without changing the process or workflow.
In the first place, you extracted the application logic from the code and put this into workflow/process engines to make it more adaptable to change, right?
Well, if you do implement the “HOW” of logic in the process, you fail to deliver what you promised! How comfortable are you about understanding and changing the following process?
An even harder challenge is to add 2 or 3 more decision points to the above flow and to ensure you cover all the possible scenarios without compromising the correct behaviour! Think of it in this way – when you implement “HOW” into your workflow/process it won’t be any different from when you implement it into your application source code! Why? Because at the end of the day, you cannot change the process/workflow when it is as convoluted as the above example.
The next time you pick a workflow/process engine to replace rule execution behaviour (validating conditions, evaluating decision points, etc.), remember you are adding more complexities as the flow grows. And when this happens it is not any different from hard-coding the decisions into your application code, although I reckon you’d be better off hard coding the whole decision logic (“HOW”), and representing it as a single decision (method call, service call, etc.) in a flow (process/workflow), because at least the flow will be simpler and more amenable to change.
Remember, workflow/process is for orchestrating tasks (actions, operations, etc.), not implementing “HOW’s”.
If you need to manage, implement and execute “HOW’s” either in your workflow/process or application code, then the business rules approach will be more beneficial for you:
1. You will have a single source of truth for a decision point across all processes and applications
2. You simplify the process/workflow, which becomes easier to understand and change
3. You can maintain, manage and execute different versions of the decision logic (rules) for different contexts
4. You can simply expose the business decisions and business rules as a REST API service
If you want to know more about the benefits, please have a look at http://www.flexrule.com/business-agility.