The previous article in this series highlighted the value of externalizing business rules processing in business process management (BPM) applications — separating decision-making rules from the business process specification. The article indicated that this externalization represents one of a number of significant innovative steps toward delivering process-aware applications in a service-oriented-architecture. This article will examine what is still missing from current business rules engine (BRE)-enabled BPM applications, what future promise is possible from an evolving capability called business rules modeling, a standards initiative underway that will improve the interplay between business process analysis (BPA), BRE and BPM, and the promise of deploying BRE-enabled applications as web services.
As discussed in Part I, current BRE-enabled applications provide the IT buyer advantages such as lowered business transaction costs, elimination of errors from implementing complex decisions, simplified process specifications, lower development costs, faster deployment times, and simplified ongoing maintenance. However, despite the fact that BRE suppliers have attempted to put some control into the hands of the business analyst, programming modifications are still required to address most business requirements. This is true both for initial development efforts and many on-going rule changes. In current BRE-enabled applications, programmers have exported pieces of the logic to business people in the form of parameters or templates, which provide “safe” ways to change the rules using natural language or tabular interfaces. These “rule maintenance applications” must be set up by programmers and as soon as a business user wants to change the logic beyond what has been “templatized”, he/she must wait for a programming cycle to upgrade the rule maintenance application….business as usual.
New BRE product enhancements promise to further lower the cost of maintenance and reduce deployment times, and increase the percentage of errors eliminated by providing complete business control of the logic rather than only pieces of the logic as is done today. This approach is possible when users are provided a rules specification and modeling environment designed for a business analyst as opposed to a rules modeling environment designed for a rules-trained IT professional. These enhanced products are available today from a very small subset of BRE suppliers. The acid test for their value is that 1) new rules are specified without requiring IT thus reducing the development bottleneck in IT and 2) the newly deployed rules do not introduce rule conflict — broken applications that IT must then repair.
BRE products with enhanced business rules modeling provide the following capabilities: a) a business-friendly way to model all of the logic, not just a subset; b) a comprehensive way to identify the logical errors in the rules such that business people can understand and address the errors; c) a way to test the rules without requiring programmers to set up a test framework; and d) a way to safely and securely redeploy changes without programmer involvement. Similar to process modeling or data modeling, business rules modeling involves the specification and analysis of a specific information asset, in this case, rules.
Business rules modeling must exist as a stand-alone environment, with a design tool that is targeted at the business analyst. The design tool must capture, model, validate/analyze rules for logical correctness, and verify business rules by testing against sample data. Rules can come from numerous sources — from mining legacy applications, interviewing business staff and management, re-engineering initiatives, and best practices improvement campaigns. Whatever the source, the rules must be captured in an abstract form so they can be deployed in many environments (e.g. .NET, Java, web services). This neutral form enables companies to delay making the final technology decision until they know what kind of budget constraints will exist.
Business rules modeling enables companies to more effectively deal with loss of knowledge, to better organize business operations, document how things work, resolve conflicts, improve strategic planning, and develop best practices. However, the promise of business rules modeling doesn’t stop there.
Supported by visionary process modeling vendors, an effort is underway at the Business Process Management Initiative (BPMI.org) to create a more integrated modeling approach that leverages the capabilities of BPA, BRE, and BPM products as well as popular specifications Business Process Management Language (BPML), Business Process Execution Language (BPEL), Business Process Modeling Notation (BPMN) and Web Services.
BPMN does not describe rules models, only process models. Discrete rule models appear as discrete “tasks” in a BPMN model, and the payload — the data sent to and received from the task — is represented as a Data Object associated with the task. The use case for the improved interplay between BPA, BRE and BPM is as follows:
- Model a BPMN process in a BPA tool, noting rule tasks, and associated data payloads.
- Double-click a rule task to auto-launch an advanced BRE tool i.e. one that supports business rules modeling as defined in this article, to model the rules. The rules are pre-populated with the data payload.
- From the BPA tool, generate a BPEL or a BPML model.
- From the advanced BRE tool, generate web services.
- In the BPM product’s BPEL or BPML build tool, perform the web services binding for each task, including the rule tasks specified in the advanced BRE tool.
- Execute your decision-automated process!
Developing and deploying BRE-enabled, BPM applications as web services represents a breakthrough advantage when rules are used to automate discrete decision points. The combination of web services with business rules modeling, as well as the improved interplay among BPA, BRE and BPM all promise to advance the agility of business operations by enabling mission-critical operations to be improved more rapidly across a company’s value chain. The result is better business execution.
