untitled
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.
|
|
November/December 1999
The Fin de Siegle Legacy Mindset
By Ronald G. Ross
September/October 1999
Analysis Paralysis Just May Save Your Life
By Ronald G. Ross
July/August 1999
If We Had Started Coding Already...
By Ronald G. Ross
May/June 1999
Your Core Business Processes Need a Rule Engine
By Ronald G. Ross
January/February 1999
Four Things Wrong with the Way We Develop Information Systems
By Ronald G. Ross
November/December 1998
Push-Type Data Hub vs. Pull-Type Data Warehouse
By Ronald G. Ross
September/October 1998
What Knowledge Management is About (And What it Has To Do With Business Rules)
By Ronald G. Ross
May/June 1998
The Next Great Leap Forward ~ About the Changes You See
By Ronald G. Ross
March/April 1998
Business Rules as Customer Interface
By Ronald G. Ross
January/February 1998
Components and Business Rules: Do They Connect?
By Ronald G. Ross
November/December 1997
The Policy Charter: A Small-Sized Picture of the Big Picture
By Ronald G. Ross
September/October 1997
Implementing
Application Packages: Is There A Better Way?
By
Ronald G. Ross
July/August 1997
'Why'
is Why Business Rule Methodology is Different
By
Ronald G. Ross
May/June 1997
Never-ending
On-the-Job Training
By
Ronald G. Ross
September/October 1996
Re-Usability
in the Business Rule Approach
By
Ronald G. Ross
March/April 1996
The
Newest Idea In Business Rules: Rules Normalize!
By
Ronald G. Ross
January/February 1996
An
Open Letter to DBMS Vendors: We Need Active Database Systems
By
Ronald G. Ross
May/June 1995
The
Greatest Irony Of The Information Age: Business Rules
By
Ronald G. Ross
November/December 1995
Business
Rules:
Knowledge For Knowledge Workers
By
Ronald G. Ross
March/April 1994
"Play
Ball!"
By
Ronald G. Ross
November/December 1999 & January/February 2000
Enterprise
Architecture: Issues, Ingibitors, and Incentives
By
John A. Zachman
July/August & September/October 1999
Packages
Don't Let You Off The Hook
By
John A. Zachman
November/December 1988
The
History Of Steam-Powered Ships
By
Ronald G. Ross
January/February & March/April 1999
Life
Is a Series of Trade-Offs and Change Is Accelerating!
By
John A. Zachman
January/February 1994
"Business
Rules, At What Cost?"
By
Ronald G. Ross
November/December 1998
"Yes
Virginia, There IS an Enterprise
Architecture"
By
John A Zachman
May/June 1994
Business
Rules: Birth of a Movement
By
Ronald G. Ross
January/February 2000
Business
Systems And Information Support Systems
By
John Hall
July/August 1998
Enterprise
Architecture: Looking Back and
Looking Ahead
By
John A. Zachman
July/August 1991
Why
I Like the Zachman Framework Architecture"
By
Ronald G. Ross
January/February 1998
The
Framework for Enterprise Architecture (The 'Zachman Framework') and the Search
for the Owner's View of Business Rules
By
John
A. Zachman
March/April 1997
Business
Process Re-Engineering
By
Ronald G. Ross
|