As part of the process of gathering information about a customer’s goals, constraints, and requirements for a new or upgraded network, documentation needs to be created. Ultimately, this documentation will be used to confirm that both the designer and the customer agree on the requirements, as well as associated goals and constraints that will impact the project.
The documentation of the gathered information is not subject to any specific format at this point in the process. However, there are certain methods that can be used to structure the information, making it easier for both the network designer and the customer to review in a more organized and simplified manner. Perhaps the most popular method is through the use of decision matrices.
A decision matrix is not nearly as complex as it sounds. In truth, it’s really nothing more than a table that can be used to document information about specific elements of the network design or data gathering process. For example, a decision table might be used to document all required applications for a new network, as shown below. In this example, the matrix simply lists a particular application type, its name, importance information, and comments.
Example Decision Matrix
Once created, a decision matrix provides a simplified high-level overview of gathered data or design information that makes it easy for the designer and decision makers to easily review project details.
Aside from documenting the business and technical goals and constraints of an organization, the initial data gathering process needs to also consider any new planned services, applications, and features required for the new or upgraded network. For example, an organization might be planning to implement a new email platform, Voice over IP (VoIP) services, or a network management system (NMS). Ultimately, the network requirements outlined by the customer need to be considered in conjunction with both the goals and constraints looked at earlier.
The bullet points below outline some of the common types of applications, services or features that a company might have defined as requirements for a new or upgraded network.
- Security services. Examples of security services that a company might be looking to implement as part of a new or redesigned network include authentication services like RADIUS, firewalls like a Cisco PIX, or IPSec VPN connections between offices.
- Network management applications. Examples of network management applications that a company might be looking to deploy include elements of the CiscoWorks suite, HP OpenView, and other SNMP-based utilities.
- Network availability. On of the most common requirements specified by customers includes the need for high network availability in order to provide redundancy. This can be accomplished in a variety of ways, including through the use of redundant links to interconnect equipment.
- Advanced service support. Customer requirements for a new or upgraded network may include the need to support features like Quality of Service (QoS) and IP Multicasting.
Outside of simply defining new applications, services and features, information should also be gathered about how critical the customer considers each to be. For example, although the customer may specify ten new requirements, some of the business constraints (such as the budget) may impact the number of applications or services that can be ultimately be deployed. By prioritizing in this way, the designer can work with the customer to determine which elements can reasonably be implemented based on all of the available information.
Similar to business constraints, technical constraints represent any of a number of technical issues and obstacles that will impact the network design. For example, a company may have made a fairly recent investment in some new equipment, and require that this equipment be incorporated into the new network design. Similarly, a company might be trying to connect many rural branch offices to a central location via WAN links. An example of a technical constraint in this case might be a company’s preference for Frame Relay, but it not being available in some of the proposed locations.
The bullet points below outline some of the most common types of technical constraints that a network designer may encounter, along with examples.
- Bandwidth or media limitations. In any network design project, it is conceivable that certain parts of a network cannot be changed for a variety of reasons. For example, an organization might have a LAN installed in a factory that uses 10 Mbps fiber optic cabling that they are not willing to replace, perhaps for budgetary reasons. In this case, the available media and bandwidth represents a technical constraint that must be circumvented, since replacement is not an option
- Application limitations. The applications currently used by an organization can have a significant impact on a network design project. For example, the customer may rely upon a particular program that can only function using a specific protocol like NetBEUI. In this case, the application would either need to be replaced, or the design would have to include support for the NetBEUI protocol. In a similar manner, a customer might still be using an older operating system like Novell NetWare 3.11 for an accounting application, necessitating that the design include the IPX/SPX protocol.
- Personnel limitations. Even in cases where an organization has sufficient staff to allocate to a project, it is possible that these staff members do not have the technical expertise required to help implement the new network or manage it once complete. This is another example of a technical constraint that may need to be dealt with by obtaining additional training for the staff, hiring additional staff, or revising the scope of the project.
- Existing equipment. Over time, companies invest in a variety of different network equipment to meet different needs. Although some companies can afford to replace all existing equipment as part of a network upgrade project, others will want to protect existing investments and reuse as much existing equipment as possible. This is a classic technical constraint that ultimately impacts almost every network design project.
Although the implementation of technologies is generally driven by business needs to begin with, companies ultimately come to rely upon these same technologies in order to function over the longer term. In line with this concept, an organization will general have technical goals as part of any planned network design project.
Examples of common technical goals include improving the security, performance, availability, and scalability of a network, as well as streamlining network management functions. Each of these areas is looked at in the bullet points below in more detail.
- Improve network security. Improving or redesigning the security of an organization’s network is an example of a technical goal. For example, a company may want to implement firewalls or intrusion detection systems to better protect internal systems from external users.
- Improve network performance. Improving performance through the implementation of a new network or the upgrade of an existing network is another common example of a technical goal. For example, a company might still be using 10 Mbps Ethernet hubs for connectivity on some LANs, and might want to increase performance at the access layer by implementing Fast Ethernet and dedicated switch ports for all systems.
- Increase network availability. Increasing network availability is a technical goal usually achieved through the implementation of network redundancy features. For example, a company might specify that any new network must implement redundant trunk links between switches, such that the failure of any link would not impact the entire network.
- Streamline network management. The redesign of network management processes in another example of a technical goal. For example, an organization’s current network management strategy might be largely reactive, trying to deal with problems when they arise. Deciding to implement a network management system such as HP OpenView for the purpose of proactive management would be considered a technical goal.
- Increase network scalability. Over time, the network requirements for an organization will change. For example, a company might be planning to merge with another organization in the near future, and wants to ensure that the new network will be able to scale in a manner suitable to supporting new users, connections, and more.
In a perfect world, a network design project would not have any business constraints. The network designer would be given a list of business and technical goals, along with a blank check. Unfortunately, business constraints like financial issues, corporate policies, scheduling, and personnel issues must all be carefully determined, considered, and well understood in order for a network design project to succeed. Overlooking any one of these areas would at best lead to a few unpleasant surprises, and at worst, potentially doom the network design project to failure.
The list below outlines some of the more common business constraints that you should be familiar with, along with examples.
- Budgets. Financial considerations represent the most common business constraint. While some companies develop a fixed budget for a project in advance, others tend to be more flexible, especially in cases where the scope of a project changes after the current situation is assessed. Regardless of whether it is flexible or not, the budget associated with any project represents the classic example of a business constraint, and one that is generally easy to identify.
- Corporate policies. Businesses of all sizes define policies and procedures based on what they perceive to be best practices. Since policies vary from organization to organization, it is critical for the network designer to gather information about any policies that might impact a project. An example of a corporate policy that represents a business constraint would include a company requiring you to deal with a preferred vendor.
- Scheduling issues. Scheduling issues are an example of another very common business constraint. As part of deciding to pursue a particular project like implementing a new network or an upgrading an existing one, a customer will generally include a schedule that defines when the project should be completed, as well as individual milestones.
- Personnel issues. Personnel issues are an example of a business constraint that can take many different forms. For example, a company might not have sufficient staff to allocate to a project, or those staff members may not have the required knowledge to participate. Similarly, personnel issues can also impact project schedules based on the availability of staff when factors like other projects or vacation time are considered.
Perhaps the most important part of gathering information for any network design project is determining an organization’s business goals. While implementing a new network that supports a variety of new applications and services may be the main deliverable for a project, this outcome is usually driven by business needs. Very few companies have the resources (monetary or otherwise) to implement technology for technology’s sake. Instead, they have specific organizational goals, which technologies like a new or redesigned network are implemented to support and enhance. In almost all cases, business needs drive technology, and not vice versa. This is an important distinction that many IT people often overlook.
The bullet points below outline some common business goals that you should be familiar with. Others certainly do exist, but almost all can be broadly characterized with the categories provided.
- Increase productivity. Increasing productivity is a central goal of just about all organizations. For example, a company may want make employees more efficient, helping them to spend more time on their core responsibilities. Similarly, a manufacturing company may be looking to implement new communications processes for advanced monitoring, thereby reducing downtime. Anything that relates to increasing productivity or efficiency can safely be considered a business goal.
- Improve customer support. All organizations rely upon their customer base in order to survive. Regardless of industry, a company without customers soon ceases to be one. As globalization makes competition fiercer, companies need to look towards improved methods of communication with and supporting their customers. For example, perhaps the goal of a company is to consolidate customer management functions, or shift all order processing and procurement to a new online system. Both would be examples of a business goal, namely improving customer support.
- Reduce costs. One major reason for implementing a new or redesigned network is to help reduce costs, both in the short and longer term. Although implementing a network generally involves a fairly large initial capital investment, it may have a significant impact on reducing costs in the long term. For example, perhaps a company is looking to implement a Voice over IP solution in order to reduce costs associated with long distance calls, or a new VPN in order to allow staff to work from home, reducing the need for office space and related equipment.
- Improve partner relationships. For many companies, managing partnerships or associated relationships effectively is critical to their line of business. For example, an automobile manufacturer relies upon potentially hundreds of suppliers to ensure that it can produce completed vehicles. When companies have different internal processes and methods for exchanging information, this can become a daunting task. As such, many companies now look to implement systems to tie into those of their partners, streamlining processes and communications. While implementing an extranet might be a technical goal, improving and streamlining processes between organizations would be the associated business goal.
The first step in any network design process involves gathering pertinent data in order to better understand a customer’s business and technical requirements. In many cases, companies will provide you with basic information about their business and technical requirements in advance, often in the form of a request for proposal (RFP) or request for information (RFI). While these documents sometimes provide great depth and detail, they can also be missing critical and necessary information. As a network designer, it is your job to ask the correct questions in order to acquire all of the necessary information that will allow you to understand the customer’s business and technical environment.
Broadly speaking, identifying customer requirements involves knowing more about their business and technical goals, as well as the services, applications, and features that they plan to deploy. While gathering information about goals is critical, it is just as important to gather information about any constraints that may exist; in other words, factors that cannot be overlooked that will ultimately impact the proposed solution.
For the CCDA exam, you are expected to be able identify goals and constraints of a business or technical nature. Unfortunately, part of gathering information involves the sleuth or detective work mentioned earlier. You simply cannot expect to be presented with explicit information that states, “our business goals are” or “our technical constraints are”. Instead, you’ll be expected to extract constraints and goals from case studies, using the information provided to determine exactly what the real issues are, and the categories they fall into.
The following articles outline examples of common goals and constraints associated with a network design project, and the categories that they fall into. It’s important to note that the process of documenting an organization’s goals, constraints, and requirements is not a series of standalone steps, but rather an iterative process that involves gathering information in certain areas, and then making adjustments as new information is discovered or presented to you.
While the roles of a network designer are indeed varied, and different general approaches to network design exist, the entire concept of designing a network is greatly simplified through the use of structured design methodologies. Although it sounds rather fancy, a structured design methodology is really nothing more than a set of distinct steps that help to ensure that all of the necessary tasks in the network design process are completed.
Cisco uses a methodology known as PDIOO as part of designing networks. PDIOO is an acronym that describes some of the major elements in a network design process, namely:
Instead of concentrating on memorizing these elements, you should instead focus on recognizing them as the key elements to any network design project. More than anything, PDIOO represents a theme that comes up again and again over the course of designing not only a network, but also just about any system you can think of.
For the purpose of designing networks, Cisco recommends an 8-step process that constitutes the structured network design methodology mentioned earlier. Each of these 8 steps represents a specific network design task that much be completed as part of a project. The specific steps involved in any network design project include:
- Identifying customer requirements
- Identifying and analyzing the current network
- Designing network topologies and services
- Planning the network implementation
- Proof of concept (building pilots or prototypes)
- Documenting the network design
- Implementing and verifying the network design
- Monitoring and revising the network design
Each of these elements is looked at in more detail in upcoming articles.
Although a top-down approach is preferred to the bottom-up method, both have associated advantages and disadvantages. The lists below take a look at some of the relative advantages and disadvantages of each method.
Top-down Network Design:
Advantages: Begins with a focus on an organization’s specific goals and requirements for network applications and services, while allowing potential future needs to be considered and accounted for.
Disadvantages: Requires thorough initial needs analysis in order to determine specific requirements, and ensure that all possible applications and services have been considered.
Bottom-up Network Design:
Advantages: Generally a faster approach based on past projects and implementations that works within an existing environment.
Disadvantages: The approach may not take all necessary applications and services into consideration, leading to a design that ultimately may not meet the needs of an organization, and may need to be redesigned in the future.
Two very general approaches exist to developing a network design, known as top-down and bottom-up. In this case, the “down” and “up” being discussed relate to a concept you are already familiar with, namely the OSI model.
The Top-Down Approach
In a top-down approach, a network designer looks at a project starting with the general applications required. In this sense, the term “application” does not necessarily mean things like a web server or Internet Explorer, although they may certainly be factors. Instead, this approach focuses on determining what the goals of the network are from an Application Layer perspective, namely the applications or services required. For example, an organization might want to implement or upgrade a network to support new applications like Voice over IP (VoIP), IP multicasting, and so forth. Along the same lines, the goal of the customer might be to interconnect to a partner network to enable an e-commerce platform. Notice that the top-down approach doesn’t begin by focusing on any particular technical elements. No discussion of Gigabit Ethernet, fiber optic cabling, or routing protocols occurs at this level. Instead, the top-down approach is solution-oriented, focusing on the specific business and technical goals of an organization. Of course technologies do need to be considered, but this typically happens later in the design process.
The Bottom-Up Approach
The alternate approach, known as bottom-up, is more commonly employed, but is far from optimal. Instead of focusing on the applications that drive the need for a new or redesigned network, this approach tends to start lower in the OSI model, worrying about issues like specific technologies, protocols, network media, and so forth. Generally speaking, this is the “stuff” that networking professionals are most familiar with. They have a tendency to begin the design process at this level, leaving applications and services as an afterthought to be considered later. After all, the network won’t do anything without the necessary equipment, or so popular thinking goes. In most cases, taking a bottom-up approach tends to require a less thorough initial analysis, and is easier to implement as a quick fix. Ultimately, however, the bottom-up approach is seldom truly successful, as it tends to rely on a number of fixes along the way in order to deal with issues that were not initially considered.