Premise and Conclusion

How Rules and Processes Relate

Part 5.  Scripts -- Rule-Friendly Process Models

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

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 script:  Take customer order.

Rule:  A 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.

[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  

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: Ronald G. Ross, "How Rules and Processes Relate ~ Part 5.  Rule-Friendly Process Models," Business Rules Journal, Vol. 7, No. 2 (Feb. 2006), URL:  http://www.BRCommunity.com/a2006/b271.html