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 model simple workflow rather than chaotic ones, the we are going to discuss 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:

simple workflow

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 and Change)
  • 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)

These will introduce a technical debt, and like any other debt your have to pay it otherwise the consequences of not addressing them a barrier to operating business.

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:

simple workflow

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

simple workflow

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

Please note this is just a simple workflow 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 simple workflow (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 Requirement Diagram to handle interaction between decisions.

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)

Learn More

  1. The Big Myth in Decision Management and Business Rules Management
  2. How Underwriting Teams Can Rely Less on Software Development and IT Teams
  3. Challenges of Scaling Decision Automation
  4. Drawbacks of Embedded Decisions in Processes
  5. Diabetes Meal Planning Using Decision Analytics
  6. Vehicle Insurance Claim Settlement
  7. Updating Business Rules in Insurance Underwriting
  8. Navigating Data to Rule-Driven Business Decisions
  9. Regulation Implementation in Decision Management
  10. Automated Credit Card Eligibility

Last updated September 22nd, 2020 at 11:31 am, Published September 1st, 2015 at 11:31 am