Never-ending On-the-Job Training

by Ronald G. Ross

This column originally appeared in the May/June 1997 issue of the Data Base Newsletter.

Everyone is talking these days about the accelerating rate of change and the urgent need to build business systems that prove more adaptable. The business rule approach clearly addresses that need. The Newsletter talks about that on a regular basis. I believe there is a flip side to the issue of change, however, which has received very little attention. That flip side has to do with training.

Remember the old story about telephone operators? Use of the telephone has grown at such a rate, that if automatic switching had not been invented, it is said that by now everyone would be a telephone operator. I believe that the rate of change in business today is just as fast. Workers are being thrown into new responsibilities and procedures at an ever-increasing rate. That means they must be trained -- by other workers. If this keeps up, sooner or later, everyone will have to become a trainer.

Clearly, that cannot happen. The only solution is to make training automatic -- that is, built right into the information systems that support the workers' day-to-day responsibilities and procedures. I believe business rules can make that happen. Here's how.

The business rule approach features declarative expression of rules. This declarative expression is associated with a simple textual statement (e.g., a rush order may include no more than 5 items). When a worker violates this rule performing any procedure, what error message should pop up on the screen? Not some obscure system code, or any message in computerese, but the business rule text itself! I like to say that business rules are the error messages.

Another way to look at this is that the business rule represents a requirement that is pure 'business logic.' In the business rules approach, this type of requirement gets input directly in building the system, then gets output directly to inform the worker when a violation in his work is detected. Think of that as a communication from a worker who knows the 'business logic' to a worker who must follow the business logic -- without these workers ever communicating directly.

A friendly business rule system goes a step further. When an error is detected, not only does the business rule system materialize the original business logic for the worker but can offer a canned procedure to the worker so that he can correct the violation. In that way the user not only learns the business logic but also learns how to correct mistakes. The very same applies even for experienced workers who encounter changes to the business policies they already knew.
For these reasons, I think of the business rule systems as instructional. Think of it as never-ending on-the-job training.

standard citation for this article:

Ronald G. Ross, "Never-ending On-the-Job Training," Data Base Newsletter, Vol. 25, No. 3 (May/June 1997), URL: http://www.BRCommunity.com/a1997/a508.html

September 2005
The Fin de Siegle Legacy Mindset
By Ronald G. Ross -- (November/December 1999)

August 2005
Analysis Paralysis Just May Save Your Life
By Ronald G. Ross -- (September/October 1999)

July 2005
If We Had Started Coding Already...
By Ronald G. Ross -- (July/August 1999)

June 2005
Your Core Business Processes Need a Rule Engine
By Ronald G. Ross -- (May/June 1999)

May 2005
Four Things Wrong with the Way We Develop Information Systems
By Ronald G. Ross -- (January/February 1999)

April 2005
Push-Type Data Hub vs. Pull-Type Data Warehouse
By Ronald G. Ross -- (November/December 1998)

March 2005
What Knowledge Management is About (And What it Has To Do With Business Rules)
By Ronald G. Ross -- (September/October 1998)

February 2005
The Next Great Leap Forward ~ About the Changes You See
By Ronald G. Ross -- (May/June 1998)