Hi, Kevin.
>
>What I am sensing here is a very fine line between what is a tier, and what isn't.
>
>Where do you draw the line?

Take a very simple example to see the pattern:

1. Data-tier
You have in the database several tables for customers, products, orders, etc, and one that stores a volume discount scale for each product.
I.e:
>100 units = 3%
>500 units = 5%
>1000 units = 10%

2. Middle-tier (bussines logic - can be a single tier or more)
You have an Order class that, between others, have a GetVolumeDiscountMethod() which gets as parameters the product code and the quantity, and returns the discount rate, accesing the needed tables or SPs.

3. UI-tier
You have a nice form in which the user enters the product code, the quantity, and then calls the Middle-tier to get the corresponding discount.

Basically, what you have to keep in mind is that the front end should have no more code than calls to the Middle-tier and some interface tricks to help the user do her work.

Also, one good tip for the middle-tier is that you should have to be able to instantiate the object from the command window (no matter if it is written in Delphi or Object-Cobol), and calling it's methods one by one, do everything with it. In our example, you need to be able to generate a new order just by calling the proper methods one by one.

Following this, one great possibility you have to automate middle-tier componentes is to write scripts (short prgs) to instantiate the class and process many transactions in a loop with different alternatives. This script can be used again and again, maybe with slight changes, after each change has been made to the component.

Hope this helps.

Best luck,