Architecting the Network
- By Wendy Chretien
When planning an institution’s technology infrastructure,
today’s campus IT architects face new challenges brought on
by users’ increasing reliance on converged networks.
THE WORD ‘ARCHITECT’ calls to mind a designer of
buildings. An architect’s job is to develop a structure to fit
the client’s needs, some of which are conflicting (or seem to
be). When it comes to designing your campus network, IT
infrastructure architects have a similar function. Like a building
architect, an IT architect must develop a well-considered
blueprint before the construction or remodeling starts. A
technology infrastructure-planning effort must take into
account organizational policies, user requirements, and
design goals such as uptime, resiliency, security, and data
privacy. Ultimately, the IT architect’s role is to develop a
vision for a campus infrastructure that can best meet the
organization’s current and foreseen needs, while keeping in
perspective real-world problems that could cloud that vision.
One of the primary challenges facing IT architects today
is converged networks. Now that users expect to view
video and listen to audio (including two-way conversations)
via the network, a whole new set of design goals must be
considered when “architecting” networks and the supporting
services for those networks. Not only are voice and
video joining the network, but critical systems such as video
surveillance (security cameras), intrusion detection, and
building automation/control—which in the past were isolated
systems—are increasingly “riding” on the local
area network. Now add to this the traffic of users
with mobile wireless devices.
While convergence benefits the institution by
reducing support for so many disparate systems,
it greatly adds to the scope of the IT
architect’s responsibilities. When one contemplates
all of the components of a campus infrastructure,
converged networks set a higher bar.
How Much Can You Tolerate?
Networks carrying “converged” traffic can’t tolerate much
in the way of delay, jitter, and downtime, not only because
critical systems are now part of the network, but also
because users expect more uptime, and demand highquality
audio/video. Specific hurdles for the IT architect/
designer include far greater needs for robustness, as well
as delivery guarantee requirements for synchronous traffic.
For example, traditional TDM (time division multiplex) voice
systems typically have experienced downtime of just minutes
per year. Substituting “data” servers for a traditional
voice switch changes that equation. More frequent software
upgrades alone make for more downtime—even if it
is planned—because to perform an upgrade, the active
system has to be temporarily taken out of use. Yet, users at
higher ed institutions now tend to access network services
at all hours, and expect those services to just “be
there.” An outage at 1 am isn’t as well tolerated as it once
was, for instance, and the campus security force doesn’t
take kindly to the security and video surveillance systems
being non-functional during that downtime, either.
Another part of the problem lies with IP and Ethernet,
which we take for granted as delivery mechanisms, but
which weren’t designed with synchronous traffic in mind.
Video, for example, presents a true test for networks, even
upping the ante from voice traffic, because while it also carries
delay-sensitive audio, it needs much greater bandwidth for video images. Most industry watchers expect video over
the network to grow exponentially over the next 12 to 18
months for all types of users, due primarily to the expanded
use of watching video via the internet (thanks to sites such
as YouTube.com). Colleges and universities often feel the
impact of these technologies first, because of the large percentage
of Gen Y users. These digital natives have difficulty
understanding why video traffic would ever be a problem;
after all, most of them have had broadband internet access
at home all their lives.
Then there’s the power issue—electrical, not political, that
is. Nearly all of the critical systems that used to be on separate
networks had their own backup power systems, usually
centralized uninterruptable power supply (UPS) systems
connected to a generator for longer-duration outages.
Now, however, both IP telephones and wireless access
points draw their electrical power from the Ethernet network.
The network switches to which these devices are
connected are much more distributed than were electronics
for legacy systems. So now the IT architect must take
on the role of, or at least understand how to communicate
well with, an electrical engineer.
Higher ed users now tend to access network services at
all hours, and expect those services to just 'be there.'
By the way, although not caused by convergence, electrical
power in the server/data center recently has also
become a much greater issue. This is primarily due to the
concentration of server processors in much smaller
amounts of space. These days, it’s possible to place up to
48 servers in one 7-foot-tall rack. (Think of all the electrical
power required in about 6 square feet of floor space!) This
poses yet another concern for IT architects—yes, their job
descriptions often include planning data centers.
And as if that weren’t enough, the cooling (air conditioning)
of data centers is also a rapidly growing concern,
because all those additional servers that are drawing more
power also generate more heat (just ask a physicist how this
works). Most network architects shudder at the idea that
they may have to add liquid cooling (similar to the way car
radiators work) to these very moisture-sensitive environments,
just to keep the contents from literally burning up.
Who Are You?
Another major dilemma in designing campus infrastructures
is security. It can no longer be “tacked on” after the
fact, but must be planned in as part of any new installation
or upgrade. One of the stumbling blocks for many institutions
has been the lack of a cost-effective means of assigning
and tracking the identity and authorizations (privileges/
access to information) of individual network users. There
are now two entire categories of software and services—
identity management and network access control—that
have been developed to help solve this problem. However,
these solutions are still very costly (at least to always cashstarved
higher ed organizations), requiring hundreds of
thousands of dollars to implement. To better understand
the security aspects of identity management that IT architects
now have to take into consideration in their planning
efforts, please see “The Case for Identity Management”
(CT August 2006) and “Trend Report: Identity Management”
(CT November 2005).
While campus infrastructure architects may begin to feel their
“building” is about to collapse, there are some measures that
can help shore up the foundation. First and foremost, remind
faculty, administrators, and staff members to get to know
their infrastructure architect. They can be an asset to the
architect by helping both to monitor the system and to gain
mindshare among those who develop budgets. Tell them to
remember that the campus infrastructure architects help
keep them in business!
Primary steps for the IT architect include assessing the current
situation, envisioning the ultimate goals (seek input from
your users—perhaps via an advisory group), and developing
a conceptual design. Each goal may require several initiatives.
Think of these as separate but related projects. Don’t
stint on time spent considering the potential ramifications of
proposed changes! Plan to actively manage change—including
educating users about it long before it occurs.
Think big, but implement incrementally. Pilot each initiative
with selected, interested users who are willing to provide
feedback. A successful pilot makes it much easier to obtain
approval and funding to move forward. Consider phasing
projects over multiple terms or years, to level out resource
needs (both budgetary and personnel) over time. It’s also
important to keep abreast of new developments and to
review and revise the plan regularly, to account for those
changes. But always keep in mind it isn’t necessary to
change the world overnight!