By: Joe Goss
I enjoy playing board games with my family. Perhaps you have some favorite board games, too. Have you noticed there are two dimensions to most of these games? The first, of course, is playing the game – the operational dimension – rolling the dice, moving a token, or taking a card. The second dimension is the set of rules that govern play. These rules typically define terminology, constrain player behavior, and trigger action in the operational dimension. In short, the rulebook governs the operation of the game. Let’s face it – without the rulebook, a game would be hard to understand and very frustrating to play.
Each operational process in your organization has rules as well. There are policies, guidelines, and restrictions that govern behavior in every operational process. Here are a few regarding an inventory system, for example:
- The production manager sets the maximum allowable level of each item in inventory
- The quantity of an item in inventory shall not exceed the level established for that item
As you can see, these rules constrain behavior in the execution of an inventory process. The first rule defines who is responsible for setting the maximum level stored for each item in inventory. The second rule constrains both personnel and the technology system from exceeding that maximum. We call these declarative sentences “business rules.” In the book “Business Rule Concepts,” Ronald Ross defines a business rule as “a statement that defines or constrains some aspect of the business, one that “assert[s] business structure or control[s] or influence[s] the behavior of the business” He notes that a business rule:
1. Is under organizational jurisdiction, which the organization may enact, revise, and/or discontinue
2. May define, restrict, guide, calculate, infer, schedule, or trigger
3. Must be practicable (i.e., can be put into practice)
Business rules in action
Here are some representative business rules related to a student at a university in applying for a scholarship.
Definition: A student has a status of “good standing” when he or she is enrolled in the current semester, has a cumulative grade point average 3.0 or greater, and is not currently under any disciplinary actions.
Restriction: A student must be enrolled for the next semester and be in good standing to be considered for a scholarship.
Guideline: A student should declare a major in a specific department before being considered eligible for a scholarship from that department.
Computation: A student’s unmet financial need equals the sum of tuition, fees, living costs, and customary expenses, minus the family’s estimated financial contribution.
Inference: Any student who completes a scholarship application is considered a scholarship applicant.
Timing: A student awarded a scholarship must accept or refuse the award within two weeks of the date on which notice of the award was sent.
Trigger: Any student who filed a Free Application for Federal Student Aid (FAFSA) is considered for need-based scholarships.
Components of business rules
These business rules share two important characteristics
1. Each is expressed as a declarative statement
2. The order of these business rule statements does not matter – they are non-procedural and apply regardless of the sequence as they appear
What would it mean to those involved in the scholarship application and awarding processes if the business rules were not identified, documented, published, and understood? Similar to a board game without rules, it’s clear that financial aid stakeholders would get very frustrated with these processes. Ineligible students would be inappropriately considered for scholarships. Parents might misrepresent financial need. Students awarded scholarships might miss the deadline for acceptance. Think for a moment about a critical operational process in your organization. Are the business rules that govern that process well documented, communicated, and understood? Are these rules applied universally by management, staff, and computer systems?
Many years of experience in developing use cases and process flows have taught me that any process model consists of two parts – a process and a context. The former is simply the sequence of steps necessary to achieve a result. The second part is the context; it includes the business rules, as well as the actors and goals of the process. The process part is procedural; the context is non-procedural. With those two dimensions in mind, I reserve space in a use case or process flow for business rules. I’ve discovered that as I work with a team, that business rules inevitably emerge from our discussion. We use this space to record, review, and refine the business rules that govern the process we are mapping.
Avoid business rule mistakes
I want to illustrate a common mistake regarding business rules in developing process models. For this exercise, let’s focus on just a few of the business rules listed previously:
- A student has a status of “good standing” when he or she is enrolled in the current semester, has a cumulative grade point average 3.0 or greater, and is not currently under any disciplinary actions.
- A student must be enrolled for the next semester and be in good standing to be considered for a scholarship.
- A student should declare a major in a specific department before being considered eligible for a scholarship from that department.
Could I model these simple business rules in a process flow diagram? Yes, I can, but there are issues to consider. Review the following example, which uses the nomenclature of Business Process Modeling and Notation (BPMN).
Representing these three simple business rules requires a very complex process flow. Representing this if-then-else logic in a narrative use case is even more challenging. You can imagine that a complex set of business rules would be progressively harder to model than this simple example. Further, I’ve violated a rule about business rules by modeling them here. Remember, business rules are non-procedural. Also, some or all of these business rules may apply to other processes. It may be necessary but cumbersome for me to duplicate some or all of these business rules within other BPMN processes. Embedding the business rules in the process flow makes it more difficult for me to identify conflicts among all of the business rules scattered among process flows. For these reasons, I’ve found it best to create a separate list of business rules, written as a narrative, and refer to them in the process flow. Compare the following process flow with the previous one.
This process flow is vastly simpler to the previous one. In many ways, it’s also much more usable. For example, I can combine this set of narrative business rules with those governing other processes. That master list will help me and the process mapping team identify business rule conflicts and omissions.
Joe Goss teaches Developing Process Models and Use Cases, in-person and online, for the Wisconsin School of Business Center for Professional & Executive Development. For information on upcoming course dates, contact [email protected].
About the Instructor: Joe Goss
Joe is a senior business analyst and project manager at the University of Wisconsin–Madison Division of Information Technology (DoIT). Joe’s background includes significant work in providing solutions to public and private organizations in sectors including agriculture, accounting, education, manufacturing, retail, public housing, law enforcement, judicial courts, public health, and natural resources. Over a 35-year career, he served clients while employed at several software development companies, a regional accounting and consulting firm, and an international computer vendor, in addition to his work as an independent consultant.