Both Data and Processes need Rules

Just as data needed DBMS, and process needed BPMS, business rules need Business Rules Management: BRM, and the systems to support it, BRMS. This is not code-like procedure; this is human-readable rules that can also be implemented as declarative statements, such as:

·        A Customer can place an Order, only if they are 18 years or older.

·        A Customer can place an Order on credit, only if their Credit Rating is ‘Good’ or ‘Excellent’.

·        The insurance coverage for a 10 year Term Life Insurance Policy must be $50,000- or higher.

·        Premiums paid by direct debit must have a monthly payment frequency.

·        A Credit Application greater than $1,000,000- must be approved by the Manager of Underwriting.

·        An Order is fulfilled, only if the Ordered Items are in stock.

As declarative statements, business rules need to be automated irrespective of any procedural order. All rules are applicable to the business at any time, and not according to any order specified in a coded program.

The structure of the rule statements must meet the two primary needs: readability and execution. The means of doing so, fortunately, have already been developed and standardized for us through the OMG, and its “Semantics of Business Vocabulary and Business Rules (SBVR), v1.0” (January 2008)[1]; the above examples meet the requirements of this standard, and would be executable by any BRMS that supports the standard.

So, from even this list of examples, it would appear that Rules are everywhere in a business; this is in fact a testament to the value of managing business rules effectively. For the most part, though, they can be categorized in relation to how they impact the other two main components of information systems, process and data.

For your data needs, Business Rules help with conditional relationships and data values. Consider the earlier example of when an Order qualifies for a discount. When an information system is used to create a new Order, the database schema would have informed the programmer that certain data attributes are needed to create a complete and Order —like Item and Discount — and what values those data attributes are allowed to be for the Order to be considered valid for the business. However, a database schema cannot document and enforce rules about values of a field that are dependent on the values of other fields; those are Rules. Further, if an Order needs to have an association with a Credit Authorization when payment is by Credit Card, that is a conditional data relationship that cannot be described in a database schema; it is a Rule.

For your processes, Business Rules are critical for the decisions made in a Process. Basic implementations of a BPMS will automate the flow of activities, but will stop executing and exit to a user prompt when it reaches a Decision Point, the diamond in the diagram. A person needs to respond to the prompt and indicate which path the process should follow next. This is better than not having BPMS, but it is not yet an ideal implementation.