Not Just for Techno-Geeks:
The Managerial and Sociological Benefits of Multi-Tier Application Architectures
You’ve undoubtedly heard about
the technical advantages of multi-
tier application architectures.
Among these are better load bal-
ancing, greater agility in the face
of change, and the ability to sepa-
rate and replace legacy systems
over time in a controlled manner.
Numerous existing systems dem-
onstrate these benefits in a very
real and convincing manner.
Unfortunately, in the pursuit
of the technological benefits of
multi-tier architectures, organiza-
tions often overlook the socio-
logical and managerial benefits of
these architectures. The purpose
of this article is to describe these
benefits and demonstrate how a
few specific managerial practices
can maximize their impact.
BACKGROUND AND
ASSUMPTIONS
The basic structure of a multi-
tier application architecture is
presented in Figure 1. Each tier
is responsible for a specific set of
services. The architecture shown
in Figure 1 is admittedly biased
toward the development of
object-oriented systems, the ap-
© 1996 by Luke Hohmann. All rights
reserved.
plication technology with which
I am most familiar, but it can be
easily extended to other technolo-
gies. Such an architecture fol-
lows the basic principle for encap-
sulation that Edsger Dijkstra [1]
outlined in the late ’60s: tiers at
lower levels of abstraction
“know” as little as possible about
layers at higher levels of abstrac-
tion.
The heart and soul of a good
application are the domain
objects that comprise the busi-
ness rules and data. It is foolish
to try to slap a high-quality user
interface onto a contrived set of
objects. Similarly, there is little
to be gained from letting your ex-
isting legacy database systems
drive the internal structure of
your domain objects. A thor-
ough and complete analysis of
the problem domain, expressed
in the notation of your favorite
object-oriented methodology, is
your best chance for success in the
crafting of such an architecture.
This leads to the final point of
this brief review: effective man-
agement practices are absolutely
essential if you plan to create an
effective multi-tier application ar-
chitecture. Fortunately, as I’ll ex-
plain shortly, explicitly striving to
build such an architecture right
from the beginning makes follow-
ing such practices far easier.
Reprint
BENEFITS
Specific benefits of the multi-tier
architecture approach are as fol-
lows:
★ Common goals
★ Common semantic model
★ Parallel development
★ Behavioral discretion
★ Specialization of skills
★ Debugging
Common Goals
The first benefit is not derived
specifically from a multi-tier archi-
tecture but from the management
approach a project takes to realize
it. Specifically, by describing the
functionality of the system in
terms of use cases (an object-
oriented requirements and analysis
technique pioneered by Ivar Jacob-
son [2]), every developer works
from the same conceptual under-
standing of the goals of the system.
Of course, this does not mean
each developer works in the same
manner or even does the same
task. Your Web page designer is
likely to approach her job quite
1
differently from your query opti-
mization expert! The point is
that when these people do talk
with each other, they will have
your user’s most pressing needs at
the center of their conversation.
Common Semantic Model
In the development of your
multi-tier system, make certain
your team engages in a high-
quality analysis effort using your
favorite methodology. Such an
analysis will concentrate on the
objects within the domain and
the required functionality of the
system. The benefit (once again
due to management and not tech-
nology) is that each person on
the team knows the classes (or
entities) that are associated with
the system and can communicate
about them with a minimum of
ambiguity and equivocality.
event (solid line to the system)
and output event (dashed line
from the system) is described in
business terms. In other words,
we don’t know how the agent
obtained the name of the guest
and the guest’s length of stay.
We only know that the heart of
the reservation system — the do-
main logic — will provide a sys-
tem operation named confirmRe-
servation().
Once the input and output
events associated with a scenario
are known, the various groups as-
sociated with the system’s develop-
ment can begin their work in paral-
lel. For example, the GUI team
can begin to prototype the look
and feel of the agent screens, se-
cure in the knowledge that the in-
terface between its tier and the
rest of the application is stable.
Behavioral Discretion
Coupling refers to the degree of
interdependence among the com-
ponents in a system. Loosely
coupled systems are easier to un-
derstand, modify, and reuse. In
software, the ideal is for each
component (i.e., a module or
object) to interconnect with
other components only through
well-defined interfaces. One key

Parallel Development

The core of a well-defined multi-

tier architecture is a clear specifi-
cation of the interfaces between
layers. To illustrate, suppose you
were building a reservation man-
agement system for a hotel. One
use case would be “Guest check-
in,” which would describe the
process for checking a guest into
the hotel. From this use case, we
can derive one or more specific
uses of the system known as sce-
narios, each telling a specific
story. Scenarios, in turn, repre-
sent a sequence of input and out-
put events.
One scenario derived from
the use case “Guest check-in” is
shown in Figure 2. In it, a guest
has arrived and uses a credit card
to make a deposit. As you read
the scenario, note how each input Figure 1: Structure of a multi-tier application architecture

2 Reprint
technical advantage of multi-tier
architectures is that they explic-
itly encourage loose coupling be-
tween tiers.
In general, the teams that cre-
ate multi-tier architectures are
similarly loosely coupled. (This
can be predicted if you know
Conway’s law, which states: “Or-
ganizations that design systems
are constrained to produce
systems that are copies of the
communication structures of
these organizations.”) One key
sociological advantage of loosely
coupled teams is behavioral dis-
cretion, or the ability (and free-
dom) of a specific team to select
its most effective manner of work-
ing, free from external influence.
Thus the GUI design team can
use a different development proc-
ess from the business domain
team, and both of these teams are
Figure 2: The “Guest check-in” scenario
in turn insulated from the persist-
ent storage team.
The greatest sociological fail-
ing of the two-tier architecture is
the inability to achieve behavioral
discretion. Recall that in a two-
tier architecture, business logic be-
comes intertwined with the user
interface. Because of this, any
GUI development is inextricably
bound to the development of the
underlying business logic that
supports it. The problem with
this approach is that the processes
associated with building world-
class systems are different for
each layer of the architecture.
Specifically, a GUI team commit-
ted to building a high-quality
user interface must be allowed to
work independent of the other
tiers of the architecture.
Reprint
Specialization of Skills
Each tier requires a specific set of
skills to ensure that the tier is
properly engineered. The skills
and responsibilities of your GUI
designer are radically different
from the skills and responsibili-
ties of your DBA. Carefully engi-
neering your application architec-
ture enables you to organize
training plans and assignments
that build these skills in the most
effective manner possible.
Debugging
Debugging a complex applica-
tion is hard enough when the
business logic is entirely encapsu-
lated within domain objects.
When part or all of the business
logic is incorporated into forms
and other user interface (UI)
elements, debugging becomes
almost impossible: in order to
understand the behavior of the
system, the debugger has to un-
derstand the behavior of both
the relevant domain objects and
the UI object. But when attempt-
ing to understand the business-
related behavior of the UI ob-
ject, the debugger is distracted
by behavior that has nothing to
do with business logic but only
with the nuances of formatting
and displaying the information
on the user’s output device. The
end result is that the debugger
becomes confused about the
proper functioning of the system,
making incorrect assumptions —
and incorrect modifications.
3
MYTHICAL BENEFITS
Beware of the following mythical
benefits of multi-tier application
architectures:
★ Reuse/replacement of windows
★ Quick replacement of legacy
systems
Reuse/Replacement
of Windows
Building an effective graphical
user interface is far more than
simply slapping a few widgets on
a screen. It requires, among
other things, a careful analysis of
the tasks your user is trying to ac-
complish and a dedicated usabil-
ity testing effort. One key test-
ing activity is trying alternative
versions of the proposed interface
to determine which is most effec-
tive. (This does not have to take a
long time — paper and pencil are
the best tools in the early stages
of GUI development.)
All of this leads me to the first
mythical benefit: reuse/replace-
ment of windows. Taking the
time to engage in proper usabil-
ity engineering means you have
created windows that are custom-
ized to your user’s needs. You
won’t replace such windows until
there is a business reason to do
so. Furthermore, their custom-
ized and focused nature means
they are not suitable for reuse in
another application anytime
soon. (The same should not be
said of application management
logic, which can be reused.)
Does this mean you should
pitch the multi-tier approach?
Of course not! When your
highly usable system is intro-
duced into the market, you will
4 Reprint
enjoy rousing success. This will
lead to two requests for change:
the first in functionality and the
second for additional user inter-
faces (think “Web”). Both you
and your customer will be de-
lighted by the ease with which
you can make these changes —
all because you engineered a
multi-tier application architec-
ture right from the beginning.
Quick Replacement
of Legacy Systems
A multi-tier application architec-
ture does pave the way for replace-
ment of legacy systems (data-
bases, applications, and the like).
Such replacement, however, does
not happen overnight. It takes
time and careful planning. Ex-
pect to take at least 12–36 months
to eradicate your legacy systems
completely. Of course, before you
expend all that energy, take a step
back and review your business
goals. What is the business reason
for replacing your legacy sys-
tem(s)? Be especially careful of
techno-geek motivations mas-
querading as “business reasons.”
GETTING THERE FROM HERE
If you are new to creating multi-
tier application architectures, the
following four principles can help
you on your way:
★ All work is driven from the
domain.
★ Establish clear lines of respon-
sibility and authority.
★ Order of construction?
Domain first.
★ Respect architectural bounda-
ries when creating assignments.
All Work Is Driven
from the Domain
A clear understanding of the
problem domain and the use
cases/scenarios of your system is
essential for creating a multi-tier
application architecture. Yes, dif-
ferent layers work at different
rates, with different schedules
and different processes. How-
ever, all layers must share a small
core set of models in order to en-
sure effective interaction.
Establish Clear Lines of
Responsibility and Authority
Every team needs to know who
is ultimately responsible for the
creation of an outcome. This
means each team has a specific
developer responsible for that
outcome. It means each tier has
an individual responsible for that
tier. It means the system as a
whole has one individual respon-
sible for the system. And it
means each person given respon-
sibility for the tier is also given
the authority to carry out the
decisions necessary to preserve
architectural integrity.
Order of Construction?
Domain First
Successful projects rarely concen-
trate on building all layers of the
architecture at the same time. In-
stead they focus first on the do-
main, for it represents the heart
of the system. Get the domain
right, and it is far easier to get
the rest of the architecture right.
Get the domain wrong, and very
little can save the project.
After the domain has been
validated, projects should address
their high-risk items next. These
could be interconnections with
legacy systems, distributed tech-
nologies, and the like. I prefer
to address the user interface layer
immediately after the architec-
ture, as customers and users al-
ways want a good (i.e., usable)
user interface.
As described above, many
tiers can be addressed in parallel.
The key to this approach is to es-
tablish the architecture early,
make certain each tier is address-
ing similar functionality as per-
ceived by the user, and integrate
frequently. If you are going to at-
tempt parallel development,
make certain each tier agrees the
domain is the key driver of the
entire architecture. Changes to
the user interface should not moti-
vate changes in the domain. The
reverse is not true: changes in
the domain are likely to motivate
changes to the user interface.
chitectural boundaries should be
changed so as to respect them.
There are three exceptions to
this rule. First, the system archi-
tect has, by definition, a boundary-
spanning assignment. Second, the
quality assurance group is also
exempt by the nature of its work.
Third, reviews and inspections
should cross boundaries as a way of
ensuring correctness and increas-
ing knowledge of the system.
Note that both the general
issue of assigning tasks to people
and the exceptions I’ve itemized
are management issues. And this
demonstrates once again the under-
lying theme: effective management
practices are absolutely essential if
you intend to create an effective
multi-tier application architecture.
REFERENCES
1 Dijkstra, E.W. “The
Structure of the ‘THE’-
Multiprogramming Sys-
tem.” Communications of
the ACM, Vol. 11, no. 5
(May 1968), pp. 341–346.
Luke Hohmann is senior object tech-
nologist at ObjectSpace, Inc., a firm
specializing in object-oriented train-
ing, consulting, and development
tools. Mr. Hohmann is the author
of Journey of the Software Profes-
sional: A Sociology of Computer
Programming from Prentice Hall
(1996). Portions of this article are
adapted from his book.
Mr. Hohmann can be reached
at ObjectSpace, Inc., 14881 Quo-
rum Drive, Suite 400, Dallas, TX
75024 (972/663-9039; fax
972/663-9099; Internet:
lhohmann@objectspace.com;
WWW: http://mem-
bers.aol.com/lhohmann). ★

Respect Architectural 2 Jacobson, I., M. Christer-

Boundaries When Creating son, P. Jonsson, and G.
Assignments Overgaard. Object-Oriented
Software Engineering: A Use
There are very few developers Case–Driven Approach.
who can handle tasks spanning Reading, MA: Addison-
multiple layers of the architec- Wesley, 1992.
ture. Review each task with re-
spect to architectural boundaries.
Any assignment that crosses ar-

This article originally appeared in Vol. 9, no. 11 of AMERICAN PROGRAMMER®. Copyright © 1997 by Cutter Information Corp.
All rights reserved. Unauthorized reproduction, including photocopying, is illegal.
The monthly AMERICAN PROGRAMMER® Newsletter is edited by Ed Yourdon and published by:

CUTTER INFORMATION CORP.

37 Broadway, Arlington, MA 02174, USA. Phone: (617) 648-8702 or (800) 964-8702,
Fax: (617) 648-1950, E-mail: lovering@cutter.com

Reprint 5