Copyright © 2009 James Taylor. Visit the original article at Interesing debate on business process and decisions.Syndicated from ebizQ
I have posted a couple of times recently on the interaction of decisions and processes – Another way decision management and process interact, More on keeping decisions and processes separate and Here’s how decision management simplifies process […]
Copyright © 2009 James Taylor. Visit the original article at Interesing debate on business process and decisions.
Syndicated from ebizQ
I have posted a couple of times recently on the interaction of decisions and processes – Another way decision management and process interact, More on keeping decisions and processes separate and Here’s how decision management simplifies process management. This last one prompted Stephen Zisk (of Pega) and Dan Selman (of ILOG) to respond.
The good news is that we are all in agreement on the silliness of using BPMN branches to manage decisions and on the value of a separation of concerns between process and decision. Then it gets interesting:
First the issue of changes to data. Stephen makes the point that
“if someone needs to add a piece of data to the calculation…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.”
and contrasts this with a merged process/rule environment such as Pega’s. Dan takes issue with this arguing that
“Services have well defined interfaces…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”
Me, I think that Stephen has a point but that it does not obviate the value of a clear division. After all, the discount calculation might be made in several places and so any change to it has a greater impact than just this one process. If I tie it into this process then I don’t necessarily make it easier to change if there are other processes using it. I can and should refactor the decision service so that it works with or without the new data element (if I can) and then change each process as and when it makes sense to pass the new data. So, yes it takes three changes but I am not sure that (in the general case) a merged process/rule environment makes a difference to that.
Stephen then goes on to address the second point:
“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?…If the sources have different costs and response times, having the decision rule pick which sources it needs to best make the decision 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.”
Dan does not see what he’s getting at here but I think I do. I agree that decision services need to be able to reach out and collect additional data required to make a decision and that limited backward chaining support is ideal for this. I am not fond of decision services that only work with the data passed in for this reason. And I can see how a process/rule engine has more options for this kind of data access. I am not sure it changes the basic dynamic, however, and I still believe a formal separation of the decision from the process (even if you use the same platform for both) is the way to go.
There are lots of examples where processes can be made simpler and more effective using a rules-based process definition (something at which Pega excels) but I don’t think this means that decision services are not a good idea even so.
Love the debate and, like Dan, I agree with Neeli that we need better visualization and refactoring tools between processes and rules.