Levels of Perspective - Perspective 4 - Business Rules (Part 1)

Updated: Jul 23, 2020

Welcome back!!!

We have successfully wrapped up Perspective 3 around process and now it’s time to tackle the topic of business rules. As you look through these different perspectives and start to uncover how the organization in which you work operates, you have come across business rules along the way. Whether you knew it or not, you have probably identified some as you discuss the customer experience, and as you mapped/modeled processes. We have definitely talked about why it is not a good practice to process map/model business rules. It will add some complexity to the process map/model that will make it very hard for the audience consuming the document to follow. However, business rules are very important to capture and can tell you a lot about your operations.

So, what is this thing called a business rule? In its simplest definition it’s a rule that defines, or constrains some part of the business operations. The outcome of the rule should either be true or false. Business rules are extremely important to capture, and understand in your business as many of these rules can help organizations stay compliant with policies or regulations that may govern their organization.

Let’s go a little deeper and look at how to identify, write, and store business rules.

1. How to identify business rules

As stated above, a business rule is a rule that defines, or constrains, some part of the business operations. Business rules are typically owned by the business, unless of course the organization in which you work is set up in a hybrid function with business and technology mixed, but typically the rule should be owned by the business. Business rules tend be static, and not change much over time. However, that doesn’t mean they do not, or will not, change.

One way to identify a business rule is if the business owner needs to make a decision. This is not always the case because not all business rules are decisions, but this is why it’s common to see business rules in process maps/models, because the person creating the process map tries to document every single decision that is made in the process. Let me tell you a story of where I have witnessed this first hand. I remember working on a project where the business was mapping a new process for the organization. This process was going to be a game changer in the industry so there was a lot of pressure to get everything right for the time. I remember walking into the room where the process was being documented with sticky notes (to make it easier to move and change the process as discussions occurred) and I saw over 20 decision symbols. The process took up half of the conference room. When I started asking questions around all the different decision points, it became evident what was being documented were business rules. You see, the team was documenting every single rule that could qualify a customer for a type of loan. I recommended that all off the rules could be wrapped up into one activity, which stated “Run Eligibility Rules”, From there we created a document that listed out all the business rules and linked that document to the process activity. From that activity either the rules ran successfully or they failed and the process went on from those two paths. In this particular case, the process map went down from taking up ½ of the conference room to a ¼ of the conference room. It was also easier for the audience to follow the process. So, as you create process maps/models determine if your decision points really serve better as a business rule and show be stored in a business rules engine, or some other container, of if the decision should be in the process map/model.

Another way to identify a business is if the rule is very specific to how a certain activity, or operational process in the business needs to function. Meaning, it’s an easy way for a business owner to determine how he/she needs to conduct business. We will get into some examples below and this will all begin to make sense, if it hasn’t already.

I should also mention you will also hear about business rules in the context of database administration. Not only is this where many business rules tend to be stored and analyzed, but they are very useful to database administrators as it alerts them on how relationships needs to occur within database models.

Now let’s talk a little bit about how you write business rules.

2. How to write business rules

When you write business rules you want to ensure the business rules are specific and clear. I would also recommend you make them as concise, specific, and attainable as you can. Remember these rules help to define how business owners will conduct their operations or processes, so you want to be as specific and clear as possible. In addition, when the technology teams implement business rules or build solutions leveraging the business rules you want to ensure there is a clear understanding of what needs to be developed. Many of you may already be familiar with how to write a business rule as you may have written them in the past, but I wanted to provide a few examples below if you are not as familiar with business rules.


  1. A credit check must be performed before an auto loan can be approved.

  2. A customer deposit must occur by 2pm Pacific Standard time for it to be available same day for the customer to use.

  3. A customer must give authorization before their credit report can be ran.

As you can see above the rules are very specific, and advise the business owners how they need to conduct business. These rules would probably be captured in a job aide or standard operating procedure as well, especially when the rules could potentially cause an organization to be out of compliance with regulations. Once you have written your business rule ask yourself:

  1. Is the business rule clear?

  2. Is the business rule specific?

  3. Is the business rule attainable?

  4. Can the business rule be tested?

If you have answered “no” to any of these questions go back and look at your business rule. At a minimum these items should be true.

As discussed earlier, you can identify business rules in many different ways. In addition, you can see how it can be tempting to capture these rules in process maps/models, especially if attached to a regulation to ensure there is demonstration of where there are regulatory touchpoints. There is definitely justification to captured some rules in a process map/model, but not all. For example, #2 above could be an example of a business rule that is not included in a process map/module, where #1 and #3 may need to be included before the next activity could occur. However, it really depends on how the process map/module is created, and the purpose of the process map/model.

Now that you have some context around how a business rule is created, in my next post I will discuss how to store these rules once you have identified them.

Until next time, signing off,

The BA Martial Artist🥋


P.S. Sign-in and leave a comment below on how you have identified business rules in the past.

74 views0 comments

Recent Posts

See All