Business Rules and Scope

When applications were stand-alone entities, scope was an issue only when building a new application. ("What is the scope of this new application?") Now, however, as we are contemplating separating our applications into finer-grained services, and at the same time opening up their access to a much wider variety of human and other systems, suddenly scope becomes crucial. The issue is magnified with the advent of rule-based systems because we have to be careful to indicate over what range of conditions the rule is valid.

Scope

One of the simplest, yet slipperiest, questions when getting started with an application is, "What is the scope of this application?" How we make this determination colors how we see rules in the building of the application.

The issue of scope arises because someone (usually either the sponsor or the builder of the system) wants to know how big the application is (how complex the application is, how long it will take to write and test, how long it will take to install and train people).

First, we have to separate those aspects that deal primarily with the implementation and not the application (although these are worth entertaining because they often raise application-building issues that we may not have thought about). These are some of the questions we typically hear first:

• What geographic areas are we implementing this in? This concerns areas that might imply foreign language for the application, as well as the documentation and training, but it also concerns travel, more sources of requirements, and so on.

• What organizational units does this cover? Is the application only for the use of the departmental finance group, or will it be used by all departments that originate financial transactions?

• What functions are we implementing? Does the application include order entry but not invoicing? This functional discussion always seems clear in a verbal statement but then often explodes in detail as the implementation proceeds.

• What other systems do we need to replace? Often a new system is meant to replace an existing one; however, the existing systems almost never have the same scope boundaries as the one you are introducing, which causes your scope to expand.

• What other systems do we need to interface with? As we will discuss later, these system are imposing semantics on ours, just as ours is imposing semantics on theirs.

• What data are we going to manage? First we need to determine this at the gross level (e.g., the application will manage data about employees, other than their payroll-related data). Then we get into more and more variations on these (e.g., hourly, salaried, or both? Temporary employees? Contract employees?).

Role of Schema in Defining Application Scope

In a traditional system the schema provides a convenient way to establish a boundary around the scope of an application. In a rule-based system we must use an ontology to serve this purpose.