How Rules and Processes Relate ~ Part 6. Point-of-Knowledge Architecture (POKA)
A general principle for software engineering is: The more granular the specifications for a system, the more adaptable (agile) it will be. Specifications for rule-oriented process models (scripts[1]) in information/knowledge system design are highly granular and therefore highly adaptive.
Before I get to that, let me summarize key points about scripts I made in the previous column of this series. Incidentally, I believe these are the 'must-haves' for any process modeling technique that seeks to play in the coming world of rule-oriented information/knowledge system design. Our name for this kind of system design is "Point of Knowledge Architecture" (POKA).
- Thin Process. When the rules are taken out of a process in an information/knowledge
system, the result is a thin process. Thin means that the process
prescribes only the necessary series of steps to accomplish the desired work
result. Excluded are all the rules -- and all the event detection and error
handling when violations of rules occur.
- Action by Request. Series of steps is an apt description
of a script; prescribed series of requests is even better. Requests
can be handled by software components presumed to execute. Each actor in a
script must be able to: (a) perform actions -- automatically or otherwise --
and (b) make requests for action to other actors.
- Man/Machine Interoperability. Human actors can be replaced by software
actors, or vice versa, on a plug-and-play basis as changing business circumstances
warrant.
- Incremental Development. As more and more business know-how is encoded
as rules over time, rule-based software actors can assume run-of-the-mill decision-making
tasks, permitting people to migrate toward more creative work.
- On-the-Job Self-Training. A world of constant change demands smart
scripts, ones coordinated with rules so that pinpoint, up-to-the-minute guidance
can be put right in front of human actors in real time as the need arises -- that
is, right at the points of knowledge.
- Rules as Guidance Messages. When a rule is violated, the guidance
message returned to the actor, if appropriate, always states the business rule.
- Rule-Based Re-Use. A script for undertaking work in normal circumstances can be directly invoked as the designated response to the violation of any rule, as appropriate.
As mentioned at the top of this column, agility in system design is achieved through granularity of specification. Ways in which POKA supports a high degree of granularity include, but are not limited to, the following. If it's agility you seek for your processes, move into the express lane for business rules now!
Separation of Rules and Processes. Rule Independence is the central idea of the Business Rules Manifesto[2]. Benefits accrue for both rules and scripts. A rule can be revised, replaced, or eliminated without touching any script(s) at all. Processes (scripts) become thin.
Separation of Scripts and Violation Responses for Rules.
- A script designated for violations of a rule can be revised, replaced, or eliminated
without touching the rule itself or any script that might produce violations
of it.
- Any script that might produce violations of a rule can be revised, replaced, or eliminated without touching the rule itself or the script designated for handling violations of the rule.
Level of Enforcement for Rules. Selecting the appropriate level of enforcement for an operative rule, something I've barely mentioned in this series, introduces an entirely new dimension of granularity. Possible levels of enforcement[3] are presented in Table 1, which also identifies some of the implications for script design in POKA. As this final piece of evidence again demonstrates, business rules achieve an altogether new threshold of opportunity to model processes effectively.
|
Level of Enforcement |
Description |
Implication for Designing Scripts |
| strictly enforced | If an actor violates the rule, the actor cannot escape sanction(s). | When a violation is detected, the event producing the violation is automatically prevented, if possible, and a designated violation response, if any, is invoked automatically. (Note: If the violation is time-based, the event generally cannot be prevented.) |
| deferred enforcement | The rule is strictly enforced, but such enforcement may be delayed -- e.g., until another actor with required skills and/or proper authorization can become involved. | When a violation is detected, the event producing the violation is allowed, and the relevant work is handed off to another worker (possibly by insertion into a work queue). Additional timing rules may be desirable to ensure that action is taken in a timely fashion. |
| override by pre-authorized actor | The rule is enforced, but an actor with proper before-the-fact authorization may override it. | When a violation is detected, if the actor involved is pre-authorized, that actor is given an opportunity to override the rule. Overrides by actor and rule should be tracked for subsequent review. |
| override with real-time waiver | The rule is enforced, but an actor may request a real-time waiver from another actor having before-the-fact authorization to give such waivers. | When a violation is detected, the actor involved is given an opportunity to interactively request a waiver from a duly-authorized actor. Additional timing rules are probably appropriate. Waivers should be tracked by actor and rule for subsequent review. |
| post-justified override | The rule may be overridden by an actor who is not explicitly authorized; however, if the override is subsequently deemed inappropriate, the actor may be subject to sanction(s). | When an override of a violation occurs, a review item (with all relevant details) should be inserted into the work queue of an appropriate actor for review and possible action. |
| override with explanation | The rule may be overridden simply by providing an explanation. | When a violation is detected, the actor involved is given an opportunity to override the rule by providing a mandatory explanation. Overrides should be tracked by actor and rule for subsequent review. |
| guideline | Suggested, but not enforced. | When a violation is detected, the actor involved (if authorized) is simply informed/reminded of the rule. |
References
[1] BRScripts in Proteus®, the BRS
business rule and business analysis methodology. 
[2] The Business Rules Group, Business Rules Manifesto
~ The Principles of Rule Independence, ver. 1.2 (Jan. 8, 2003). Available
at www.BusinessRulesGroup.org
(in English as well as translations to numerous other languages).
[3] Adapted from: Semantics of Business Vocabulary
and Business Rules (SBVR), by the Business Rules Team, August 2005. Available
to OMG members at www.omg.org
as bei/2005-08-01:
BRT's revised submission to the Object Management Group's (OMG) Business Semantics
of Business Rules RFP. For background on the SBVR and the consortium
that produced it, refer to "A Brief History of the Business Rule Approach,"
Business Rules Journal, Vol. 6, No. 1. Available at www.BRCommunity.com/a2005/b216.html
Excerpted from Chapter 6, Business Rule Concepts: Getting to the Point of Knowledge (Second Edition), by Ronald G. Ross. www.BRSolutions.com (September 2005). ISBN 0-941049-06-X. Reprinted with permission.
# # #
Standard citation for this article:
About our Contributor:
Online Interactive Training Series
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.
How to Define Business Terms in Plain English: A Primer
How to Use DecisionSpeak™ and Question Charts (Q-Charts™)
Decision Tables - A Primer: How to Use TableSpeak™
Tabulation of Lists in RuleSpeak®: A Primer - Using "The Following" Clause
Business Agility Manifesto
Business Rules Manifesto
Business Motivation Model
Decision Vocabulary
[Download]
[Download]
Semantics of Business Vocabulary and Business Rules