The Tracks of My Tiers - tiered architectures

Tiered architectures are all the rage these days. At first, everyone was talking about three-tier architectures, followed almost immediately by n-tier architectures. I wouldn't be entirely surprised to hear about an "infinity" plus one-tier architecture. When I recently completed and presented a multitier project, I was caught slightly off-guard by the number of misunderstanding, by both programmers and managers, about multitier architectures. I also discovered some serious disadvantages and spectacular advantages in delivering my largest multitier project to date.

A logical three-tier architecture is an architecture where the project is divided into three distinct layers: storage, business logic (or business objects) and presentation (or UI). Each layer has one and only one responsibility. The lowest level year -- storage -- is responsible only for the storing and retrieving of business objects. The middle layer -- business logic or business objects -- is responsible only for ensuring that all of the appropriate business rules, including relationship, needed for a particular business domain are enforce. Finally, the highest layer -- presentation -- handles presenting the business object in a fashion that is palatable to users.

Each layer ideally has no knowledge of higher layers: The storage layer should know nothing about business objects or UI, while the business objects should be clueless about the UI. Conversely, higher layers typically know only the layer directly below: The UI obviously must know about the business objects of effectively present them.

If the code for each logical tier can run on separate physical machines, the architecture is said to be a physical three-tier model. Many commercial Web sites follow this physical model, where the Web server is the middle-tier machine. When targeting Windows NT, a developer can also choose either DCOM or CORBA for creating physically tiered applications. However, you need not be planning a physically layered environment to benefit from a tiered design. In other words, when you hear the term multitier, you should ask the question "logical and/or physical?"

One of the unfortunate fallouts of RAD tools is they can easily intermix logical tiers. Few if any RAD tools give any sort of feedback if business logic and presentation logic are interwined. In fact, almost all the demos provided with RAD tools freely mix business logic and presentation logic. RAD tools are, however, keenly aware of the three-tier model, and all of the popular RAD tools provide programmers with effective tools to create multitier applications. Moral: Ignore the architecture of the sample code provided with RAD tools.

Multilayered architecture has a few major drawbacks. Until all the lower tiers are well-designed and some portions of the lower tiers are coded, it is difficult to scale up the number of developers on the project. While these underlying and invisible layers are being perfected, progress can seem very slow. Because the UI is completed last -- because it is based on business objects -- nothing demo-able exists until late in the development cycle. To combat these lulls, be sure to communicate progress effectively, or your project may be perceived as standing still. Also, don't take for granted that you or your team innately understands how to divide objects into business and presentation components. Challenge assumptions until you are sure that business objects aren't dependent on the existence of presentation objects -- other than error reporting and debugging messages, of course. Getting rid of layer interdependencies takes practice.

The payoffs of a multitier architecture were huge on our project. We spent many, many months concentrating on the storage layer and on an additional layer to translate business objects into standard relational entities. During this phase, no discernable progress was apparent outside of our team. When rubber finally met the road, however, we were able to translate a business object model directly into code in a matter of weeks. In another couple of weeks, we had built a relatively sophisticated UI on top of all the business objects. In fact, I've never seen a project go from nothing to complete in such a short time. As a bonus, the long-term maintenance costs should be much lower, because the code within each tier is highly cohesive. Spaghetti code is discouraged by the architecture itself. And although the layer that translates objects to relational entities is complicated, it is completely isolated in its own separate layer, unaffected by future changes to business logic.

Few decisions will have as much impact on your project's success as using a multitier approach. Even if you are working on a small project, try to consider how you would have divided various objects within a multitier model. Thinking in layers will have you cranking out better quality code in record time. Avoid layers, and you'll end up with the "tiers of a clown."

Eric Binary Anderson is a senior technical lead at Automatic Data Processing (San Ramon, Calif.) and has his own consulting business, Binary Solutions. Contact him at ebinary@aol.com.

COPYRIGHT 1998 Boucher Communications, Inc.
COPYRIGHT 2000 Gale Group