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

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)