Business rules, as the name stands are about business, and particularly and most likely operations of the business.

Business rules are criteria used in business operations to

  • guide behavior,
  • shape judgments, and
  • aid decision-making

As we see in the above definition, they are very different from system rules. Having said that, this does not make system rules less important, but what is important here is to make sure we can differentiate between them.

System rules are derived from business rules, technology best practices, and constraints, as well as requirements for a specific system and process.

System rules are defined to

  • ensure systems, applications, and processes are aligned with business rules
  • provide customers and users with a better experience and a more compelling journey
  • make products and services more reliable and ensures the quality of parties engagements

Let's have a look at an example;

  1. a shipping invoice should have a valid email address.
  2. if a customer provides an invalid address, show “please enter valid email” to them.

So, which one is a business rule? yes, of course, the answer is number one. The second sentence defines an acceptable system behavior, derived from the first sentence – the business rule.

Documentation vs Modeling Business Rules

As mentioned above, business and system rules are both important, therefore, they should be identified and be clearly defined.

However, the definition of the can be either by documenting them or modeling them.

There are two disadvantages to documenting rules:

  • Documenting rules, like any other documentation will be stale at some point, and the way operation works will diverge from the documentation eventually. It's very expensive and impractical to make sure the documentations are always up to date.
  • Digital business requires automating rules, and automating them as part of any automation capacity, i.e. system or application development, process automation, etc. will require handing them over to IT professionals for implementation. Which is an extremely expensive exercise.

Rules modeling, on the other hand, addresses the two above challenges. Eliminates the “handing over” process for automation and at the same time allows models to become live specification and definition of rules, so there will not be any stale, out-dated documents.

The challenge though is the fact that inherently there are too many rules in organizations. When all the business and systems rules related to different operations (i.e. sales, marketing, partner engagement, customer onboarding. etc.) and all possible systems and processes are modeled, they will become insanely hard to track and understand individual rules and how they collaborate to each to provide an answer to a specific situation. This is called the big bucket of rules problem.

The alternative to this approach (rules approach) is to look at the questions that business needs the answer for and then group the rules based on the situations. Rather than starting with rules, start with the business questions (i.e. operational business decisions). And then find out the relation between the decisions and how they impact each other. And then focus on the rules of those particular decisions.

All of a sudden, this Decision-Centric Approach® opens tons of new possibilities and eliminates all the risks associated with the rule approach.

Business Rules Modeling Techniques

There are many different ways of rules modeling, but we explain the three different ways here:

Decision Table

The Decision Table allows modeling of system and business rules in a tabular form. The benefit of this technique is it is very familiar with businesspeople and domain experts. This is a declarative approach to model them.

Rules in Decision table

Natural Language

The Natural Language allows modeling of system and business rules using business glossaries and terminologies. The benefit of this method is it will enable people to establish ubiquitous language and use it to define the rules in their own language and terminologies. This is a declarative approach to model them.

Rules modeled in natural language

Tree and Sub-Tree

The Tree and Sub-Tree allows modeling of system and business rules in a tree structure. The benefit of this approach is that its very familiar with IT professionals as its a procedural approach to defining the rules.

And you might ask, why not use for example process modeling techniques to model system or business rules? You definitely can, and it is appropriate in some cases. What you need to look at are:

  1. Frequency of changes: How often the rules need to change and require updates? Are there any dependencies on any external force? law, regulation, etc that makes it out of your control.
  2. Numbers of rules: How many rules are needed to be modeled? 10, 30, or thousands?

The process model will introduce massive complexity when it faces a large number of rules or frequent changes.

Conclusion

You might use any techniques of rules modeling in your processes, applications and operational decisions but

When any types of rules i.e. business rules or system rules are impacted with frequent changes from

  • market volatility
  • policies and regulations
  • data and information

rules modeling techniques will help you tons in reducing time to market, decreasing cost of applying changes as well as ensuring being compliant with legislations and laws.

 

Last updated February 10th, 2023 at 10:00 am, Published October 1st, 2020 at 10:00 am