Why the Types of Business Rules Should be a Concern
As briefly discussed in my post A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture, the operational result of the Governance and Policy Management Processes is Business Rules. This post will discuss the types of business rules because a good understanding of the types of rules is an imperative in understanding how they effect an automated business process and their enabling and supporting IT systems. In the US Federal Government, the analog of these Business Rules are the Regulations that enable and support the Laws.
The reason needing to understand the types of Business Rules is that to effectively, cost efficiently, and agilely automate the support of an organization's processes requires a formal method for enforcing and mediating/adjudicating the organization's policies and standards. This formal method requires a translation/transformation of the policies and standards into rules that can be automated. But there are at least three type of enforcement rules. Understanding what each type of rule does two things; helps to ensure that "the rules" aren't muddled, and ensures that the policies and standards are adequately and completely enabled (i.e., that some part of the policy or standard is not checked because there is no rule to support it).
In addition, if the rules are stored in a Rule Repository (which is part of the Asset and Enterprise Architecture Repository, AEAR), then as new rules are put in place, the Enterprise Architect can check to ensure that they do not conflict with other rules. And, as rules are revised/updated the Enterprise Architect can check to ensure that they do not create defects in the processes by the way they are implemented.
Types of Business Rules
A Business Rule is a metric or group of metrics for determining whether a system or user is out of conformance with a policy or standard and the change in value for the organization due to the non-conformance. This definition may be "as clear as mud, but it does cover the ground". To clarify the definition, let's consider the types of rules.
There are at least three types of Business Rules that serve different roles in enforcing the policies and standards within the organization's processes and systems.
As briefly discussed in my post A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture, the operational result of the Governance and Policy Management Processes is Business Rules. This post will discuss the types of business rules because a good understanding of the types of rules is an imperative in understanding how they effect an automated business process and their enabling and supporting IT systems. In the US Federal Government, the analog of these Business Rules are the Regulations that enable and support the Laws.
The reason needing to understand the types of Business Rules is that to effectively, cost efficiently, and agilely automate the support of an organization's processes requires a formal method for enforcing and mediating/adjudicating the organization's policies and standards. This formal method requires a translation/transformation of the policies and standards into rules that can be automated. But there are at least three type of enforcement rules. Understanding what each type of rule does two things; helps to ensure that "the rules" aren't muddled, and ensures that the policies and standards are adequately and completely enabled (i.e., that some part of the policy or standard is not checked because there is no rule to support it).
In addition, if the rules are stored in a Rule Repository (which is part of the Asset and Enterprise Architecture Repository, AEAR), then as new rules are put in place, the Enterprise Architect can check to ensure that they do not conflict with other rules. And, as rules are revised/updated the Enterprise Architect can check to ensure that they do not create defects in the processes by the way they are implemented.
Types of Business Rules
A Business Rule is a metric or group of metrics for determining whether a system or user is out of conformance with a policy or standard and the change in value for the organization due to the non-conformance. This definition may be "as clear as mud, but it does cover the ground". To clarify the definition, let's consider the types of rules.
There are at least three types of Business Rules that serve different roles in enforcing the policies and standards within the organization's processes and systems.
Knowledge Rules
A knowledge rule is a metric within which the process, system, or user is in conformance and outside of which the process, system, or user may be out of conformance. The operative word is "may". Many times it takes more than one metric for a rule "to be broken". A trivial example is based on an old US Air Force saying, "He ran out of airspeed, altitude, and ideas"; meaning the aircraft crashed. With sufficient airspeed an aircraft can gain altitude; with sufficient altitude an aircraft can gain airspeed; and so on. The point is that knowledge of the minimum airspeed to fly, the advantage of altitude, and other ideas(like landing in the water or a soft grassy area are all bits of knowledge that can keep a pilot alive and an aircraft in flyable (or at least repairable) condition. However, if the pilot violates all of them concurrently, he or she has a serious exciting short-term problem and an abrupt end.
Event Rules
A knowledge rule is a metric within which the process, system, or user is in conformance and outside of which the process, system, or user may be out of conformance. The operative word is "may". Many times it takes more than one metric for a rule "to be broken". A trivial example is based on an old US Air Force saying, "He ran out of airspeed, altitude, and ideas"; meaning the aircraft crashed. With sufficient airspeed an aircraft can gain altitude; with sufficient altitude an aircraft can gain airspeed; and so on. The point is that knowledge of the minimum airspeed to fly, the advantage of altitude, and other ideas(like landing in the water or a soft grassy area are all bits of knowledge that can keep a pilot alive and an aircraft in flyable (or at least repairable) condition. However, if the pilot violates all of them concurrently, he or she has a serious exciting short-term problem and an abrupt end.
Event Rules
An Event Rule determines when a process or user violates one or more of the organization's policies and standards. Event rules would seem to be easy to define, but the devil is in the detail. For example an organization may have an Oracle 10 database standard. While at first blush the knowledge of which database product used would seem to be the only knowledge rule needed, and the use of a non-Oracle 10 database product would seem to be knowledge needed to trigger the event rule, in fact it might be much more complex. For example, suppose there is a waiver to the database standard based on a contractual obligation. Then, the event has not occurred because two metrics are required, 1) that "a non-standard database is used" and 2) that "there is no waiver". You can see that if this most basic event rule requires more than one knowledge rule to cause the event, then most (business or organizational) Event Rules will require many more.
Value Rules
A Value Rule determines the value of the consequence of a violation of the policy or standard. While the Knowledge and Event Rules are the "If" clause of the "If-Then-Else" branching logic statement in programming and in business processes, the Value Rule is the "then" clause. The Value Rule determines the value of the various alternatives based on the cause of the Event, that is, the combination of Knowledge Rule values. For example, if the police officer pull a teenager over for not using a direction indicator (turn signal) on her car when changing lanes on an empty Interstate highway, the officer may give her a warning, while, if the Interstate is busy, the officer may give her a ticket. Again, if it is the driver's first offense, the officer may determine that a warning is sufficient, while if the driver has had one or more warnings, the officer may write a ticket.
Summary
If an organization can formally decompose their policies and standards into these three types of Business Rules, and can insert them into a central Rule Repository, which is part of the AEAR, then organization can be both much more agile and, at the same time, in control of changes in the policies and standards because the Enterprise Architect will be able to model the effects of any changes.
No comments:
Post a Comment