I sat on a panel today about business rules and business process and whether they should be separate or combined.
I already have a couple of posts on this topic - here and here - so regular readers (both of them) will know where I stand on this. The panel was somewhat predictable in terms of where vendors stood but there were a couple of interesting items:
There was some good discussion of whether you should always start with rules, always start with processes or always start with both. The consensus seemed to be that you should usually start with both (at least thinking about both the rules and the processes in which they are executed) but that this was not a hard and fast rule (think about a legacy modernization problem where the process implementation is not being changed, just a decision) and that it did not imply that both pieces would repay automation equally.
Everyone agreed it was important to demonstrate success early, regardless or which technology choices you made, and that it was important to think about the enterprise vision even while remaining focused on the first project.
Personally I think we will see both more and tighter partnerships between BPM and BRM vendors and more blurring of the line between them with business rules vendors increasingly supporting some process flow and state management and BPM vendors embedding better rules products.
Lastly I wanted to address a question Barb highlighted before the event but that we did not have time to consider. Her class had raised the following question:
Is there a very gray line between process management and business rules?
Explanation: you can create a model that prescribes that you or an automated system carry out task 1 then carry out task 2 and based on some criteria moves to task 3 or 4.
For ex: task 1 is to determine if a person is a desirable renter based on their financial history. Task 2 is to determine if the person has brought cars back damaged or late or to the wrong destination. Task 3 is to determine if the person is a risky driver based on driving record. These can be modeled and managed as THREE tasks within a bigger process (each task with its own rules) or as one TASK within a process (with a super set of all of the rules), or other combinations. Is this a gray line or can you make it clearer for us?
I think this example is easy to resolve - there should be one decision task as there is only one business decision - should I offer a car and at what price? This decision might be made available as a service to third parties who resell my car rentals or on my website to let customers get the right price for themselves. It has "business atomicity", a term I just made up. In addition I might add or remove decision steps (perhaps a state makes it illegal to use financial history or I decide to add profitability of the selected car to the decision) without changing the process in any way. If you focus on meaningful business decisions then this is usually pretty clear.
P.S. Fair Isaac has partnerships with most of the leading BPM vendors including, but not limited to, webMethods (an OEM), Oracle, FileNet, Savvion, Fujitsu, Metastorm, DST and Lombardi.
P.P.S I promised to post on available white papers and how to get them. There are several, listed below, that you can get by emailing edm@fairisaac.com
- "Business Case for Blaze Advisor" and an IDC ROI Study for overall business value
- "How Blaze Advisor Works", "Blaze Advisor for .NET" and "Blaze Advisor for Java" white papers with more "how to" information
- Industry specific white papers for Insurance, Telco, Healthcare (Payer and Provider), Mortgage
- An SOA and rules and a BPM and rules one showing how rules fits in these approaches
