Why is Why Business Rule Methodology is Different

by Ronald G. Ross

This column originally appeared in the July/August 1997 issue of the Data Base Newsletter.

Outwardly, the business rule approach produces many of the same deliverables as any other approach to building automated business information systems -- screens, processes, data, controls, etc. In other words, the end result is almost sure to include some application system. So why is the business rule approach any different from other system development methodologies? Here's why.

As discussed in previous Newsletter issues, a business rule methodology places an emphasis on the following:

Balancing what the company 'knows' and what it 'does.'
Specifying requirements in a declarative manner.
Liberating rules from processes.
Producing thin processes and throw-away procedures.

These features have various technical advantages, but collectively they seek to ensure that the resulting application system produces an adaptable business.

This has two important implications. First, to achieve that result, the 'application' components must be seamlessly integrated with the business itself. To say that a business rule project aims toward producing application software misses the whole point. The real objective is to produce a full business capacity that covers all the following areas.

business aspect business component IS component

knowing terms and facts data model

producing business transformations actions

communicating business network communications grid

collaborating work procedures

coordinating precedence states

guiding ends and means rules

The second implication is being able to address the issue of motivation. A business capacity will be of little value if it addresses the wrong business objectives. The key question is why the business capacity in its particular form is the right one for the company.

Traditional system development methodologies have done a poor job of answering that key question. Information engineering, for example, sought to answer it by involving sponsors and key managers directly in producing deliverables. This was not only expensive and time-consuming -- but worse, did not really even work. Today, most projects are still directed based on cost. Money is important, of course -- but it is not a substitute for knowing why.

The business rule approach offers a revolutionary new approach. This is because core business rules are always about satisfying a particular set of business objectives involving a particular set of business risks. These connections are not 'data' and they are not 'process.' Instead, they represent something different altogether -- namely why.

standard citation for this article:

Ronald G. Ross, "'Why' is Why Business Rule Methodology is Different," Data Base Newsletter, Vol. 25, No. 4 (Jul./Aug. 1997), URL: http://www.BRCommunity.com/a1997/a365.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)