How Rules and Processes Relate ~ Part 5. Scripts -- Rule-Friendly Process Models

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

Only a relatively small portion of traditional application code literally supports the actual steps of a process.  Much of the code is devoted to edits, validations, derivations, and calculations -- in other words, to rules -- as well as to the detection of related events.

When the rules are taken out of a process in an information/knowledge system ("system process" for short), 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.

A football play is a good analogy.  A diagram of a football play is literally represented as a collection of orchestrated steps needed to accomplish the desired result (advance the ball).  It is nothing more and nothing less.  No rules -- or penalties for violating these rules -- are embedded within it.  A play simply focuses on doing the work.

In the design of an information/knowledge system (I'm using that term for reasons discussed in my previous column), the 'plays' are the system processes, which we (BRS) call scripts.[1]  Using 'script' rather than 'system process' emphasizes both:

  1. The critical shift in mindset needed in moving from a business perspective to a system perspective.  As I discussed in my last column, business processes and system processes are not the same!

  2. A re-orientation to rule-friendly process models.  Process models for designing information/knowledge systems under the business rules approach are not the same as process models as you have known them from before!

Scripts provide patterns for doing work from the perspective of system design.  Scripts might be used to take a customer order, evaluate a medical claim, book a reservation, assign a teacher to a class, and so on.  Often a script is undertaken in response to something that somebody does (for example, a customer placing an order).  A script can also be undertaken in response to some timing criteria (e.g., when to bill customers), or to some predefined condition (e.g., inventory quantity on hand is below a certain threshold).  In both these latter cases, by the way, appropriate criteria for automatically initiating the scripts can be expressed as rules.

Series of steps is an apt description of a script; prescribed series of requests is even better.  

Aside:  Prescribed means that the given series of steps can be followed to achieve the desired results, but not that they must be followed.  For example, there might be one or more other series of steps that can be followed to achieve the same results.  To say must be followed represents a rule about sequencing, or more precisely, about required antecedents.  It is a matter of preference and pragmatics whether that kind of rule should be embedded in the notation for system processes, graphic or otherwise.  In BRS-style scripts, we prefer not to; as a result, any series of requests is merely prescribed (not mandatory).

By requests I mean requests for action, which can be of various kinds -- for example:

Sample Kinds of
Request for Action

Example

Retrieval   Obtain credit rating for a customer from the credit system.
Storage   Store customer information.
Modification Modify year-to-date claimant payments.
Display Display customer's current account balance.
Communication   Insert a special order into a supervisor's work queue for approval.

These requests are generally handled by software components presumed to execute.  Such software components might include DBMSs (to create, retrieve, modify, or delete data), GUIs (to display data), service providers (e.g., print routines), interfaces to legacy systems, work queues, special-purpose rule analyzers, and so on.

Including People in Scripts

In many respects, the most important sources or recipients of requests in scripts are people.  People, after all, do a lot of actual work!  These people might be either inside the company (that is, workers) or outside the company (e.g., customers).

Aside:  Since we are talking about a system design, it's obviously not actually the real people -- it's surrogates via logical communication links.  Only in a business model -- which a script is not(!) -- could you say "people" and actually mean the real flesh-and-blood people.  It's very important to keep these perspectives straight.

Although all these people might be seen as 'users', the term actor is really better.  'User' suggests outside beneficiaries of system services, whose own work and interactions are outside scope.  Actor, in contrast, suggests someone whose own activity or role is integral to understanding and doing the work.  An actor is someone whose own work is definitely within scope.

What can human actors do to move work along?  Two things:

  • Perform actions -- manually or otherwise.

  • Make requests for action to software components or to other actors.

These are exactly the same two ways that software 'actors' participate in scripts.  That's a critical point.  Here's what it means:

  • Easy plug-and-play replacement of human actors with software actors (or vice versa!) as changing business circumstances warrant.  That's a crucial form of man/machine interoperability.

  • Incremental development.  As more and more business knowledge is encoded as rules over time, rule-based software 'actors' can take over run-of-the-mill decision-making tasks.  People can migrate toward more creative tasks.

Support for incremental development is especially important -- no reasonable approach to business rules is ever all-or-nothing.  Well-planned accrual over time -- and getting to the low-hanging fruit first -- that's always the prudent strategy.

Here then is the beginning of a new image for work:  

  • Many kinds of human and software actors interacting interchangeably under scripts.

  • Thin, throwaway scripts featuring choreographed collaboration.

  • And rules!

Smart Scripts

As discussed in the first column of this series, a foremost cause of time shock for business people is rapid change in the rules.  At any given time, actors participating in scripts might be found at virtually any stage of time shock.  Sometimes, you might find them completely up-to-speed, other times completely lost.  Most of the time, they are probably somewhere in between.  That poses a big challenge with respect to training.

The only approach to training that will truly scale is on-the-job self-training.  That requires smart scripts, ones coordinated with rules so that pinpoint guidance can be put right in front of actors in real time as the need arises (assuming they are authorized) -- that is, right at the points of knowledge.  Where do you find these points of knowledge?  Two places:

  • Wherever a human actor might not understand or might disagree with the results from structural rules.

  • Wherever a human actor could violate an operative rule.

Aside:  I discussed these newly introduced business-level categories of rules earlier in this series[2]  Briefly, an operative rule can be violated directly by people involved in affairs of the business.  Operative rules govern the on-going conduct of business activity, always carrying the sense of obligation or prohibition.  A structural rule can be ill-conceived, misunderstood or misapplied, but it cannot be directly violated.  Structural rules organize (i.e., structure) basic knowledge of the business, always carrying the sense of logical necessity or impossibility.

Violation of operative rules has especially powerful implications for all rules that are automatable.  What guidance message should be returned to an actor when such a rule is violated?  As I have been saying for many years (it was a key point in the first edition of Business Rule Concepts, in 1998), the guidance message should succinctly state the business rule that was violated.  What that means, in effect, is that the relevant portion of the rulebook is 'read' to the actor on-line (including relevant structural rules), right as the actor bumps up against the operative rule.  Remember, the really rapid change is in the rules -- these days, no worker can safely assume immunity from time shock.

Rule-Based Process Re-Usability

Scripts imply reuse of software as a given.  Over and above that, scripts offer process reusability.  With rules, that means a lot more than simply 'modular design'.  

Rule-based re-use of processes is distinctive of the business rule approach.  It works like this.  A script for undertaking work in normal circumstances is invoked as the designated response to the violation of some rule.  That script kicks off automatically whenever a violation of the rule is detected.

Aside:  This invocation capability, as well as the capability to detect violations, is assumed to be an automatic (built-in) part of the system.  Support by a rule engine or similar platform is clearly desirable.  In any case, support should never be part of any script (or other portion of an application) but, rather, provided by software infrastructure.

To illustrate, Table 1 shows what such activity would look, like step-by-step, using this simple scenario to illustrate:

Work scriptTake customer order.

RuleA customer who places an order over $1,000 must hold an account.

Should the rule be violated in this script, invoke the script:  Establish customer account.

Note:  Let's say this is the script normally used to set up accounts, so there's a good chance it would be already familiar to the order entry clerk.

There's much more exciting to talk about with scripts, but I'll save that for the next and final column of this series.

Table 1.„ Step-By-Step Activity for Rule-Based Re-Use of a Process
 

 Step-by-Step Activity

 Simple Scenario

1. A worker executes a script A worker (order entry clerk) performs the script (Take customer order) to take an order.
2. The worker makes a request under that script. The worker (order entry clerk) makes a request (that the order be stored).
3. The request produces a change in state. Change in state (storage of the order) is attempted.
4. The event results in the evaluation of relevant rules, if any. This event fires the rule:  A customer who places an order over $1000 must hold an account.
5. A violation of one of these rules, let's suppose, is detected. Let's say the customer holds no account, so a violation of the rule is detected.
6. Another script (designated beforehand by the rule analyst or process analyst) is invoked automatically. The script Establish customer account had been designated beforehand as the one to be invoked for a violation of this rule.
7. This other script offers the capability needed for the original worker (or possibly someone else) to correct the error that caused the violation.  (Note:  This is a typical reaction, but not the only kind possible.  A script invoked for a security breach, for example, might focus on immediate countermeasures.) The order entry clerk is offered the opportunity to perform the script Establish customer account.
8. Supposing such work is undertaken under the offered script (not a given) ... The order entry clerk elects to do so.
9. And supposing such work is deemed satisfactory by the rule ... This work successfully corrects the original violation of the rule -- the customer now holds an account.
10. Then work can continue under the original script from where it left off. The order entry clerk resumes work under the original script, Take customer order, from the point it was interrupted.  For example, the next action might be to schedule the order's fulfillment.

Notes

[1]  BRScripts in Proteus®, the BRS business rule and business analysis methodology. return to article

[2]  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 5. Scripts -- Rule-Friendly Process Models" Business Rules Journal, Vol. 7, No. 2, (Feb. 2006)
URL: http://www.brcommunity.com/a2006/b271.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
Subscribe to the eBRJ Newsletter
In The Spotlight
 Silvie  Spreeuwenberg
 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.