We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

James Taylor's Decision Management

James Taylor

More on keeping decisions and processes separate

Vote 0 Votes

Neeli Basanth posted this in response to my post Here's how decision management simplifies process management and asked an interesting question:

No doubt the diagram on the right looks much simpler and purely shows the flow. Although it no longer tells the viewer on how the decisions were made.

And this is, at some level, true. In response I would make a couple of points:

  • Crazy-EPC-Branchings.pngWhile the simple example shows the viewer how the decision is made this "benefit" wears off quickly as the number of branches multiplies. Take a look at this example from my friends at IDS Scheer and the fact that the decision logic is displayed in the diagram no longer seems like a benefit.
  • Even in simpler examples, the business person who defines the decision rules may not be the person who defines the process steps - if risk assessment is part of the decision it could be handled by a risk group while the process itself was handled by a customer service group. In these circumstances a degree of opacity in the decision-making logic may actually help by separating the concerns of the two groups.
  • The pace of change might be quite different between the process and the decision. For example a discount calculation decision might change all the time as different groups are targeted and as competitors respond. None of this changes the order to cash process itself so separating the two isolates change more completely.
  • In a long running process it may be more effective not to commit to the decision making approach when the process is instantiated, instead invoking (say) a rules engine to make the decision when the process reaches the relevant point. Separating the decision logic out makes this easier.
  • Branches are not a great way to display logic. If there were even 10 rules that contributed to the risk it might be easier to understand them if they were displayed as a ruleset in a rules environment rather than as branches. Even with the extra look-up step the developer of the process might reach understanding quicker.
  • Separating the decision logic allows it to be reused. Perhaps this is not the only process that needs to know how high risk an applicant someone is. Embedding the logic for the decision in the process might make the process easier to read but it embeds the logic making reuse hard if not impossible.
At the end of the day the decision logic is not the same as process flow or even process logic and I believe it should be managed separately.


Thanks for the detailed explanation.

Fully agree with you on the need for seperation and externalization of decision rules from process. But I do feel that the process owner and process modeler should have a view into these.

My opinion could be countered that a process owner does not have visibility into the processing of a web service that is being orchestrated in the process. But business rules are not comparable to a web service.

A possible option, left to vendors, could be ability to launch the view of the rules from the process both while modeling and run time.

Thanks again


I agree with your original premise that using simple decision branches in a BPMN diagram is a lousy way to implement a decision. Further, I agree with your "separation of concerns" ideas - this is the core of why using a real decision process (not just diagrams or excel-like expressions and variables) is so important for BPM.

But a completely separate decision service based on a rules engine is not the only solution, and can make things worse by introducing an interface/API and making change or decisions *more* difficult. Two examples:
1.) In your discount calculation example, what if someone needs to add a piece of data to the calculation? Now you need to change three things to handle the new data: the interface to the decision service, the process activity to pass in the data, and the decision rule itself. In a merged rules/process environment, as long as the data is already part of the work object, you just change the rule.
2.) In your "long-running process" example, what if you need to make a decision based on things that may happen at different stages or even external to the case? Think of a risk process that might involve getting information from several internal and external sources to contribute to a decision rule. If the sources have different costs and response times (e.g. external identity verification, costly query, etc), having the decision rule pick which sources it needs to best make the decision (through backward chaining) would save time and money in most cases. But if you have a separate decision engine, you either have to do the calls for external data inside the decision engine or you have to introduce convoluted processes inside the BPM to support the backward chaining. Resolving the rule in the same "space" as the process engine fixes the problem.

I could provide myriad other examples, but these are meant to just illustrate that you need a separation of concerns (a real decision mechanism with robust decision types), but you may want to implement the decision in the same "space" as the process itself to take advantage of the rules engine and gain flexibility.


Regarding point 1:

Services have well defined (architected) interfaces, and services that implement decisions are no different. If you share amorphous state between a process and a set of rules then you explicitly tie your decision service to the process. This is an anti-pattern IMO as it makes the decision service hard to test, hard to reuse and often difficult for the business user to understand (due to the loose coupling). It also greatly complicates governance as it becomes difficult to understand/refactor the decision services or processes as they undergo change.

Regarding point 2:
I don't understand your second point I am afraid. If you are trying to optimize the access to costly resources (goal-driven inference) you are going to need an engine that can perform that task -- and I don't see how moving the rule into the process definition will help. I suspect it may make the job harder as I have not see backward-chaining or optimization in a process definition language.

I agree with Neeli that we need better visualization and refactoring tools between processes and rules, but to conflate the two is a mistake IMO -- certainly when you are dealing with business domains where you may encounter 1K+ rules that evolve daily, weekly or monthly. When you edit a discount or scoring rule you really HAVEN'T changed your business process!

Daniel Selman


Good post. But, if we tie the decision service to the process, then the chances of making it a service becomes less. Probably on a case to case basis, but having decision service separate makes it more reusable.

James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links



 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives