Re-Usability in the Business Rule Approach

by Ronald G. Ross

This column originally appeared in the Sep./Oct. 1996 issue of the Data Base Newsletter.

The object community touts re-usability as a major benefit of object orientation (OO). I believe the business rule approach can produce re-usability on a far greater scale. Let me explain.

Re-usability means various things in OO. For example, an object class can (should) be formed such that the services (methods) it provides can be invoked (i.e., re-used) by many other object classes. This corresponds roughly to the traditional notion of modularity in software engineering.

A more specific interpretation of re-usability in OO is that an operation (method) defined for a supertype automatically is inherited by all subtypes. This enables re-use. Actually, the real focus, however, is on revisability. For example, the operation named 'pay salary' for Employee can be revised to 'work' differently for the subtype Manager. All other object classes (potential 'users' of the operation), however, are shielded from the distinction.

These are good ideas, but fundamentally they are about software re-usability. Can the business rule approach potentially incorporate them? Yes (plus inheritance and revisability for rules). Does the business rule approach potentially offer more? Yes -- far more. Here's how.

In the business rule approach, rules must be segregated from procedures. (This is one aspect of what I call 'rule independence.') Followed rigorously, this produces procedures (I call them 'scripts' -- OO might call them 'use cases') that are nothing more than simple series of requests (a.k.a. 'thin processes'). An implication is that procedures become 'cheap' -- in effect, throw-away. That's exactly what businesses need these days to become more adaptive.

In this environment, rules provide the boundary between procedures for normal business activity and procedures for abnormal business activity (a.k.a. rule violation activity). Here's how that happens. When a procedure (script) for normal business activity fires a rule, a violation may be detected. If so, a procedure (script) to handle it can be invoked automatically. That offers the user the opportunity to correct the violation -- for example, to create, update, or delete the data that caused the violation in the first place.

Re-usability arises as follows. Ideally, the invoked procedure (script) should be the one that in other circumstances would be used for the normal business activity involving that data. In other words, entire procedures -- the ones the users should know already -- can be re-used. As far as I know, OO has no equivalent concept. And without rules, I doubt one can be found.

standard citation for this article:

Ronald G. Ross, "Re-Usability in the Business Rule Approach," Data Base Newsletter, Vol. 24, No. 5 (Sep./Oct. 1996), URL: http://www.BRCommunity.com/a1996/a507.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)