Factors that augment scalability include high-capacity backbones, switching technology, and modular designs. Additional considerations regarding scalability include the number of devices in the network, CPU utilization, and memory availability. For example, a network with one router is likely to be less scalable than a network with three, even if the three routers are substantially smaller than the one.

Adaptability

While similar to scalability, adaptability need not address an increase in the number of users. An adaptable network is one that can accommodate new services without significant changes to the existing structure, for example, adding voice services into the data network. Designers should consider Asynchronous Transfer Mode (ATM) where the potential for this adaptive step exists. For example, the possibility of adding voice service later would negate the use of Fiber Distributed Data Interface (FDDI) in the initial network design. Making this determination requires a certain amount of strategic planning, rather than a purely short-term tactical approach, and could therefore make a network more efficient and cost-effective. However, this section is not intended to advocate the use of any specific technology, but rather to show the benefits of an adaptable network.

Adaptability is one aspect of network design where using a matrix is beneficial. A matrix is a weighted set of criteria, designed to remove subjectivity from the decision-making process. Before reviewing vendors and products, a designer will typically work with managers, executives, and others to construct a matrix, assigning a weight to each item. While a complete matrix should include support and cost, a simple matrix could include only the adaptability issues. For example, the use of variable-length subnet masks might be weighted with a five (on a scale from one to five), while support for SNMP (Simple Network Management Protocol) v.3 might only garner a weight of one. Under these conditions, the matrix may point to a router that can support Enhanced Interior Gateway Routing Protocol (EIGRP) or Open Shortest Path First (OSPF) over one with a higher level of manageability, assuming that there is some mutual exclusivity.

Cost Control

Financial considerations often overshadow most other design goal elements. If costs were not an issue, everyone would purchase OC-192 SONET (Synchronous Optical Network) rings for their users with new equipment installed every three months. Clearly this is not the “real world.” The network designer’s role is often similar to that of a magician—both must frequently pull rabbits from their hats, but the network designer has the added responsibility of balancing dollars with functions. Therefore, the designer is confronted with the same cost constraints as all other components of a business. The fundamental issue at this point must be how to cope with this limitation without sacrificing usability. There are a number of methods used in modern network design to address this problem.

First, many companies have a network budget linked to the IT (Information Technology) department. This budget is typically associated with such basic, general services as baseline costs—wiring, general desktop connectivity, and corporate access to services such as the Internet. There is typically also a second source of funding for the IT department from project-related work. This work comes in the form of departmental requests for service beyond the scope of general service. It may involve setting up a workgroup server or lab environment, or it may involve finding a remote-access solution so that the executives can use a newer technology—DSL, for example. These projects are frequently paid for by the requesting department and not IT. In such cases, the requesting department may even cover costs that are not immediately related to its project. In the DSL project, for example, few companies would argue with the logic of setting up a larger scalable installation to address the needs of the few executives using the first generation of the service. It may be possible to have the requesting department fund all or part of a more-expensive piece of equipment to avoid a fork-lift upgrade in the future. (A fork-lift upgrade is one that requires the complete replacement of a large component—a chassis, for example.) Even if IT may need to fund a portion of the project, this is usually easier than funding the entire effort.

Second, a good network design will include factors that lend themselves to scalability and modularity. For example, long-range (strategic) needs may prompt the conversion of an entire network to new technologies, while immediate needs encompass only a small portion of such a project. By addressing tactical needs with an eye toward the strategic, the network designer can accomplish two worthy goals—a reduction in costs and the creation of an efficient network. In reality, the costs may not be reduced; in fact, the costs will likely rise. However, such costs will be amortized over a longer period of time, thus making each component appear cost effective. Such an undertaking is best approached by informing management of the schedule and long-range plan. Budgets frequently open up when a long-term plan is presented, and designers always want to avoid having a budget cut because a precedent was set by spending too little in the previous year.

The third approach to balancing network cost with usability is to buy cheaper components. A brief word of advice: avoid this approach at all costs. The net impact is that additional resources are required for support, which erodes any apparent savings.

The last approach is to use a billing model. Under this model, all purchases are pooled and then paid for by the other departments. This method can be quite limiting or quite fair, depending on its implementation. Such a model does away with the problem caused by concurrent usage but may leave the IT group with no budget of their own.

Concurrent Usage

Concurrent usage is an interesting concept in network design, as it ignores most other concerns. Imagine that the IT department has a single spare slot on its router and another department (Department A) wants a new subnet. One approach would be to have Department A purchase the router card and complete the project. However, this approach fails to consider the next request. A month later, another department (Department B) wants the same special deal on a new network segment, but, alas, there are no open slots. Department B would need to pay for a new router, power supplies, rack space, wiring, maintenance, and so forth. Department A may have paid $2,000 for their segment, but Department B will likely generate a bill for ten times that figure. Of course, Department C, making their request after Department B, would benefit from Department B’s generosity—their new segment would cost only $2,000, since there would now be a number of open slots.

Another solution is to fund all network projects from a separate ledger—no department owns the interface or equipment under this model. Unfortunately, this solution often leads to additional requests—it is always easier to spend someone else’s money. Bear in mind that this solution focuses only on the technical costs. If the designer is asked to spend 30 hours a week for six months on a single department’s effort, there will likely be additional expenses.