NET 226 - Designing Internetwork Solutions

Chapter 1, Analyzing Business Goals and Constraints

Objectives:

This lesson introduces the ideas behind top-down network design. Objectives important to this lesson:

  1. Top-down methodology
  2. Analyzing business goals
  3. Scope of a network project
  4. Identifying network applications
  5. Analyzing business constraints
Concepts:

Chapter 1

Top-down methodology

The chapter begins with the very realistic idea that a network can be a mess. This can be due to poor planning, or to patching and replacing hardware and software without an eye on the big picture. The author's purpose for her text is to show us a method that may avoid unnecessary complexity and mystery in network design. We are given a hint about the meaning of "top-down" on page 4, where the author tells us that we will begin our design at the top (upper) layers of the ISO-OSI Network Model.

The seven layers of the model are usually written in a list, numbering the top as layer seven and the bottom as layer one.

Layer Number ISO Layer Functional Description
7 Application services and programs
6 Presentation translation across networks
5 Session setting up and ending connections
4 Transport guarantee delivery
3 Network find other networks
2 Data-Link media access and links inside a network
1 Physical wiring, bit transmission, sending and receiving network signals

The author explains that this approach begins with questions about what the users will do on this network. We want to know, as layer 7 suggests, what applications will run on this network. We also want to know who will use those applications and what the goals are for their usage. Although the author has not really explained either approach yet, she allows that we could us a bottom-up approach (which she calls "connect the dots") if our user's applications and goals are well known.
The top-down approach should seem familiar to you if you have taken classes about structured approaches to creating applications or computer systems.

An introduction to a structured approach appears on page 5:

  • Use a top-down approach
  • Model the current system (if any exists) and the new system.
  • Collect information on data, data flows, and data processes.
  • Learn what the users need from their processes and their data. Develop a model of how the organization works and how it can make the best use of its data.
  • Develop a logical model about what the system must do, then a physical model about how the system will do it. Logical models are based on a big picture or strategic view of what the company does. Physical models are based implementing functions with hardware and software.

The creation of a logical model before the physical model supports the concept of starting at a high level and working into the details after you define the big picture.

The text continues its background material with a discussion of the Systems Development Life Cycle model. This model can be used to create a new system or to revise an old one. It s a cycle because it is meant to be repeated any time a change is needed or desired.

The author tells us on page 6 that there are four phases in the design part of the life cycle version she favors. She shows six phases in the graphic on page 7, which include two phases for implementation and monitoring. Those phases are not included in the discussion in this chapter.

SDLC

The four phases in the design portion of the cycle (top to bottom, clockwise) are discussed briefly:

  • Analyze requirements - What are the business goals for this network? What are the constraints we must include? Do we need to balance the goals against what we think we can or can't do? Does the existing network perform as desired?
  • Logical network design - This is about the things you can do beefore you choose hardware. What shall we pick for a logical topology? How many networks do we want? What should be our address range, and how will we name our devices? Will we use WAN links, and if so, how do the constraints limit our choice of vendors?
  • Physical network design - What brands, models, and actual devicees will make our network functional? Which ISP or data carrier have we selected, and how does that affect what we use to connect to them?
  • Test, optimize, and document - Build a prototype, write a test plan, and test the new network model. Document everything about it as a proposal for the full scale network build. Note: at this stage it it still only a plan. The new network has not yet been built.

The text also presents a Cisco version of a network life cycle which condenses the logical and physical design steps above into one step. This may cause the reader to wonder whether each phase of such a project is the same length or importance as the other phases. The Cisco version separates the Test and Optimize phase in the model above into two separate phases. It also adds an eventual Retirement phase, placed in the center of their cycle wheel because it could happen at any time. All computer hardware and software will eventually need replacement, and that need may arise no matter what phase of a cycle we happen to be using at the time

 

Analyzing business goals

This section is very much like what you should have seen in a System Development class. The text makes a point of discussing this phase as gathering business goals. If you are working with a client you have known for years, you may know their business already. If this is a new client, you should follow the advice in the text to research the client's business, especially by talking to and observing the client's staff as they work. It is also important to know something about the organization of the client's company for two reasons.

  • Knowing who is in charge of what tells you who makes decisions about their processes and their data.
  • It also tells you who works with whom, and gives you clues about the actual, functional organization of the company, whether they have a functional organization chart or not.

If you understand why the network addition or change is necessary to the client, you will have a way to judge whether the project is successful. Learn what the customer needs, what the customer wants, and how success will be measured from the customer's point of view.

  • The text suggests that the success of a network project may be judged by reduction of operational costs, increased communication speed or volume, or by new revenue that the customer expects to generate.
  • New or improved features are also reasons to change networks, such as improved management tools, reduced energy footprints, or additional services such as support for mobile users.
  • An ongoing reason for network changes is security, which is related to resiliency. Networks must be protected in order to remain available, and must be recoverable, which means there should be some ability to duplicate any service that is critical to the client's operations.

Some of these ideas appear in the list of common business goals on pages 13 and 14.

Scope of a network project

This part of the text discusses measuring the size of a project. It advises you to ask the customer about all the requirements, but be aware that it is unlikely that the customer is well versed in network design needs, so they often will not be the best judge of what the project needs or how long it will take to finish it.

The text suggests we start a scope analysis with the OSI model. The model itself does not discuss network projects, but we can examine the project request in terms of which layers the project will touch. To do this, you will have to keep a high altitude view of the project, since every network transmission from any application will pass through all seven layers of the model. The text is a bit more helpful with a list of terms on pages 15 and 16 that can be guidelines for the extent of a project:

  • Segment - a single network, or a portion of a network, with a switch or a router at the outer boundary. Think of a home network in which all devices plug in to a common switch. Technically, each line of UTP running from a computer to a switch can be viewed as a separate segment, but the text seems to be referring to the small collection of devices that connect to one concentrator.
  • LAN - in the definition in the text, we assume multiple devices connected to switches (each device to one switch), and a protocol that lets the switches pass signals to other switches.
  • Building network - building from the previous concept, a building network may connect multiple LANs, typically with routers, but possibly with switches. This concept of this network is limited to one building. There is typically a backbone network providing communication between smaller units (LANs).
  • Campus network - several building networks may be linked as a campus network, including LANs in as many buildings as may be in a single corporate or organizational site. There is typically a backbone network providing communication between smaller units (building networks).
  • Remote access - networks that allow mobile users to connect, possibly across the Internet or across a leased data line. This may support single users, or clusters of users in specific locations. VPN software is probably used in these cases.
  • WAN - typically, this network crosses city boundaries, and requires data lines that may operate under several different protocols, such as point-to-point, Frame Relay, ATM, and other Wide Area Network methods.
  • Wireless network - The statement in the text is misleading. Wireless networks do not require air to operate. The typically operate on radio frequencies or infrared light, neither of which "use air" as a medium. If there were no air, the network would still work, as proven by network components in space. The only requirement for a wireless network is that it does not require a cable of any sort to connect to a network. Various types of wireless networks have different ranges, but this is the first one in the list that is not measured by the distance of components from each other.
  • Enterprise network - This one is also not really determined by size or distance, although such networks are typically large and widespread. An enterprise network is one that may have many components, and is owned by one entity. It may have locations in several cities, several states, or several countries. Its components will typically include all of the elements listed above.
Identifying network applications

The text takes another point of view as its next premise: that networks exist for applications. Some applications can run on a network or not, but some require a network to offer any value to the customer. If you are having trouble deciding if an application is a network application, remember a definition of a network. Networking can be defined with five features:

  • users sharing resources (like printers or files)
  • across a common medium (like copper wire or fiber optic cable)
  • by way of specific rules (like TCP/IP or other network protocols)

Each of the words in bold or in a color in the list above represents a separate component in the definition. When users are sharing data, printers, or cable runs, there is a network involved. The text offers a long list of application types on pages 17 and 18. It is not a complete list, and it probably never can be complete. Some of these types can work as standalone installations, that is, you don't have to have a network to run them. When you survey a customer about their applications, keep this in mind. Don't just ask about their network applications. Ask about every application that uses a network service or resource. The list should be longer when you ask this way.

When using the survey form on page 16, you should also make sure to note the applications that are used to manage the network itself, or to manage devices that are part of the network. They probably fit the smaller list of types on page 18. Note that there is a wider version of the survey tool on page 54. This version asks for more details about each application.

At the end of this short section, the text examines another column on the survey tool: criticality. It would be pointless to ask users to put a value in this column until you explain what the word "critical" means, and how to score their applications. The ranking on page 18 seems a bit vague to me. It only offers three choices:

  • Extremely critical
  • Somewhat critical
  • Not critical

If you don't see the problem, try substituting the word "dead" for the word "critical". Are the first and second choices actually different? How can I tell whether an application belongs in the first category or the second? Doesn't there seem to be a wider gap between the second and third choices than between the first and second choices?

Critical is not a word that works well with adjectives. Instead of this approach, it might be better to take a time related approach. If this application stopped working, how long could you wait for it to be functional again? How long could it be down before it affects our business?

  • A month?
  • A week?
  • A day?
  • An hour?

This is not only more granular, it is a question the users and managers may be able to answer in a way that will allow you to tabulate and compare those answers. Don't be surprised that different users will have different priorities.

Analyzing business constraints

The last major topic concerns finding and dealing with the things about the project that you cannot change. That's what a constraint is: something you have to accept, work around, or make a feature in the project. There will be constraints on most projects that will affect your plans, so you should know about them as soon as possible. And I would recommend reciting the serenity prayer to yourself, whether you have a religious faith or not. If that doesn't do it for you, remember a quote from Robert Heinlein: "Never try to teach a pig to sing. It wastes your time, and it annoys the pig." He wasn't talking about pigs.

The text offers some advice about things to watch for. The first discussion is about the internal policies and politics of the customer's organization.

  • hidden agendas and internal wars between people in the organization
  • a history of other projects that will affect how your project is perceived
  • people who are already in favor of your project or opposed to it, before you have even submitted it
  • people in jobs that will be eliminated by your project
  • projects that merge voice and data services when there are entrenched organizational units that manage them separately
  • designing your project to include an acceptable level of risk: is it too risky for them or not innovative enough?
  • are there products or vendors that you are required to use, or required not to use? this applies to hardware, software, operating systems, network devices, protocols, and anything else that might have a place in your project
  • is the project affected by real politics: federal or local regulations that must be followed?

good, fast, or cheapThe second major discussion is about money and staff. These are related concepts, which you know if you are familiar with the idea that a project can be fast, cheap, or good, but you can only have two out of three. Notice that there is no point in the figure on the right where all three colors overlap. (Listen to the testimony of Lucas Martell. Yes, an animation project is an IT project.)

The text points out that a project that requires new hardware may also require licenses for software. The hardware may also have an ongoing expense for maintenance, whether done by your own staff of by a service provider. If you are adding new staff as part of the design, there will be payroll for the staff, and often training expenses for them.

The third discussion is about scheduling the project. The date the project is due to be be completed is important, but the text reminds us to schedule milestone events along the way. The purpose of a milestone is to celebrate the completion of something, often a major part of a project. Milestones also exist to tell us whether we are or are not on schedule to meet that end date. If we reach a milestone later than we should, we should consider changing the due date or changing what we are doing that is slowing us.

The text recommends that we consider using standard tools to analyze the flow of our projects. We should update the customer about problems as they arise and renegotiate the schedule as needed.

The chapter ends with a checklist that summarizes the information you should gather about a project before you can be sure you will be able to complete it. There is a similar list at the end of chapter 2, but we will start the first assignment for the class with elements from Chapter 1.

Week 1 Assignment: Chapter 1

  • Read Chapter 1
    • Read the Design Scenario on page 24. Answer questions 2 and 4 on that page.
  • Read Chapter 2 and 3