How do you determine when it is appropriate to use rules or procedural code in your BPM based solution? Recently Paul Haley, founder and chairman of haley.com, was asked to help with this question:
Some strategy folks in an enterprise architecture group recently asked for help making rules more relevant to their organization. Their concerns ranged from when to embed rules in their middle tier versus encapsulate them within services to identifying ideal use cases and reference implementations. They were specifically interested in coupling rules with BPM and BI.
Paul states that traditionally IT thinking is biased towards procedural coding, which leads to overusing BPM. He identified two fundamental items that need to be understood in order to provide a more balanced view:
- abstract activities for which rules technology well-suited and
- when and why rules technology is better than familiar alternatives
BPM products today uniformly include some mechanism to incorporate rules, however Paul argues that current implementations are holding back the true capabilities of the technology:
All too frequently, users unwittingly sacrifice the time to market, flexibility, agility, and accessibility advantages of externalizing logic from process.
The bottom line is that BPM is not advancing the broader use of business rules. Rather, BPM vendors are merely responding to those who understand that they have decisions to make within their processes and that rules are more appropriate for managing those decisions than code or flowcharts.
So how do you start taking advantage of rule technology beyond the ordinary, BPM prescribed, use cases? Paul provides some "blueprints for rules":
There are obvious heuristics for when rules are probably efficacious. Some of them are task-centric, such as in decision making or compliance. For example:
- if there are many criteria (or reasons) for qualification (or disqualification)
- if there are many exceptions indicating problems (e.g., the unexpected or a lack of compliance)
In the first case, the decisions are among two mutually exclusive alternatives. This is the easiest case for business rules. This case is further improved:
- As the number of criteria increases
- As the set of criteria becomes more dynamic
- As the criteria become more complex
One area where rules technology is typically appropriate is identifying exceptions and enforcing compliance. Paul writes:
Exceptions are quite common in compliance applications. Most regulations are expressed as requirements. That is, they tend to say what must be not what to do. Any such requirements must either be transformed into deductive rules or operators that take action. Typically such transformations involve replacing “must”, “may”, “shall” or “will” and introducing “if” or “unless”. Unfortunately, transforming a requirement often results in more than one rule.
Analytic transformation of requirements into business rules that are more than one-to-one or that affect multiple classes, tasks or processes is a clear indication for using rules technology.
Note that policies may also often be expressed as requirements but they are also frequently expressed as rules. So in addition to business requirements and regulations, policies may also be enforced using exceptions or require transformation.
Maintaining exception logic as rules allows exceptions to be recognized and compliance to be enforced throughout a business process without needing to express how (or that) requirements, regulations, or policies are (or need to be) checked (redundantly and distinctly). That is, factoring out requirements (including most regulations and some policies) from a flowchart increases productivity and agility dramatically.
Similarly, rules can be a useful component in scoring algorithms:
... as subject matter experts realize heuristics or as correlations with risk, profitability or other key performance indicators are discovered, the use of rules facilitates a scalable scoring architecture.
Paul then discusses some indicators for when rules technology is not appropriate, including "don’t consider rules if the process is trivial":
Do not use rules if both of the following hold true:
- the flowchart has a handful of branch points
- the logic is fully understood and will not change
In terms of encapsulating rules as a service, Paul offers this advice:
One common discussion concerns encapsulating business logic (i.e., rules) within objects or services. Services make sense for decisions and compliance that are orchestrated by the business process.
And continues:
If a requirement, regulation, policy or rule spans many classes in the model and many tasks within the process, externalized rules are strongly indicated.
Concluding the article, Paul is critical of the current lack of integration between BPM and BRM products:
The reality of today’s market is that business rule capabilities captive to BPM vendors do not have the accessibility, manageability, functionality and performance of those from the dedicated rule vendors mentioned earlier. And the partnerships between top-tier BPM vendors and rule vendors are not integrated deeply enough.
...
The limitations of integration capabilities certainly impact when to use rules in addition to a BPM platform. The built-in capabilities of some vendors may be the most viable alternative even if their capabilities are weak relative to pure-play rules vendors. To do so exacerbates vendor lock-in concerns, however.
Paul does call out JBoss Drools, as previously covered by InfoQ, as potentially having the best integration currently available for pushing the rules technology envelope from within a BPM solution.
