Posted on

Business Rules Process Management

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.

Such questions occur every time a group or enterprise considers adopting rules technology for more than a specific application. They are looking for guidelines, blueprints, or patterns that will help them disseminate understanding about when and how to use rules. They have adopted a BPM vendor which will be integrated with their selected rule vendor, each as enterprise standards, so they are particularly interested in the integration requirements between the two.

Two high level understandings are critical for success in furthering adoption of rules technology.

  1. abstract activities for which rules technology well-suited and
  2. when and why rules technology is better than familiar alternatives

Continue reading “Business Rules Process Management”

Posted on

Process vs. Decisions

In comments to a recent post concerning the acquisition of Haley Systems by Ruleburst, James Taylor suggested that a “decision-centric” perspective is necessary for business rules to become mainstream.  In subsequent correspondence, I questioned whether fixating on decisions would achieve his objectives for enterprise decision management.   EDM hopes to integrate business intelligence (e.g., predictive analytics) with point decision making so as to improve decision making over time.  This is a natural step beyond the typical point decision making application of business rules, such as in a stateless web service that returns a simple decision, such as a score, price or simple yes/no.  But it is a narrow perspective on the broader confusion between business rules and business process that has been holding back the mainstream.

For years, smart people have been searching for a razor to determine what logic they should “code” in process versus as rules (e.g., using a BRMS versus their BPM platform).  At first glance, the decision-centric approach seems to have the answer.  Simply put a decision node in your business process diagram and let the BPM tool orchestrate the decision implemented as a stateless web service! 

Unfortunately, this alluring answer is all too often inadequate or impractical.  The business rule vendor has effectively transfered responsibility for managing state (i.e., information collection and provisioning) into the business process diagram and orchestration tools – or code.  The result is implementation complexity, limited user communities, cost overruns and failures.  That will certainly hold back mainstreaming a bit!

A better answer is coming.  Complex event processing anticipates that business processes and decision making can be stateful, as Paul Vincent explains briefly but well here.  When CEP is supported by knowledge capture, management and automation tools such as the better BRMSystems provide, the lines between process specification and decision specification will further blur beyond the adequacy of the decision-centric advisory.   Expect this to happen in 2008.