In my previous post I said

"Implement these as decision services that use rules to make a decision but which do not have side effects - that don't change the data. This will make them easier to implement and easier to reuse while focusing on those areas where rules makes the most difference."

In response to this I got an interesting question:

Does this make sense with BRFplus?  One of the big features of BRFplus is connecting actions directly to the outcome of rules.  IE: Data updates in forms, emails, workflow etc. It sounds like from your above comment though that actions such as this should be implemented independent of the rules though.

When I saw BRFplus presented at TechEd, and spoke with Carsten Ziegler this was one of the things I had to think about. While I understand the desire to put the ability to take action into BRFplus rules - this is common to all business rules management systems, by the way - I still don't like it.

The problem, as I say above, is that this means the Decision Service cannot be called unless you are willing to tolerate the side effets of doing so. If, for instance, a Decision Service implemented in BRFplus to determine the eligibility of a customer for a particular product updates the customer profile then you can only check the eligibility when you are processing an application - you cannot expose the functionality as part of a customer inquiry environment or to help a call center representative answer questions. In general therefore I stick to my principle - Don't use BRFplus or any business rules management system to take actions when you are using it to make decisions.

Does this mean that there is no value to this ability of BRFplus? No - the ability to take actions can be used to update intermediate results, to log decision making for future analysis, to record how often and in what context the question is being asked and so on. It just should not be used to do things that matter to the business - it should not change the state of the business when used to implement a decision service.

Now you could use BRFplus to implement the logic that takes actions if you wanted to - you could use BRFplus as a declarative programming language. And this would be fine as long as you separated out and called the decision itself as a separate function. This separation of concerns - decision making separate from other aspects of the application - is what is critical.

Business rules and BRFplus can be used for many things. When you use them to implement Decision Services, don't use the action functionality to change the state of the business because you will regret it.