Chapter 14. Documenting Your Network Design

This chapter starts by providing advice on responding to a customer’s request for proposal (RFP), and concludes with information on writing a network design document when no RFP exists. The section “Contents of a Network Design Document” provides an outline of a typical design document and specifies the topics that should be included in each part of the document. The section serves as a summary for Top-Down Network Design because it references each of the major steps of the top-down design methodology presented in this book.

At this point in the design process, you should have a comprehensive design that is based on an analysis of your customer’s business and technical goals, and includes both logical and physical components that have been tested and optimized. The next step in the process is to write a design document.

A design document describes your customer’s requirements and explains how your design meets those requirements. It also documents the existing network, the logical and physical design, and the budget and expenses associated with the project.

It is also important that a design document contain plans for implementing the network, measuring the success of the implementation, and evolving the network design as new application requirements arise. The network designer’s job is never complete. The process of analyzing requirements and developing design solutions begins again as soon as a design is implemented. Figure 14-1 shows the cyclical nature of the top-down network design process.

As mentioned in earlier chapters, in addition to being cyclical, network design is also iterative. Some steps take place during multiple phases of a design. Testing occurs during the design-validation phase and also during implementation. Optimization occurs while finalizing the design and also after implementation during the network-monitoring phase. Documentation is an ongoing effort. Documentation that is completed before the implementation stage can facilitate the approval process for a design and help expedite the rollout of new technologies and applications.

Figure 14-1 Network Design and Implementation Cycle

Responding to a Customer’s Request for Proposal

A Request for Proposal (RFP) lists a customer’s design requirements and the types of solutions a network design must include. Organizations send RFPs to vendors and design consultants and use the responses they receive to weed out suppliers that cannot meet requirements. RFP responses help organizations compare competing designs, product capabilities, pricing, and service and support alternatives.

Every RFP is different, but typically an RFP includes some or all of the following topics:

• Business goals for the project

• Scope of the project

• Information on the existing network and applications

• Information on new applications

• Technical requirements, including scalability, availability, network performance, security, manageability, usability, adaptability, and affordability

• Warranty requirements for products

• Environmental or architectural constraints that could affect implementation

• Training and support requirements

• Preliminary schedule with milestones and deliverables

• Legal contractual terms and conditions

Some organizations specify the required format for the RFP response. If this is the case, your initial design document should follow the customer’s prescribed format and structure precisely. Organizations that specify a format might refuse to read responses that do not follow the requested format. In some cases, the customer might request a follow-up document in which you can provide more detailed information on your logical and physical network design.

Some RFPs are in the form of a questionnaire. In this case, the questions should drive the proposal’s organization. Embellishments that focus on key requirements and the selling points of your design can sometimes be added, unless the RFP specifically states that they should not be added.

Although every organization handles RFPs slightly differently, typically an RFP states that the response must include some or all of the following topics:

• A network topology for the new design

• Information on the protocols, technologies, and products that form the design

• An implementation plan

• A training plan

• Support and service information

• Prices and payment options

• Qualifications of the responding vendor or supplier

• Recommendations from other customers for whom the supplier has provided a solution

• Legal contractual terms and conditions

Despite the fact that a response to an RFP must stay within the guidelines specified by the customer, you should nonetheless use ingenuity to ensure that your response highlights the benefits of your design. Based on an analysis of your customer’s business and technical goals, and the flow and characteristics of network traffic (as covered in Part I, “Identifying Your Customer’s Needs and Goals”), write your response so that the reader can easily recognize that the design satisfies critical selection criteria.

When writing the response, be sure to consider the competition. Try to predict what other vendors or design consultants might propose so that you can call attention to the aspects of your solution that are likely to be superior to competing designs. In addition, pay attention to your customer’s business style. Chapter 1, “Analyzing Business Goals and Constraints,” covered the importance of understanding your customer’s biases and any office politics or project history that could affect the perception of your design.

Contents of a Network Design Document

When your design document does not have to follow a format dictated by an RFP, or when a customer requests a follow-up document to a basic RFP response, you should write a design document that fully describes your network design. The document should include the logical and physical components of the design, information on technologies and devices, and a proposal for implementing the design. The following sections describe the topics that should be included in a comprehensive design document.

Executive Summary

A comprehensive design document can be many pages in length. For this reason, it is essential that you include at the beginning of the document an Executive Summary that succinctly states the major points of the document. The Executive Summary should be no more than one page and should be targeted at the managers and key project participants who will decide whether to accept your design.

Although the Executive Summary can include some technical information, it should not provide technical details. The goal of the summary is to sell the decision makers on the business benefits of your design. Technical information should be summarized and organized in order of the customer’s highest-priority objectives for the design project.

Project Goal

This section should state the primary goal for the network design project. The goal should be business-oriented and related to an overall objective that the organization has to become more successful in its core business. The Project Goal section should be no more than one paragraph; it often can be written as a single sentence. Writing it carefully will give you a chance to make it obvious to the decision makers reading the document that you understand the primary purpose and importance of the network design project.

An example of a Project Goal section that was written for an actual design customer follows:

The goal of this project is to develop a wide-area network (WAN) that will support new high-bandwidth and low-delay multimedia applications. The new applications are key to the successful implementation of new training programs for the sales force. The new WAN should facilitate the goal of increasing sales in the United States by 50 percent in the next fiscal year.

Project Scope

The Project Scope section provides information on the extent of the project, including a summary of the departments and networks that will be affected by the project. The Project Scope section specifies whether the project is for a new network or modifications to an existing network. It indicates whether the design is for a single network segment, a set of LANs, a building or campus network, a set of WAN or remote-access networks, or possibly the whole enterprise network.

An example of a Project Scope section follows:

The scope of this project is to update the existing WAN that connects all major sales offices in the United States to corporate headquarters. The new WAN will be accessed by sales, marketing, and training employees. It is beyond the scope of this project to update any LANs that these employees use. It is also beyond the scope of this project to update the networks in satellite and telecommuter offices.

The scope of the project might intentionally not cover some matters. For example, fixing performance problems with a particular application might be intentionally beyond the scope of the project. By stating up front the assumptions you made about the scope of the project, you can avoid any perception that your solution inadvertently fails to address certain concerns.

Design Requirements

Whereas the Project Goal section is generally short, the Design Requirements section is your opportunity to list all the major business and technical requirements for the network design. The Design Requirements section should list the goals in priority order. Critical goals should be marked as such. To review some examples of design requirements, see the case studies in Chapter 10, “Selecting Technologies and Devices for Campus Networks,” and Chapter 11, “Selecting Technologies and Devices for Enterprise Networks.”

Business Goals

Business goals explain the role the network design will play in helping an organization provide better products and services to its customers. Executives who read the design document will be more likely to accept the network design if they recognize from the Business Goals section that the network designer understands the organization’s business mission.

Many network designers have a hard time writing the Business Goals section because they are more interested in technical goals. However, it is critical that you focus your network design document on the ability of your design to help a customer solve real-world business problems.

As discussed in Chapter 1, most businesses embark on a network design project to help them increase revenue, reduce operational costs and inefficiencies, and improve corporate communications. Other typical goals include building partnerships with other companies and expanding into worldwide markets. At this point in the network design process, you should have a comprehensive understanding of your customer’s business goals and be able to list them in the design document in priority order.

Technical Goals

The Technical Goals section documents the following goals discussed in Chapter 2, “Analyzing Technical Goals and Tradeoffs”:

• Scalability: How much growth a network design must support.

• Availability: The amount of time a network is available to users, often expressed as a percent uptime, or as a mean time between failure (MTBF) and mean time to repair (MTTR). Availability documentation can also include any information gathered on the monetary cost associated with network downtime.

• Network performance: The customer’s criteria for accepting the service level of a network, including its throughput, accuracy, efficiency, delay, delay variation (jitter), and response time. Specific throughput requirements for internetworking devices, in packets per second (pps), can also be stated. Specific throughput requirements for applications should be included in the Network Applications section.

• Security: General and specific goals for protecting the organization’s capability to conduct business without interference from intruders inappropriately accessing or damaging equipment, data, or operations. This section should also list the various security risks that the customer identified during the requirements-analysis phase of the design project.

• Manageability: General and specific goals for performance, fault, configuration, security, and accounting management.

• Usability: The ease with which network users can access the network and its services. This section can include information on goals for simplifying user tasks related to network addressing, naming, and resource discovery.

• Adaptability: The ease with which a network design and implementation can adapt to network faults, changing traffic patterns, additional business or technical requirements, new business practices, and other changes.

• Affordability: General information on the importance of containing the costs associated with purchasing and operating network equipment and services. Specific budget information should be included in the Project Budget section.

The Technical Goals section should also describe any tradeoffs the customer is willing to make. For example, some customers might indicate that affordability can be sacrificed to meet strict availability goals, or usability can be sacrificed to meet strict security goals. As discussed in Chapter 2, including a chart that categorizes the comparative weights of goals can help the readers of a network design document understand some of the design choices that were made.

User Communities and Data Stores

This section lists major user communities, including their sizes, locations, and the principal applications they use. You can use Table 4-1, “User Communities,” to summarize information about user communities. This section should also list major data stores (servers and hosts) and their locations. Use Table 4-2, “Data Stores,” to summarize information about data stores.

Network Applications

The Network Applications section lists and characterizes the new and existing network applications. Information about applications can be summarized in the “Network Applications Technical Requirements” chart shown in Table 2-2, and in the “Network Applications Traffic Characteristics” chart shown in Table 4-4. If you want, you can merge these two tables so that there is just one row for each application.

The case studies in Chapters 10 and 11 provide good examples of the information regarding network applications, user communities, and data stores that should be included in a design document.

Current State of the Network

This section briefly describes the structure and performance of the existing network. It should include a high-level network map that identifies the location of major internetworking devices, data processing and storage systems, and network segments. The high-level map should document the names and addresses of major devices and segments and indicate the types and lengths of principal network segments. For large internetworks, two or three high-level maps might be necessary. Detailed maps, however, should be placed in the Appendix rather than in this section.

The network maps should include logical and physical components (for example, the location and reach of any virtual private networks [VPN], virtual LANs [VLAN], firewall segments, server clusters, and so on). The maps should also characterize the logical topology of the internetwork and the networks that make up the internetwork. Network drawings, or text associated with drawings, should indicate whether networks are hierarchical or flat, structured or unstructured, layered or not, and so on. They should also indicate network geometry (for example, star, ring, bus, hub and spoke, or mesh). The documentation of the current state of the network also briefly describes any strategies or standards your customer uses for network addressing and device naming. If the customer uses address-summarization techniques, for example, this should be indicated in the design document.

A portion of the Current State of the Network section of the network design document should be dedicated to an analysis of the health and performance of the present network. See Chapter 3, “Characterizing the Existing Internetwork,” for more information on the documentation you should gather about the existing network.

Detailed health and performance reports can be placed in the Appendix of the design document to avoid overwhelming the reader with too much information at this stage. It is important that the reader be able to quickly reach the Logical Design and Physical Design sections of the document, because those sections contain the essence of your design proposal.

Logical Design

The Logical Design section documents the following aspects of your network design:

• The network topology, including one or more drawings that illustrate the logical architecture of the new network.

• A model for addressing network segments and devices.

• A model for naming network devices.

• A list of the switching and routing protocols that have been selected to implement the design, and any specific implementation recommendations associated with those protocols.

• Recommended security mechanisms and products, including a summary of security policies and procedures. (If a detailed security plan was developed as part of the network design, it can be submitted as an addendum to the design document.)

• Recommended network management architectures, processes, and products.

• Design rationale, outlining why various choices were made, in light of the customer’s goals and the current state of the network.

Physical Design

The Physical Design section describes the features and recommended uses for the technologies and devices you selected to implement the design. It can include information for campus networks (as discussed in Chapter 10) and remote-access and WANs (as discussed in Chapter 11). This section can also include information about any service providers selected.

If appropriate, the Physical Design section should include information on the pricing for network devices and services. Sometimes pricing is negotiable and is not appropriate to include in the design document. Pricing can also be a distraction, taking away focus from the quality of the design solution. In many cases, however, customers expect to see product and service pricing in the design document.

The Physical Design section should also contain information on the availability of products. If your design recommends products that are not yet shipping, you should document a predicted ship date, as provided by the product vendor. If you have information about the lifecycle of a product (for example, when the vendor will obsolete it), include that also.

Results of Network Design Testing

This section describes the results of the testing that you did to verify your network design. It is one of the most important portions of the design document because it gives you a chance to prove to your customer that your design will likely meet requirements for performance, security, usability, manageability, and so on. You can describe any prototype or pilot systems that you implemented and the following testing components:

• Test objectives

• Test acceptance criteria

• Testing tools

• Test scripts

• Results and observations

In the Results and Observations segment, be sure to include any optimization techniques you recommend be applied to the design to ensure that it meets requirements. Based on the results of your testing, you might recommend mechanisms for minimizing broadcast and multicast traffic, advanced features for meeting quality of service (QoS) requirements, and sophisticated router switching and queuing services. See Chapter 13, “Optimizing Your Network Design,” for more information on optimization techniques.

Implementation Plan

The Implementation Plan includes your recommendations for deploying the network design. The level of detail in this section varies from project to project, and depends on your relationship to your customer.

If you are a member of an Information Systems (IS) department that is responsible for the design and implementation of the new network, this section should be quite detailed. If you are a sales engineer for a vendor of networking products, on the other hand, your role is probably to recommend solutions but not implement them, so this section should be short. (You should avoid appearing as if you are telling your customers how to do their jobs.)

The following topics are suitable for the Implementation Plan section:

• A project schedule.

• Plans with vendors or service providers for the installation of links, equipment, or services.

• Plans or recommendations for outsourcing the implementation or management of the network.

• A plan for communicating the design to end users, network administrators, and management. This section can also explain how implementation progress will be communicated (possibly via regularly scheduled status meetings or email messages).

• A training plan for network administrators and end users.

• A plan for measuring the effectiveness of the design after it has been implemented.

• A list of known risks that could delay the project.

• A fallback plan if the network implementation fails.

• A plan for evolving the network design as new application requirements and goals arise.

Project Schedule

The Implementation Plan should include a project schedule or timeline. The level of detail you include in a schedule depends on your role on the project. In general, the schedule should at least include the dates and deliverables for major milestones. Table 14-1 shows an example of a high-level schedule that was developed by a sales engineer for an actual customer.

Table 14-1 High-Level Schedule Developed for a Network Design Customer

Project Budget

The Project Budget section should document the funds the customer has available for equipment purchases, maintenance and support agreements, service contracts, software licenses, training, and staffing. The budget can also include consulting fees and outsourcing expenses.

Return on Investment

In many cases the best way to sell a customer on a new network design is to convince the customer that the design will pay for itself in a reasonable time period. The network design document can include a return-on-investment (ROI) analysis that explains how quickly the design or new equipment will pay for itself.

Following is an example of an ROI that was completed for an actual customer, Customer ABC. The goal of this ROI analysis was to prove to the customer that the recommended WAN switching equipment will pay for itself quickly because it will enable the customer to decrease the number of required T1 lines, and thus reduce the cost of leasing those lines from the local phone company.

Design Document Appendix

Most design documents include one or more appendixes that present supplemental information about the design and implementation. Supplemental information can include detailed topology maps, device configurations, network addressing and naming details, and comprehensive results from the testing of the network design.

You can also include business information such as a list of contacts at the customer’s site and in your organization, including email addresses, phone numbers, beeper numbers, and physical addresses. Information on where to ship equipment and any special shipping requirements or procedures is a useful addition in some cases.

If necessary, the Appendix can include exact information on pricing and payment options. Sometimes copies of purchase orders are included. The Appendix can also contain legal and contractual terms and conditions, and nondisclosure agreements.

Some design documents include information about the company presenting the design proposal, including pages from annual reports, product catalogs, or recent press releases favorable to the company. The goal of this type of information is to make sure the reader understands that the company is qualified to develop and implement the proposed network design. If appropriate, this section can include recommendations from other customers for whom the company has provided a solution.

Summary

When a customer provides an RFP, your network design proposal should follow the format prescribed in the RFP. When not bound by an RFP, or when a customer expects comprehensive design documentation, you should develop a document that describes requirements, the existing network, the logical and physical design, and the budget and expenses associated with implementing the design.

The design document should include an executive summary and a primary project goal. It should also document the network topology, any addressing and naming schemes you designed, security recommendations, and information about protocols, technologies, and products. Results of your network design testing can be included to convince your customer of the validity of your design.

It is also important that a design document contain a plan for implementing the network and measuring the success of the implementation. The plan should recommend network management and monitoring processes that can confirm that the implementation meets requirements for performance, availability, security, manageability, usability, and affordability.

The plan should also mention a process for evolving the network design as new application requirements arise. Enterprise networks continue to change at a rapid rate as organizations increasingly rely on their networks to help them achieve critical business goals. A network design must keep pace with new applications that let organizations increase revenue, reduce operational costs, and communicate more effectively with customers, business partners, and employees. Organizations that have not yet implemented modern applications such as collaboration applications, IP telephony, unified communications and messaging, and videoconferencing will likely want to deploy these or other new applications in the near future.

Vendors and standards bodies rapidly introduce new products and protocols to keep up with changing requirements. By following a systematic design process, you can keep pace with the evolving networking industry. With a focus on your customer’s business and technical goals, you can develop solutions that accommodate changing technologies and requirements.

Many inexperienced network designers make the mistake of immediately jumping to the design step of selecting vendors and products. Top-Down Network Design has presented the benefits of first analyzing requirements and traffic flows, and then developing a logical design, followed by a physical design that specifies products and technologies. Using this approach will strengthen your competency as a network designer and promote the success of your network design customers.

Review Questions

1. In what ways is network design an iterative process? Why does the need for network documentation arise in many phases of a network design project?
2. When responding to an RFP, why is it important to pay attention to the business style of the organization that is requesting the proposal?
3. How does the Project Goal section of a network design document differ from the Design Requirements section? Why is it important to have both sections?
4. What items often appear in the Appendix of a network design document?

Design Scenario

In Chapters 11 and 13, you learned about the network design project for Klamath Paper Products. Develop a high-level project schedule for Klamath’s design project. Include the dates of completion for major design, testing, and implementation tasks. You may not know the exact nature of all the tasks or how long they will take, but based on what you have learned in this book, try to include realistic tasks and completion dates.