untitled
Implementing Application Packages: Is There a Better
Way?
by Ronald G. Ross
| This column originally appeared in the Sep./Oct. 1997 issue of the
Data Base Newsletter. |
How do you go about fitting application packages to the business (or vice versa)?
You have to look hard to find a company that doesn't face this challenge in one form
or another today. You can talk about the year 2000 as the Big One, but that
one will come and go -- application packages won't.
Yet no one seems to have an approach they feel completely comfortable with.
- You can (and should) closely examine the features of the package itself, but
that does nothing for the business tactics you need to put the package to work for
you.
- You can (and should) develop comprehensive workflows to outline new procedures,
but that does nothing for the policies you need to make them most effective.
- You can (and should) do data modeling, but that does nothing for the business
risks you must address to stay competitive.
For this reason, top-notch professionals have begun eyeing the business rule approach
for new ideas. After all, business rules represent the core business logic
that the application packages must address.
But how exactly could a business rule approach be applied? After all, an
application package comes complete with ready-made terms, facts, and rules (not usually
described that way) -- which is what the business rule normally seeks to develop.
Why go through all that bother?
There is an easy answer and a hard answer. The easy answer is that many
packages (a) come with extensive options that must be selected and set, and/or (b)
cover only a portion of the targeted business area. Business rules provide
direct assistance for meeting both these needs.
The hard answer is hard because it is really a matter of perspective. Acquiring
an application package is really a business matter -- and that means looking
at the world through the hard lens of business cause-and-effect. If we adopt
this tactic vs. that tactic, what advantages will result? If we choose this
course of action vs. that course of action, what risks will we face? If we
set this policy vs. that policy, what side effects may occur?
This is not the view of 'business rules' that IT professionals normally take.
However, I believe it is actually the purest form of 'business rules.' Business
rules one level up. Not system architecture, but business motivation.
Not rules, but policies.
To be more specific, my associate in business rules, Gladys S.W. Lam, and I recommend
that what you need to bring in an application package is the same as you need to
launch any in-house application development project -- to develop a Policy Charter.
After all, it's not where the software comes from that counts -- it's what it will
do for the business!
| standard citation for this article: |
| Ronald G. Ross, "Implementing Application Packages: Is There a Better
Way?" Data Base Newsletter, Vol. 25, No. 5 (Sep./Oct. 1997), URL: http://www.BRCommunity.com/a1997/a369.html |
|
|
|
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
|