This great white paper, Introducing Microsoft Windows Workflow Foundation: An Early Look posted to his blog by David Chappell, is a nice, succinct overview of this new technology platform from Microsoft. This paper does a great job of differentiating between the kinds of business rules that belong in a process management or workflow tool and which ones deserve a rules management approach - I discuss the difference between a rules engine and a rules management system in my business rules FAQ in this item.
So what does this white paper say about business rules. Well it uses an insurance underwriting example, a classic use of business rules as I have discussed before. In this example rules controlling routing and simple conditions and threshold checks are managed directly and conditions can be managed dynamically so that they can be changed in an operational system. Slightly more complex groups of activities dependent on conditions can also be defined and executed.
However, it goes on to say
For evaluating complex sets of business rules, building and maintaining an intricate group of conditions can be problematic. In the insurance application process described earlier, for example, each applicant must be checked against the potentially complex set of rules that make up the firm's underwriting policies.
While expressing these rules using the Windows Workflow Foundation options described so far is certainly possible, it's not always the best choice. Instead, the right approach for handling complex groups of rules can sometimes be to use a rules engine.
Now this is great for anyone, like me, who thinks that business rules are an important technology for developing the next generation of business systems - Microsoft agrees! Before we all get too excited, however, David goes on:
To make this possible, Windows Workflow Foundation provides a rules engine that can be accessed through the Policy activity. Using this activity, a developer can define a group of rules called a rule set. Each rule has the form IF <condition> THEN <action> ELSE <action>. For example, an insurance company might create a Policy activity with a rule set containing all of its underwriting qualifications. Drivers under 21 might be ranked as high-risk, for example, unless they have good grades in school, while married drivers might be given a lower risk ranking. A workflow that needs to determine whether a particular applicant conformed to these rules could then invoke this Policy activity. The Windows Workflow Foundation rules engine would determine which rules in this rule set are true, and then execute those rules. This execution might change the state of the workflow in such a way that other rules in the rule set have now become true. To handle this, the rules engine examines and, if necessary, executes any affected rules in the rule set again, a technique known as forward chaining. This process continues until either no new rules become true or a predefined limit is reached.
Well now this looks, at first blush, to be Microsoft trying to take over the business rules market by embedding a business rules engine. However, a few simple questions give the lie to this:
- What happens if you want to re-use rules in a non-Microsoft or even a non-WWF platform?
- How do you give business users control over these rules? Can you do so in a controlled way? Would they have to learn to use VisualStudio?
- Is IF THEN ELSE a reasonable construct for complex rules or do you need things like "IF AT LEAST ONE OF" to keep the rules from becoming code?
- What about the backward chaining you sometimes need in business systems?
- What about management of thousands of rules - versioning, control, authentication etc etc.
- What about performance when you have hundreds and thousands of rules, few of which are executed for each transaction?
- Lastly what happens when you need to layer corporate rules, federal rules, state rules and segment-specific rules into a single decision - as any real insurer would do in the example given?
For all these reasons I think Microsoft is going to still promote the use of partners with full-featured business rule management solutions like Blaze Advisor. There's clearly no money in providing a .NET rules engine, given one will be in WWF, but a rich, multi-platform BRMS still seems to have a role to play and, for processes like underwriting, origination, fraud and many others, a key role. David even goes on to make this clear:
Using the Policy activity requires writing some code. There's currently no default graphical representation for this activity in the Workflow Designer toolbox, for example, and so a developer must explicitly create a specific Policy activity. A developer must also write code to define the rules in a rule set.
So read this paper. Understand why business rules are key to workflow and BPM and then decide if your processes involve the automation of complex, or even somewhat complex, business decisions. If they do you are going to need WWF and a good .NET rules management system with cross-platform capabilities. If not, WWF is probably all you need.
