Home > Articles > Cisco Network Technology > Network Architecture & Design > Analyzing Business Goals and Constraints of Network Design

Analyzing Business Goals and Constraints of Network Design

Chapter Description

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.

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.


Understanding the corporate structure will also help you recognize the management hierarchy. One of your primary goals in the early stages of a network design project should be to determine who the decision-makers are. Who will have the authority to accept or reject your network design proposal? Sometimes, this can be a rather complicated issue, as discussed in the section "Politics and Policies," later in this chapter.

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.


Designers rarely get a chance to design a network from scratch. Usually a network design project involves an upgrade to an existing network. However, this is not always the case. Some senior network designers have developed completely new next-generation networks to replace old networks. Other designers have designed networks for a new building or new campus. Even in these cases, however, the new network usually has to fit into an existing infrastructure—for example, a new campus network that has to communicate with an existing WAN. Where there is an existing network, the design project must include plans for migrating to the new design with minimal disruption and risk.

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 3Figure 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 identifies network applications. In Chapters 2 and 4, it will be enhanced to include technical requirements and network-traffic characteristics. At this point, your goal is simply to identify network applications.

Table 1-1 Network Applications

Name of Application

Type of Application

New Application? (Yes or No)


















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.

3. Analyzing Business Constraints | Next Section Previous Section