Business Rules Are Everywhere — Part 4: Many Faces of Rules in and Around Processes

Summary:
Wrapping up his theme of the power of putting business rules in the hands of the business people, Jim Sinur brings 'rules' out from the shadow of process, where he says that they have been for over a decade. In this column he explores some of the more common faces of rules that we find today as well as some that will emerge in the future.

Rules have been in the shadow of process for over a decade, but it is time to give rules their due. If we make the rules — particularly business rules — transparent, explicit, easy to understand, and easy to change, we can possibly cope and flourish with the speed of change that is only accelerating. I'd like to explore some of the more common faces of rules that we find today and that will emerge in the future.

Deep Frozen Logic

As long as there have been computer programs, logic has been deeply embedded within them and programmers have been the gatekeepers of business change. Where the logic is complex and deep and static, this is a perfectly good approach. However, today less and less of the business logic represented by rules really falls into this category. This is a dying breed in a world hungry for change.

Explicit Rules

Instead of deep embedding, many savvy business and IT professionals have figured out which rules change the most and have separated them from the deep frozen logic approach. This allows for quicker change and, in some cases, less deep testing for some logic (look and feel, for instance).

Visual Rules

A key to making rules understandable and easy to change is to make them visible. The three most common representations are decision trees, decision tables, and decision flow models. In some implementations these have been used in combination. An emerging standard that plays well with process modeling (BPMN or BPMN-like) is the decision modeling notation (DMN).

Flow Rules

These are specific types of rules that guide the flow of a process instance inside a process, a process snippet, or the sequential portion of a case. They are about deciding where the instance or case is going to go next. It is a next step or action thing.

Orchestration Rules

These are specific types of rules that determine which logic is being called upon to complete a step or action. These are often deep and tight logic portions of business or technical logic. Often the results of the code or called service are captured for the flow rules to make their determination for the next step.

Interface Rules

These are specific rules about the look and feel of a particular process application. They can also help decide the next portion of the interface to bring up (sub-screens in the UI). They are often key in helping the customer experience, and they exist in the engagement portion of processes or applications. More and more these are being exposed to customers for customization on a large scale. These also apply to dashboards and scorecards related to process performance and business outcomes.

Data Syntax Rules

These are specific rules around protecting the accuracy of data and include data domain definitions, data relationships, and cross data field editing. These are critical rules for data accuracy.

Transformation Rules

These are specific rules around changing the format, domain, context, and relationships around data and their formats. These are quite necessary to get systems to talk to each other and, certainly, for systems to talk to people.

Notification Rules

These rules are for when certain people or systems need to know when something (often an event or a pattern of events) is worth noting — for instance, when a set tolerance is violated.

Context Rules

These rules are telling the process (or portions thereof) what conditions and patterns might do to their particular behavior. If they are being used in an on-demand situation versus a routine scheduled situation, this allows the same rules to behave a bit differently. This is often used in geographical applications, especially where countries need a local variation. Of course, there are other variations.

Constraint & Governance Rules

These rules are about keeping process or application actions away from conditions or situations that could cause harm — for instance, if an emerging process would act badly. These rules also keep process participants (humans or machines) from doing something undesirable or, worse yet, illegal. These are sometimes referred to as boundary rules.

Net; Net

There are many kinds of rules, in all sorts of formats. This is not a complete classification, but this list will help you and your processes. The key is to promote them for easier change, close to the parties impacted where possible.

Standard citation for this article:

About our Contributor:

Jim Sinur
VP and Research Fellow, Aragon Research

Jim Sinur is an independent consultant and thought leader in applying business process management (BPM) to innovative and intelligent business operations (IBO). His research and areas of personal experience focus on business process innovation, business modeling, business process management technology (BPMT), processes collaboration for knowledge workers, process intelligence/optimization, business policy/rule management (BRMS), and leveraging business applications in processes. Mr. Sinur was critical in creating the first Hype Cycle and Maturity Model, which have become a hallmark of Gartner analysis, along with the Magic Quadrant. He has been active in the rules, data and computing communities, helping shape direction based on practical experience. Mr. Sinur has vertical industry experience on the investment and operational sides of the insurance and financial services.

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.