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.

Why? Consider that most decisions made in a business are consistent and on-going applications of Rules — does the Customer qualify for a Discount on this Order? —, and are made many, many times a day. In these situations, the person in the above case is looking up the rules in a manual or (worse) applying them from memory, which we all know can be faulty in even the best people. This is where using BRM has its biggest impact, eliciting those common rules out of the manuals and memories, and getting them into a BRMS; Business Processes will flow uninterrupted until a new situation arises. That is when a person is really needed, and once the situation is understood, it can be defined as a new rule and added to the BRMS.

So back to the beginning – Business Processes can now be fluid, not frozen. Change is expected, even welcomed because fast response to changing business environments can make the difference between success or failure, profit or loss, etc etc.  Tell me honestly, would your company love to have systems that supported change? Comments welcome….

[1] Available at ). This is a thorough standard, and is made accessible through the efforts of thought leaders like Ron Ross and his RuleSpeak® business rule notation that has been in use for over 10 years.


Would you recommend this article?


Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.

Jim Love, Chief Content Officer, IT World Canada

Featured Download

IT World Canada in your inbox

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Latest Blogs

Senior Contributor Spotlight