Architecting the Network

• By Wendy Chretien
• 03/01/07

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.

Power Struggle

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.

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).

Coping Mechanisms

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!