Analyzing Business Goals and Constraints of Network Design

This chapter covers typical network design business goals and constraints and talks about the top-down process for gathering information on goals, and the importance of using systematic methods for network design.

This chapter serves as an introduction to the rest of the book by describing top-down network design. The first section explains how to use a systematic, top-down process when designing computer networks for your customers. Depending on your job, your customers might be other departments within your company, those to whom you are trying to sell products, or clients of your consulting business.

After describing the methodology, this chapter focuses on the first step in top-down network design: analyzing your customer's business goals. Business goals include the capability to run network applications to meet corporate business objectives, and the need to work within business constraints, such as budgets, limited networking personnel, and tight timeframes.

This chapter also covers an important business constraint that some people call the eighth layer of the Open Systems Interconnection (OSI) reference model: workplace politics. To ensure the success of your network design project, you should gain an understanding of any corporate politics and policies at your customer's site that could affect your project.

The chapter concludes with a checklist to help you determine if you have addressed the business issues in a network design project.

Using a Top-Down Network Design Methodology

According to Albert Einstein:

The world we've made as a result of the level of thinking we have done thus far creates problems that we cannot solve at the same level at which we created them.

To paraphrase Einstein, networking professionals have the ability to create networks that are so complex that when problems arise they can't be solved using the same sort of thinking that was used to create the networks. Add to this the fact that each upgrade, patch, and modification to a network can also be created using complex and sometimes convoluted thinking, and you realize that the result is networks that are hard to understand and troubleshoot. The networks created with this complexity often don't perform as well as expected, don't scale as the need for growth arises (as it almost always does), and don't match a customer's requirements. A solution to this problem is to use a streamlined, systematic methodology in which the network or upgrade is designed in a top-down fashion.

Many network design tools and methodologies in use today resemble the "connect-the-dots" game that some of us played as children. These tools let you place internetworking devices on a palette and connect them with local-area network (LAN) or wide-area network (WAN) media. The problem with this methodology is that it skips the steps of analyzing a customer's requirements and selecting devices and media based on those requirements.

Good network design must recognize that a customer's requirements embody many business and technical goals including requirements for availability, scalability, affordability, security, and manageability. Many customers also want to specify a required level of network performance, often called a service level. To meet these needs, difficult network design choices and tradeoffs must be made when designing the logical network before any physical devices or media are selected.

When a customer expects a quick response to a network design request, a bottom-up (connect-the-dots) network design methodology can be used, if the customer's applications and goals are well known. However, network designers often think they understand a customer's applications and requirements only to discover, after a network is installed, that they did not capture the customer's most important needs. Unexpected scalability and performance problems appear as the number of network users increases. These problems can be avoided if the network designer uses top-down methods that perform requirements analysis before technology selection.

Top-down network design is a methodology for designing networks that begins at the upper layers of the OSI reference model before moving to the lower layers. It focuses on applications, sessions, and data transport before the selection of routers, switches, and media that operate at the lower layers.

The top-down network design process includes exploring divisional and group structures to find the people for whom the network will provide services and from whom you should get valuable information to make the design succeed.

Top-down network design is also iterative. To avoid getting bogged down in details too quickly, it is important to first get an overall view of a customer's requirements. Later, more detail can be gathered on protocol behavior, scalability requirements, technology preferences, and so on. Top-down network design recognizes that the logical model and the physical design may change as more information is gathered.

Because top-down methodology is iterative, some topics are covered more than once in this book. For example, this chapter discusses network applications. Network applications are discussed again in Chapter 4, "Characterizing Network Traffic," which covers network traffic caused by application- and protocol-usage patterns. A top-down approach lets a network designer get "the big picture" first and then spiral downward into detailed technical requirements and specifications.

Using a Structured Network Design Process

Top-down network design is a discipline that grew out of the success of structured software programming and structured systems analysis. The main goal of structured systems analysis is to more accurately represent users' needs, which are unfortunately often ignored or misrepresented. Another goal is to make the project manageable by dividing it into modules that can be more easily maintained and changed.

Structured systems analysis has the following characteristics:

• The system is designed in a top-down sequence.

• During the design project, several techniques and models can be used to characterize the existing system, new user requirements, and a structure for the future system.

• A focus is placed on understanding data flow, data types, and processes that access or change the data.

• A focus is placed on understanding the location and needs of user communities that access or change data and processes.

• A logical model is developed before the physical model. The logical model represents the basic building blocks, divided by function, and the structure of the system. The physical model represents devices and specific technologies and implementations.

With large network design projects, modularity is essential. The design should be split functionally to make the project more manageable. For example, the functions carried out in campus LANs can be analyzed separately from the functions carried out in remote-access networks, virtual private networks (VPNs), and WANs.

Cisco Systems recommends a modular approach with its three-layer hierarchical model. This model divides networks into core, distribution, and access layers. Cisco's Secure Architecture for Enterprises (SAFE) and Enterprise Composite Network Model (ECNM), which are discussed in Part II of this book, "Logical Network Design," are also modular approaches to network design.

With a structured approach to network design, each module is designed separately, yet in relation to other modules. All the modules are designed using a top-down approach that focuses on requirements, applications, and a logical structure before the selection of physical devices and products to implement the design.

Systems Development Life Cycles

Systems analysis students are familiar with the concept that typical systems are developed and continue to exist over a period of time, often called a systems development life cycle. Many systems analysis books use the acronym SDLC to refer to the life cycle, which may sound strange to networking students who know SDLC as Synchronous Data Link Control, a bit-oriented, full-duplex protocol used on synchronous serial links, often found in a legacy Systems Network Architecture (SNA) environment. Nevertheless, it's important to realize that most systems, including network systems, follow a cyclical set of phases, where the system is planned, created, tested, and optimized.

Feedback from the users of the system causes the system to then be re-created or modified, tested, and optimized again. New requirements arise as the network opens the door to new uses. As people get used to the new network and take advantage of the services it offers, they soon take it for granted and expect it to do more.

In this book, network design is divided into four major phases that are carried out in a cyclical fashion:

• Analyze requirements. In this phase, the network analyst interviews users and technical personnel to gain an understanding of the business and technical goals for a new or enhanced system. The task of characterizing the existing network, including the logical and physical topology and network performance, follows. The last step in this phase is to analyze current and future network traffic, including traffic flow and load, protocol behavior, and quality of service (QoS) requirements.

• Develop the logical design. This phase deals with a logical topology for the new or enhanced network, network layer addressing, naming, and switching and routing protocols. Logical design also includes security planning, network management design, and the initial investigation into which service providers can meet WAN and remote access requirements.

• Develop the physical design. During the physical design phase, specific technologies and products to realize the logical design are selected. Also, the investigation into service providers, which began during the logical design phase, must be completed during this phase.

• Test, optimize, and document the design. The final steps in top-down network design are to write and implement a test plan, build a prototype or pilot, optimize the network design, and document your work with a network design proposal.

These major phases of network design repeat themselves as user feedback and network monitoring suggest enhancements or the need for new applications. Figure 1-1 shows the network design and implementation cycle.

Figure 1-1 Network Design and Implementation Cycle

The Plan Design Implement Operate Optimize (PDIOO) Network Life Cycle

Cisco Systems teaches the Plan Design Implement Operate Optimize (PDIOO) set of phases for the life cycle of a network. It doesn't matter exactly which life cycle you use, as long as you realize that network design should be accomplished in a structured, planned, modular fashion, and that feedback from the users of the operational network should be fed back into new network projects to enhance or redesign the network. Learning the Cisco steps is important if you are studying for a Cisco design certification. For that reason, the steps are listed here:

• Plan. Network requirements are identified in this phase. This phase also includes an analysis of areas where the network will be installed and an identification of users who will require network services.

• Design. In this phase, the network designers accomplish the bulk of the logical and physical design, according to requirements gathered during the plan phase.

• Implement. After the design has been approved, implementation begins. The network is built according to the design specifications. Implementation also serves to verify the design.

• Operate. Operation is the final test of the effectiveness of the design. The network is monitored during this phase for performance problems and any faults, to provide input into the optimize phase of the network life cycle.

• Optimize. The optimize phase is based on proactive network management which identifies and resolves problems before network disruptions arise. The optimize phase may lead to a network redesign if too many problems arise due to design errors or as network performance degrades over time as actual use and capabilities diverge. Redesign may also be required when requirements change significantly.

• Retire. When the network, or a part of the network, is out-of-date, it may be taken out of production. Although Retire is not incorporated into the name of the life cycle (PDIOO), it is nonetheless an important phase.

Figure 1-2 shows a graphical representation of the Cisco PDIOO network life cycle.

Figure 1-2 PDIOO Network Life Cycle

Analyzing Business Goals

Understanding your customer's business goals and constraints is a critical aspect of network design. Armed with a thorough analysis of your customer's business objectives, you can propose a network design that will meet with your customer's approval.

It is tempting to overlook the step of analyzing business goals, because analyzing such technical goals as capacity, performance, security, and so on is more interesting to many network engineers. Analyzing technical goals is covered in the next chapter. In this chapter, you will learn the importance of analyzing business goals, and you will pick up some techniques for matching a network design proposal to a customer's business objectives.

Working with Your Client

Before meeting with your customer to discuss business goals for the network design project, it is a good idea to research your client's business. Find out what industry the client is in. Learn something about the client's market, suppliers, products, services, and competitive advantages. With the knowledge of your customer's business and its external relations, you can position technologies and products to help strengthen the customer's status in the customer's own industry.

In your first meeting with your customers, ask them to explain the organizational structure of the company. Your final internetwork design will probably reflect the corporate structure, so it is a good idea to gain an understanding of how the company is structured in departments, lines of business, vendors, partners, and field or remote offices. Understanding the corporate structure will help you locate major user communities and characterize traffic flow. Characterizing traffic flow is covered in Chapter 4.

Ask your customer to state an overall goal of the network design project. Explain that you want a short, business-oriented statement that highlights the business purpose of the new network. Why is the customer embarking on this new network design project? For what will the new network be used? How will the new network help the customer be more successful in the customer's business?

After discussing the overall business goals of the network design project, ask your customer to help you understand the customer's criteria for success. What goals must be met for the customer to be satisfied? Sometimes success is based on operational savings because the new network allows employees to be more productive. Sometimes success is based on the ability to increase revenue or build partnerships with other companies. Make sure you know up-front how "success" is defined by executives, managers, end users, network engineers, and any other stakeholders. Also, determine whether the customer's definition of success will change as yearly fiscal goals change.

In addition to determining the criteria for success, you should ascertain the consequences of failure:

• What will happen if the network design project fails or if the network, once installed, does not perform to specification?

• How visible is the project to upper-level management?

• Will the success (or possible failure) of the project be visible to executives?

• To what extent could unforeseen behavior of the new network disrupt business operations? In general, gather enough information to feel comfortable that you understand the extent and visibility of the network design project.

You should try to get an overall view of whether the new network is critical to the business's mission. Investigate the ramifications of the network failing or experiencing problems. Chapter 2, "Analyzing Technical Goals and Tradeoffs," discusses the details of performance and reliability analysis, but at this point in the design process, you should start addressing these issues. (Remember that top-down network design is iterative. Many network design requirements are addressed more than once.)

Changes in Enterprise Networks

Enterprise networks at many corporations have been undergoing major changes. The value of making vast amounts of data available to employees, customers, and business partners has been recognized. Corporate employees, field employees, contract employees, and telecommuters need access to sales, marketing, engineering, and financial data, regardless of whether the data is stored on centralized or distributed servers or mainframes. Suppliers, vendors, and customers also need access to many types of data.

A network that is used by only internal users is no longer the norm at many companies. Companies are seeking ways to build networks that more closely resemble modern organizations. Many modern organizations are based on an open, collaborative environment that provides access to information and services for many different constituents, including customers, prospective customers, vendors, suppliers, and employees. Cisco Systems uses the term network organizational model to define a network model that mirrors modern organizations that have expanded from traditional boundaries to include access for various constituents.

To remain competitive, companies need ways to reduce product development time and take advantage of just-in-time manufacturing principles. A lot of companies achieve these goals by partnering with suppliers and by fostering an online, interactive relationship with their suppliers. An example is automobile manufacturing. Instead of producing every automobile component in-house, many manufacturers contract with partners who specialize in specific components and technologies. For example, one partner might produce the engine while another produces the body. If all the partners can access data and services on the manufacturer's network, production costs are reduced, just-in-time manufacturing can be accomplished, and it is easier to plan around component shortages. The ability to share information saves time and money for the automobile manufacturer and for its partners.

A network designer must consider requirements to extend the network to outside users very carefully. For security reasons, external access should not mean full network access. Using a modular approach to network design is important here so that there is a clear boundary between the enterprise's private networks and the portions of the internetwork that partners can access.

Networks Must Make Business Sense

With the economic downturn that followed the Internet boom, there is an increased need to choose technologies that solve business problems. Although many companies made "technology for technology's sake" choices during the boom, this is no longer the case. Business leaders are more involved in Information Technology (IT) decisions than they once were, and IT managers rely on business managers to help them prioritize and fund IT projects. Network upgrades are made not because some new technology sounds interesting to the engineers, but because it will help an enterprise increase profits, productivity, market share, and cash flow. Network designers must choose solutions that solve a business manager's problem.

Network applications have become mission critical. Despite this trend, large budgets for networking and telecommunications operations have been reduced at some companies. Many companies have gone through difficult reengineering projects to reduce operational costs, and are still looking for ways to manage networks with fewer people and reduce the recurring costs of WAN circuits.

As the head count at many corporations remains flat or shrinks, there's a renewed focus on using network applications to increase individual productivity in all departments, not just within the networking and IT departments. One result has been the emergence of web-based productivity tools. Most enterprises streamline their business processes, applications, and protocols, and standardize on Transmission Control Protocol/Internet Protocol (TCP/IP). TCP/IP and web-based applications for selling products and supporting customers have risen in popularity, as have web-based applications for supporting employees and suppliers.

Streamlining processes and protocols has also led to an increased use of IP telephony and to the continued convergence of voice and data networks. To save money and to reduce the need for specialized data or voice engineers, companies continue to adopt IP telephony technologies.

Until recently, telecommunications and voice networks were separate. Telecommunications engineers knew little about data networks, and networking engineers didn't know the difference between a TDM and a Tandem Switching System (TSS). In today's environment, voice, data, and video networks are merging.

In traditional voice and data terminal/mainframe networks, data flow and throughput were predictable. Closed communications systems were the norm, and data sources were well known. In today's networks, Internet surfing is ubiquitous. It is hard to predict data flow and the timing of bursts of data when users are jumping from one website to another, possibly downloading videos or animation files. In addition to web surfing, the move to a network organizational model where the network is used by both inside and outside users affects network data flow. Network design practices must keep pace with these changes in business practices.

The Need to Support Mobile Users

Notebook computers have finally become small enough to carry around, and workers now expect to get work done at home, on the train, in hotels, in meeting rooms, at customer sites, and even while having their morning latte at the local coffee shop. These days almost every notebook computer ships with wireless networking built in to facilitate users getting work done outside the office.

It shouldn't matter (to the user anyway) where data is and in what format. Network users expect network performance to be uniform, regardless of where the user or data resides. A user should be able to read e-mail on a cell phone, for example, and read voice mail from a web browser while sipping coffee in an Internet cafe. Users should have secure and reliable access to tools and data wherever they are. The challenge for network designers is to build networks that allow data to travel in and out of the enterprise network from various wired and wireless portals without picking up any viruses and without being read by parties for whom it was not intended.

One of the biggest trends in network design is virtual private networking, where private networks make use of public service networks to get to remote locations or possibly other organizations. Customers getting involved in VPN projects have concerns about security, reliable and predictable performance, and data throughput requirements. VPNs are covered in Chapter 5, "Designing a Network Topology."

Network architectures are taking on a virtual and ubiquitous form for users, while remaining highly structured and managed from the network engineers' point of view. The designer is challenged to develop secure, resilient, and manageable solutions that allow users to work efficiently, wherever they are physically located.

The Importance of Network Security and Resiliency

Network security has filtered to the top of the list of business goals at many companies. Although security was always important, it has become even more important as networks become indispensable and as tools for breaking into networks become ubiquitous. Enterprises must protect their networks from both the unsophisticated "script kiddies" and from more advanced attacks launched by criminals or political enemies. There is also a continued requirement to protect networks from Trojan horses and viruses.

Many enterprise managers now report that the network must be available 99.999 percent of the time. Although this goal may not be achievable without expensive redundancy in staff and equipment, it may be a reasonable goal for companies that would experience a severe loss of revenue or credibility if the network were down for even very short periods of time. This goal is linked to goals for security, as the network can't be available if security breaches and viruses are disabling network devices and applications. When security and operational problems occur, networks must recover quickly. Networks must be resilient. More than ever, IT and business managers require high-availability and resiliency features for their network equipment and protocols, as they realize the extent to which network downtime can jeopardize business success.

In addition to security, another goal that has filtered to the top of the list of business goals is the need for business continuity during and after a disaster. Companies have learned from the attacks on the World Trade Center on September 11th, 2001, the importance of resiliency for network designs and applications. Many companies, including Lehman Brothers and the Wall Street Journal, managed to resume operations immediately following the attack. They were able to continue business operations because of a well-planned disaster recovery strategy and because of the redundancy built in to their networks.

Companies that have survived hurricanes, earthquakes, and fires have also learned the importance of a disaster recovery plan that promotes business continuity, despite the loss of critical network devices and services. Many companies have not had the misfortune of learning these lessons the hard way, but are nonetheless embarking on network design projects with the goal of developing a network that will recover quickly in the event of a natural or unnatural disaster.

One aspect of analyzing a customer's business goals is the process of analyzing vulnerabilities related to disasters and the impact on business operations. Help your customer determine which network capabilities are critical and which facilities provide them. Consider how much of the network could be damaged without completely disrupting the company's mission. Determine whether other locations in the company are prepared to take on mission-critical functions.

In the last few years, networks have become more interconnected and complex, which can make meeting goals for network resiliency more difficult. Many enterprise networks are linked to telecommuter home networks, branch-office networks, extranets that offer access to business partners and customers, and the Internet. The diversity and quantity of portals into the enterprise network pose many security and stability risks. On the other hand, geographical diversity of mission-critical capabilities has turned out to be a lifesaver for some companies hit with disaster. One reason that the Wall Street Journal was able to publish its newspaper the day after the 9/11 attacks was because it had learned from 1990 power outages about the need to disperse critical functions across many different sites.

These days, security and disaster recovery should be considered with every network design choice, and the network designer must propose solutions that provide resiliency and stability. A systematic and modular design process, as taught in this book, is even more important than it once was, as networks become increasingly complex and vital to an organization's success.

Typical Network Design Business Goals

If you keep in mind the changes in business strategies and enterprise networking discussed in the previous sections, it becomes possible to list some typical network design business goals:

• Increase revenue and profit

• Increase market share

• Expand into new markets

• Increase competitive advantages over companies in the same market

• Reduce costs

• Increase employee productivity

• Shorten product-development cycles

• Use just-in-time manufacturing

• Plan around component shortages

• Offer new customer services

• Offer better customer support

• Open the network to key constituents (prospects, investors, customers, business partners, suppliers, and employees)

• Build relationships and information accessibility to a new level, as a basis for the network organizational model

• Avoid business disruption caused by network security problems

• Avoid business disruption caused by natural and unnatural disasters

• Modernize outdated technologies

• Reduce telecommunications and network costs, including overhead associated with separate networks for voice, data, and video

Identifying the Scope of a Network Design Project

One of the first steps in starting a network design project is to determine its scope. Some of the most common network design projects these days are small in scope—for example, projects to allow a few people in a sales office to access the enterprise network via a VPN. On the other hand, some design projects are large in scope. Ask your customer to help you understand if the design is for a single network segment, a set of LANs, a set of WAN or remote-access networks, or the entire enterprise network. Also ask your customer if the design is for a new network or a modification to an existing one.

Explain to your customer any concerns you have about the scope of the project, including technical and business concerns. Subsequent sections in this chapter discuss politics and scheduling, which are tightly linked to the scope of a network design project. (Many network designers have learned the hard way what happens when you don't help your customers match the schedules of their projects to the scope.)

Make sure your customers tell you everything they can about the network and the design project. You may want to poke around outside the stated scope of the project, just to make sure nothing essential has been omitted. Double-check that you have gathered all the requirements and that you have accurate information about sites, links, and devices. If the project addresses network security, make sure you know about all external links, including dial-in access.

When analyzing the scope of a network design, you can refer to the seven layers of the OSI reference model to specify the types of functionality the new network design must address. For example, you might decide that the design project is concerned only with network layer concerns such as routing and IP addressing. Or you might decide that the design also concerns the application layer because the focus is on voice applications, such as Interactive Voice Response (IVR), which directs customers to the correct location in a call center, or unified messaging, where e-mail can be retrieved via voice mail and text messages can be converted into speech. Figure 1-3 shows the OSI reference model.

Figure 1-3 The Open Systems Interconnection (OSI) Reference Model

In addition to using the OSI reference model, this book also uses the following terms to define the scope of a network and the scope of a network design project:

• Segment. A single network based on a particular Layer 2 protocol. May include Ethernet hubs and repeaters, and multistation access units (MAUs) if Token Ring is still in use.

• LAN. A set of switched segments, usually based on a particular Layer 2 protocol (although mixed LANs are possible). May have one or more Layer 3 protocols associated with it, although most networks are standardizing on IP.

• Building network. Multiple LANs within a building, usually connected to a building-backbone network.

• Campus network. Multiple buildings within a local geographical area (within a few miles), usually connected to a campus-backbone network.

• Remote access. Networking solutions that support individual remote users or small remote branch offices accessing the network.

• WAN. A geographically dispersed network including point-to-point, Frame Relay, ATM, and other long-distance connections.

• Enterprise network. A large and diverse network, consisting of campuses, remote-access services, and one or more WANs or long-range LANs. An enterprise network is also called an internetwork.

Identifying a Customer's Network Applications

At this point in the design process, you have identified your customer's business goals and the scope of the project. It is now time to focus on the real reason networks exist: applications. The identification of your customer's applications should include both current applications and new applications. Ask your customer to help you fill out a chart, such as the one in Table 1-1.

Table 1-1 Network Applications

Name of Application	Type of Application	New Application? (Yes or No)	Criticality	Comments

For "Name of Application," simply use a name that your customer gives you. This could be an industry-standard name, such as Lotus Notes, or it could be an application name that means something only to the customer (especially for a home-grown application). For new applications, the name might be a code name for a software-development project.

For Type of Application, you can use any appropriate text that describes the type of application, or you can classify the application as one of the following standard network applications:

• Electronic mail

• File transfer, sharing, and access

• Database access and updating

• Groupware

• Web browsing

• Network game

• Remote terminal

• Calendar

• Medical imaging

• Videoconferencing

• Video on demand (VoD)

• Scheduled multicast video

• Surveillance and security camera video

• Internet or intranet voice (IP telephony)

• Internet or intranet fax

• Sales order entry

• Management reporting

• Sales tracking

• Computer-aided design

• Document imaging

• Inventory control and shipping

• Telemetry

• Interactive Voice Response (IVR)

• Unified messaging

• Desktop publishing

• Web publishing

• Electronic whiteboard

• Terminal emulation

• Online directory (phone book)

• Distance learning

• Point of sales (retail store)

• Electronic commerce

• Financial modeling

• Human resources management

• Computer-aided manufacturing

• Process control and factory floor

The preceding list includes user applications. The Network Applications chart should also include system applications (or, if you prefer, you can do a separate chart for system applications). System applications include the following types of network services:

• User authentication and authorization

• Host naming and name resolution

• Dynamic host addressing

• Remote booting

• Remote configuration download

• Directory services

• Network backup

• Network management

• Software distribution

In the Criticality column of the Network Applications chart, you can give each application a ranking from 1 to 3 with the following meanings:

1. Extremely critical

2. Somewhat critical

3. Not critical

Later, you can gather more specific information on mission criticality, including precisely how much downtime is acceptable (if the customer can quantify availability requirements).

In the Comments column, add any observations relevant to the network design. For example, include any information you have about corporate directions, such as plans to stop using an application in the future, or specific rollout schedules and regional-use plans.

Analyzing Business Constraints

In addition to analyzing business goals and determining your customer's need to support new and existing applications, it is important to analyze any business constraints that will affect your network design.

Politics and Policies

It has been said that there are two things not to talk about with friends: politics and religion. It would be nice if you could escape discussing office politics and technological religion (technology preferences) with a network design customer, but avoiding these topics puts your project at risk.

In the case of office politics, your best bet is to listen rather than talk. Your goal is to learn about any hidden agendas, turf wars, biases, group relations, or history behind the project that could cause it to fail. In some cases, a similar project was already tried and didn't work. You should determine if this has happened in your case and, if it has, the reasons why the project failed or never had a chance to come to fruition.

Pay attention to personnel issues that could affect the project. Which manager or managers started the project and how much do they have at stake? Are there any managers, network engineers, or users who want the project to fail for any reason? Find out who your advocates and opponents are. In some cases, no matter how technically sound your network design is, there will be people who have a negative reaction to it.

Be sure to find out if your project will cause any jobs to be eliminated. Some network design projects involve automating tasks that were once done by highly paid workers. These workers will obviously have reasons to want the project to fail.

Be prepared for the possibility of formidable office politics if your network design project involves the merging of voice and data networks. Voice experts and data experts have traditionally lived in their own worlds. They may face each other with some mistrust and fear for the future. You can often reduce the uncertainty by running short IP telephony seminars for voice technicians and traditional telephony seminars for the data network administrators.

While working with a client, you will gain a feeling for the client's business style. One aspect of style that is important to understand is tolerance to risk. Is risk taking rewarded in the company, or are most people afraid of change? Knowing the employment history of the decision-makers will help you select appropriate technologies. The employment history of the decision-makers affects their tolerance to risk and their biases toward certain technologies. Understanding these issues will help you determine if your network design should be conservative or if it can include new, state-of-the art technologies and processes.

Another aspect of the client's business style has to do with testing the design. At some companies, the testers might claim they have carefully tested a new Voice over IP (VoIP) implementation, for example, when what they really did was get a VoIP call to complete. Your idea of testing, on the other hand, might be to make numerous calls under various load conditions. See Chapter 12, "Testing Your Network Design," for more information on testing.

It is important that you discuss with your customer any policies (religion) regarding protocols, standards, and vendors. Try to learn of any "forbidden technologies" where the users or network engineers have decided, possibly for the wrong reasons, that a particular protocol is slow or unstable.

Find out if the company has standardized on any transport, routing, desktop, or other protocols. Determine if there is any doctrine regarding open versus proprietary solutions. Find out if there are any policies on approved vendors or platforms. In many cases, a company has already chosen technologies and products for the new network and your design must fit into the plans. Ask your customer if there are any policies regarding distributed authority for network design and implementation. For example, are there departments that control their own internetworking purchases? Find out if departments and end users are involved in choosing their own applications. Make sure you know who the decision-makers are for your network design project.

A lot of organizations need to implement policies in response to legal, regulatory, or contractual requirements. In the United States, Generally Accepted Accounting Principles (GAAPs) drive many accounting policies. In the medical profession, network designs may be affected by security and privacy policies that are regulated by the Health Insurance Portability and Accountability Act (HIPAA) of 1996. In other parts of the world, network equipment choices may be regulated by governmental Postal, Telegraph, and Telephone (PTT) organizations.

In the rush to get to technical requirements, network designers sometimes ignore nontechnical issues, which is a mistake. Many brilliant network designs have been rejected by a customer because the designer focused on the lower layers of the OSI reference model and forgot about company politics and technical religion.

Budgetary and Staffing Constraints

Your network design must fit the customer's budget. The budget should include allocations for equipment purchases, software licenses, maintenance and support agreements, testing, training, and staffing. The budget might also include consulting fees (including your fees) and outsourcing expenses.

Throughout the project, work with your customer to identify requirements for new personnel, such as additional network managers. Point out the need for personnel training, which will affect the budget for the project.

In general, it is a good idea to analyze the abilities of the networking staff. How much in-house expertise is there? Should you recommend any training or outsourcing for network operations and management? The technologies and protocols that you recommend will depend on the abilities of internal staff. It is not a good idea to recommend a complex routing protocol, such as Open Shortest Path First (OSPF), for example, if the engineering staff is just starting to learn internetworking concepts (unless you also recommend a comprehensive training plan).

Analyzing in-house expertise is especially important and challenging for companies that merge their voice and data networks. Consider the need to train the traditional voice experts on data technologies and the data experts on voice technologies. Also, implementing voice and video often requires advanced QoS knowledge that may necessitate training.

To ensure the success of your project, determine who controls the network budget—the Information Systems (IS) department, network managers, or users' departments? How much control do users and groups have over network expenditures? Are there any departmental charge-back schemes?

Regardless of who controls the budget, one common network design goal is to contain costs. Reduced budgets or limited resources often force network designers to select the most affordable solution instead of the best solution. It is useful to know the areas in which the network design can be changed with the least effect on performance to meet budget requirements. Chapter 2 discusses typical tradeoffs that must be made to meet the goal of affordability while achieving good performance and reliability.

If possible, work with your customer to develop a return on investment (ROI) analysis for the network design. Make a business case to the customer that explains how quickly the new network will pay for itself, due to reduced operational costs, improved employee productivity, or the enabling of higher revenue potential and market expansion.

Project Scheduling

An additional business-oriented topic that you should review with your customer is the timeframe for the network design project. When is the final due date and what are the intermediate and major milestones? In most cases, management of the project schedule is the customer's obligation, not yours, but you should ask the customer to give you a copy of the schedule and to keep you informed about any slips in the schedule.

Be sure to include circuit disconnect or circuit capacity changes in the project schedule. There is often a long lead time for these changes. Plan to document when the circuit changes and other major changes take place so that if problems occur, you can analyze what has changed to help you troubleshoot.

Many tools exist for developing a schedule that includes milestones, resource assignments, critical-path analysis, and so on. Take a look at these aspects of the schedule and voice your view on whether the schedule is practical, considering what you have learned about the scope of the project. During the technical-analysis stage and the logical- and physical-design phases of the project, be sure to keep the schedule in mind. As you iteratively develop a concrete understanding of the technical scope of the network design project, point out any concerns you have about the schedule.

Business Goals Checklist

You can use the following checklist to determine if you have addressed your client's business-oriented objectives and concerns. If you can't gather every piece of data mentioned in the checklist, make sure you document what is missing in case it becomes critical, but don't stall the project to gather every last detail. This book teaches an ideal network design methodology that you should try to follow, but if real-world constraints, such as uncooperative network design customers, budget cuts, and time constraints, hamper your ability to follow the methodology precisely, just follow it as much as you can. In general, the methodology still works even if some data is missing after you do your analysis.

• I have researched the customer's industry and competition.

• I understand the customer's corporate structure.

• I have compiled a list of the customer's business goals, starting with one overall business goal that explains the primary purpose of the network design project.

• The customer has identified any mission-critical operations.

• I understand the customer's criteria for success and the ramifications of failure.

• I understand the scope of the network design project.

• I have identified the customer's network applications (using the Network Applications chart).

• The customer has explained policies regarding approved vendors, protocols, or platforms.

• The customer has explained any policies regarding open versus proprietary solutions.

• The customer has explained any policies regarding distributed authority for network design and implementation.

• I know the budget for this project.

• I know the schedule for this project, including the final due date and major milestones, and I believe it is practical.

• I have a good understanding of the technical expertise of my clients and any relevant internal or external staff.

• I have discussed a staff-education plan with the customer.

• I am aware of any office politics that might affect the network design.

Summary

This chapter covered typical network design business goals and constraints. It also talked about the top-down process for gathering information on goals, and the importance of using systematic methods for network design. Using systematic methods will help you keep pace with changing technologies and customer requirements. The next chapter covers analyzing technical goals and constraints.

This chapter also talked about the importance of analyzing your customer's business style, tolerance to risk, biases, and technical expertise. You should also work with your customer to understand the budget and schedule for the network design project to make sure the deadlines and milestones are practical.

Finally, it is important to start gaining an understanding of your client's corporate structure. Understanding the corporate structure will help you analyze data flow and develop a network topology, which usually parallels the corporate structure. It will also help you identify the managers who will have the authority to accept or reject your network design, which will help you prepare and present your network design appropriately.