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. It is a dying breed in a world hungry for change.
Explicit Rules:
Instead of deeply embedding, many savvy business and IT professionals have figured out what rules change the most and 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. These have been used in combination in some implementations. An emerging standard that plays well with process modeling (BPMN or BPMN like) is decision modeling (DMN).
Flow Rules:
These are specific types of rules that guide the flow of a process instance inside a process, a process snippet or 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 service called 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 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 a on demand situation versus a routine scheduled situation. This allows the same rules to behave a bit differently. This is often used in geographical and countries that need a local variation. There are other variations, however.
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 kind 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 as close to the parties impacted where possible.
