How Rules and Processes Relate ~ Part 6. Point-of-Knowledge Architecture (POKA)

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross

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 processThin 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.

  1. 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.

  2. 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.

Table 1. Levels of Enforcement for Rules and their Implications for Designing Scripts

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. return to article

[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). return to article

[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 return to article


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:


citations icon
Ronald G. Ross, "How Rules and Processes Relate ~ Part 6. Point-of-Knowledge Architecture (POKA)" Business Rules Journal, Vol. 7, No. 3, (Mar. 2006)
URL: http://www.brcommunity.com/a2006/b276.html

About our Contributor:


Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the BRS Methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:


Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross

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.