where Business Processes, Data and Rules meet.
Blog
Home / Business Rule / Flow Orchestration Simplified – Using Decisions

Flow Orchestration Simplified – Using Decisions

0

In a couple of previous posts, we discussed why you should not use a Workflow to implement business logic. Business processes (e.g., Workflow, Rule Flow, Data Flow, etc.) are for orchestrating the sequence of tasks to be executed.

In this post, we are going to show you an example on how to apply a decision to simplify your flow, as well as discussing other benefits of this approach.

Let’s say we have a generic flow that executes tasks based on person’s title (i.e., Infant, Kid, Teen, Young, and Adult).

If you are going to model the entire logic as a process, you will end up with something similar to the following flow:

flow

Issues

As you can see in this flow, the logic of the business definition for a Person’s Title is modeled inside the flow itself. This approach has many issues, including:

  • It makes the process convoluted and less clear. (Hard to understand)
  • This logic implementation does not have anything to do with process goal itself. (Single responsibility violation)
  • Changing the logic (e.g., range of ages for different titles) will require a process change. (Change/Deployment complexity and overhead)
  • The logic is not reusable between different processes and/or applications. (Reusability issue)
  • Logic cannot be tested without running the whole flow. (Testability issue)
  • Testing the logic can be done only by asserting the impact of it on the entire process. (Testability issue)

Solution

We just need to introduce a decision model to encapsulate the Person’s Title decision. This can be simply done by using a Decision Table, as shown below:

flow-age-dt

Now by modeling this logic separately, we can reference and use it in the process, and the result will look much better:

flow-better-dt

As you can see now, the flow (i.e., your business process) is much less complex.

Please note this is just a simple flow and those are also conditions are mutually exclusive (a person cannot be a teen and an infant). In a real business process, the conditions can be satisfied using multiple different routes and the process itself is more complex. Extracting the business logic from the process will significantly reduce the complexity. So you can model a simpler flow (i.e., business process) and manage it more easily.

Also, if the logic is more complex than a single Decision Table, you can always use Decision Model and Notation – The Decision Graph.

Conclusion

In this example, we replaced 9 different nodes in the original flow with 1 Decision Table! Extracting the business logic and definitions from your process model (e.g., flow) will not only significant reduce the complexity of the process itself, but also have the following positive impacts:

  • Logic can be shared between other processes (flows) and applications
  • Quality of logic can be increased and guaranteed as the intention of the logic can be tested
  • Process (e.g., flow) can focus on its goal rather than trying to implement business logic (Design benefit)
  • Process can take advantage of complex decision-making models (Decision model and Notation)

Read More

  1. XBRL and Standard Business Reporting
  2. Boxed Expressions – DMN
  3. Decision Model and Notation – DMN
  4. Reusable DRD or Sub DRD in Decision Model and Notation (DMN)
  5. What is a Decision Requirement Diagram (DRD)?
  6. Decision Graph and External Datasource
  7. Decision Model and Notation – DMN
  8. Decision Table Advanced Conditions (Simple, Optional, Partial and Calculated Conditions)
Recommended Posts

Leave a Comment

You must be logged in to post a comment
Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.