Open standards-based BPM solutions, such as many of those based on BPEL, enable all three approaches: code-based, model-driven, and service-oriented. They allow you to use your choice of rules engine if you decide to go for the model-driven or the service-oriented approach. You can also leverage existing rules/rules repositories/rules engines for use in business processes. If you need to use facts external to the BPM solution, then you generally don't have to worry about synchronizing rules metadata if you take the service-oriented approach. However, if you don't, then you can use the integrated rules capabilities and benefit from the integrated design time for rules and processes.

Case Study
In the previous section we discussed various approaches for rules enabling your business processes. Some of the key criteria to keep in mind when deciding which approach to use are the design experience, flexibility, reuse, and ease of maintenance of rules. Let's illustrate the trade-offs of the various approaches using a case study.

Consider the example of a loan flow process that is deployed at a loan agency. The loan agency accepts a request from a client, performs a credit check with an external service, and then does an automatic approval or routes it to a manager for review. Depending on the outcome, the loan flow process notifies the customer. The scenario consists of the following participants: the customer, the loan agency's approval process, and the credit rating service. Various facts that may be used to make loan approval decisions include the loan amount, the customer's annual income, the customer's credit rating, the status at this agency (returning customer or new customer), and the agency's outstanding loans (after all, if the agency has approved many high risk loans recently, it's probably a good idea to take this into account in approving future loans). Now let's consider various decision points in the process:

1.  The first step is to get the credit rating from the credit rating service. The credit rating service may return a rating if the customer has a past history or it may return a NULL value if the customer is not known. If the loan agency does not want to ever deal with customers without a credit rating, it may have a rule such as: (see Insert 1)

This rule is very simple and not likely to be changed after process deployment. Hence, the fastest way to implement this would be by using the code-based approach with XPath or other expressions. Now let's consider a slightly more complex rule.

2.  The loan agency may then use the customer's social security number (SSN), prior credit history, annual income, and outstanding loans to determine the customer credit rating, the risk, and maximum amount to lend a specific customer (see Insert 2).

In the above rule, there are various inputs that are provided by the business analysts; for example, the minimum annual income requirements and credit score. The analysts would like the ability to change these without necessarily redeploying the process. In this case, the model-driven or service-oriented approach would offer the most flexibility, since the rules would be separate from the process logic and can be modified independently. The code-based approach would not work since it would not be maintainable in the long run, and as the rules get more complex, defining them through just simple expressions would be very difficult. Now let's examine a slightly more complex scenario.

3.  Based on the current business environment and other company policies, the loan agency may interpret the results differently and further apply rules to determine if the customer should be granted the loan, what interest rate should be given, and the appropriate approval policies. Note that in case 2 above, all the information needed to apply the rules was available from the business process itself. However, in some cases, rules may require additional facts that are asserted by other applications. Say you want to know if the "outstanding loans this month" are greater than US$3M or if the customer already has some other products - say, home equity loan or insurance products - from this company. These facts are provided to the rules engine by other applications, but are used by the rules engine in the decision to approve or reject a loan. For example: (see Inserts 3 & 4)

In this case, the decision service is used to evaluate rules based on both static data; that is, the loan application, as well as data such as "outstanding loans to high risk customers" from the BAM system. Similarly, rules are also used for dispatching the loan application for manual processing for high-risk customers. In this scenario, the code-based approach will obviously not work because it is not flexible enough and would be very difficult to maintain in the long run. The model-driven approach also is not very effective, since the rule engine requires facts/data from external systems such as a BAM solution or customer database. You could make the loan business process retrieve all this data and pass it to the rules engine; however, this would make the process very complex and would require changes every time the business analyst decided to use additional criteria for loan approval. The service-oriented approach works best in this case. You could have a central rules repository with a decision service that is used by all clients of the rules engine. The BPM solution, as well as other applications like BAM, would assert different facts to this service that executes the appropriate rule sets to make decisions.

This process and the various decision points are also illustrated in the architecture diagram in figure 1. As you can see, the first rule is implemented using inline process logic, and the rules service is used for cases 2 and 3 discussed above.

We suggest the following rules of thumb when deciding how to leverage rules logic in business processes:

• The code-based approach should be used for simple expressions that are not likely to need modification after the process is deployed. Examples of where the code-based approach works well are validation checks, such as "If the customer does not have a credit rating, reject the loan," or certain constraint checks, such as "All loan applications from a new customer must be accompanied by an employment verification letter." If business analysts are involved in capturing the rules, chances are that the rules are likely to change, and so you should go for the model-driven or service-oriented approach.
• Use the model-driven approach when the rules are likely to need changing or when you need to separate rules from the process logic. This allows you to separate duties - processes being developed by the process implementers - and the business rules being captured and managed by business analysts. Use this approach for workflow rules for load balancing of tasks ("A specific loan agent can have a maximum of 10 open tasks assigned at any point") or a policy-based task assignment ("Orders from Premier customers are handled by reps in Dept B, but other orders are routed to Dept A"). As long as the rules do not require external facts, the model-driven approach works well for a wide range of uses. If they do however, you need to consider the service-oriented approach!
• The service-oriented approach works best when you need to use facts from multiple business processes or applications in your decisions, or when you don't want to use the embedded rules engine in your BPM solution, e.g., because you already have a rules engine that is in use for other applications. It may be a little more difficult to set up, but offers the most flexibility and having a common rules repository enables rules reuse across processes and applications. It requires you to plug your rules engine into your BPM solution. BPEL-based BPM solutions tend to make this easier compared to the monolithic BPM suites. Examples of when the service-oriented approach works well include when you have a common rules repository that is used to handle vacation, delegation, and escalation rules. This would be used in HR-related applications as well as other financial applications for any approval workflow. Another example is when you have rules to decide the APR for loans not just based on the customer details available from the business process, but also real-time aggregate information/facts fed to the rules engine from another component, e.g., BAM solution.