SMB Networking Solutions Design Considerations
The basis of any business transaction is the exchange of perceived value between the transacting parties. Designing a networking solution is not only a technical issue, it is a business proposition and a transaction.
For example, the value of a solution might be found in its sheer novelty, thus creating a perception on the part of an SMB's stakeholders of a business that is innovative, creative, and on the cutting edge of technology. That perception in turn could lead to higher levels of investment or an increase in the customer base that further expands the business. A single converged IP network transcending geographical boundaries and supporting multimedia communications (voice, streaming audio and video, selective video conferencing, and all of the traditional database and resource sharing functions) can be viewed as a trendsetter in ultimate productivity. That kind of perceived value tends to come from early adapters whose business mission (whether formally stated or not) demands that they be perceived as innovative and progressive. The value of a networking solution can also be associated with something that is perceived as a bit more mundane and mainstream, such as an incremental increase in productivity by occasionally allowing an employee to work remotely.
Whatever the SMB's position regarding a networking solution, the value proposition of the solution needs to be clearly articulated because it drives the design process. When considering the design of the solutions in the sections that follow, ponder the fundamental issue of value to the SMB resulting from each solution.
In addition, keep in mind that many solutions are organically grown together. Remote access can be designed for internal employees only, as a part of collaboration with partners, or as a part of customer care. In all instances, it is tied closely to security. Front office/back office integration requires that a solid networking infrastructure already be in place and that the software applications to be integrated are already functioning well.
When designing a networking solution, it is quite easy to be drawn into the process of solving all of the existing network problems that, from your perspective, represent separate issues. However, keep in mind that when it comes to the network, your perception typically has a higher granularity than the view of the executives who have to sign off on the design document and sign the purchase orders for labor and equipment to proceed with deployment. The executives tend to take a more integrated view of the network, in which many issues boil down to a simple question: Will it function well and support the business's goals?
You must always give consideration to the reconciliation of the highly granular versus the highly integrated views of the network. Otherwise, the potential for failure of the design process is high. The executive stakeholders will not sign off on a design that does not give significant consideration to implementation issues.
Network and Data Security Design Considerations
Ponder these questions in the context of considering the deployment of a security solution:
Has the SMB placed a monetary value on having its computer network inaccessible for varying periods of time, from a few minutes to hours, or even days?
Is the impact of system unavailability linear as a function of time, or does the impact spiral out of control at a certain point, causing the business to fail or lose a significant market share to competition?
What is the impact of having employees spend many hours unproductively due to downtime?
What is the impact of having confidential and proprietary information fall into the wrong hands?
What is the impact of having mission-critical information imperceptibly altered or outright corrupted?
A key concept to keep in mind while designing security solutions is that a security solution is not equivalent to a security policy. A security solution supports a security policy but is not a substitute for one; that distinction, although it might seem clear, tends to get blurred during the design process if an SMB does not have a clearly defined policy.
SMBs without sufficient resources to afford internal network security staff probably lack a security policy and might be looking to you as a resource for developing it without even necessarily identifying the process in those terms. When you realize that this is happening, you must differentiate between the changing responsibilities: designing a solution to support a policy versus developing a policy that in turn will require one or more solutions to implement it. Although both tasks are valid, developing a security policy might have different legal ramifications than designing a security solution to implement it.
Design considerations for specific security solutions dealing with specific threats and deployment scenarios are discussed in Chapter 5. Chapter 4, "Overview of the Network Security Issues," provides an overview of security issues, including terminology, security threat categories and their respective antidotes, and the importance of developing a security policy before proceeding with any security implementations.
Remote Access Design Considerations
You should consider the following questions before defining the requirements for any form of a remote access solution:
What is the value of having access to a corporate database anytime and from anywhere?
Are there any other resources on the corporate network—such as high-performance printers, network management stations, or even individual networking devices—that it would be useful to access remotely?
Who are the most likely candidates within the SMB's corporate structure to have remote access?
Who are the least likely candidates for having remote access? Why?
Is it possible that a mindset has developed that needs to be reevaluated regarding who should and should not have remote access?
If remote access is offered, what are the acceptable performance criteria for it to be effective?
What security considerations will accompany any form of remote access?
Answers to those questions drive the design process and determine the specificity of the solution, the remote user categories, the granularity in access levels for different groups of users, and the performance and security criteria for a solution to be effective.
Wireless Design Considerations
What is the value of retaining a connection to the network while maintaining physical mobility? Perhaps mobility in a certain SMB means occasionally carrying a notebook computer from an office cubicle to a conference room and then connecting the notebook to the network in the conference room via a wired outlet in the same manner as it is done in the cubicle. In this case, there probably is not much reason to consider the design of a wireless network.
But what if the work atmosphere at the SMB location is much more dynamic, prewired meeting facilities more limited, and coworkers routinely need to get together to collaborate or to do research on various projects while retaining network access? If a meeting facility has a limited number of wired network connections, it means that a switch might have to be set up locally to provide network access, and cables might snake all over the room—not exactly a scalable or productive environment. What is the value of a wireless solution under those circumstances? Also, consider an automated production facility in which requests for inventory delivery from a manufacturing floor must be transmitted to mobile operators on the warehouse floor. The need for a wireless design in this situation would be greater than in a business that requires only an occasional walk from a cubicle to a conference room.
You need to consider the following questions, and possibly others, when designing a wireless solution:
Are productivity gains (due to mobility while retaining network access) or savings (from not having to install cabling and cross-connect closets) sufficiently offsetting the cost of design, installation, and maintenance of a wireless solution?
How secure will the solution have to be, and where will the access points need to be located, to provide sufficient coverage for those authorized to use the wireless local-area network (WLAN) and yet not let it extend beyond the facility to public areas where anyone can tap into it?
Is the wireless approach considered only for LANs or for WANs as well?
Will the SMB proceed with a radio frequency (RF) site survey, which is always strongly recommended for larger wireless installation, or will a site survey be skipped, with all of the attendant implications of not identifying potential sources of interference, connection boundaries, and RF dead spots?
The Cisco wireless solution is discussed in Chapter 6, "The Wireless LAN Solution."
IP Telephony Design Considerations
What is the value of deploying an IP Telephony solution if the existing telephone system already works well? You can assume that an SMB will have some form of a telephony infrastructure already in place. There are plenty of questions to ask when considering an IP Telephony solution:
What is the investment (in terms of time and money) that has been put into the existing infrastructure? Does the high-level design approach require leaving what is already in place (and not changing it in any way), replacing it entirely, replacing it partially, or integrating it with new equipment?
How old is the existing telephony infrastructure?
What is its level of depreciation?
What are the recurring maintenance costs?
What is the level of expertise required on the part of support personnel for moves, adds, and changes to the infrastructure, and how long does it take to accomplish them?
How are phone calls made within the enterprise?
How are phone calls made outside of the enterprise?
Is the enterprise a single building, or does it encompass multiple locations?
Are the calls between the locations toll or local calls?
Is a private data network between the locations already in place? If so, what is the capacity of that network?
Is the network perhaps already multiplexing traditional Public Switched Telephone Network (PSTN) lines with data?
Does the SMB have a sufficient number of lines for outside calls, or do employees run into problems when attempting to dial out?
Does the SMB know if the customers calling in get a lot of busy signals because of an insufficient number of lines, or is it easy to get through?
What are the features of the current system that are most frequently used? Are there features that nobody uses? If so, why? Is it because they are too difficult or cumbersome to use, or are they simply unnecessary?
Is there a list of features that users deem desirable that are not available within the current system?
Telephone service is considered a common utility, and overhauling any kind of utility represents an overhaul of an element of the business infrastructure, which can have a significant impact on business operations. When considering IP Telephony, the issue of Voice over IP (VoIP) inevitably comes up. Although IP Telephony is closely coupled with VoIP, to the point where the two expressions are often used interchangeably, there is a difference between them.
VoIP is the enabler for IP Telephony. VoIP represents a technology that encompasses numerous protocols and standards from the Internet Engineering Task Force (IETF) groups and from the International Telecommunications Union Telecommunications Standardization Sector (ITU-T) to allow the transmission of voice traffic over a packet-switched (IP-based) as opposed to a circuit-switched network. IP Telephony refers to the utilization of VoIP to create telephony systems with many advanced features that are not available in traditional circuit-switched telephony installations.
In the context of more than a century of telephony history, VoIP is a relatively recent phenomenon—it is a newcomer that dates to the mid-1990s. However, since its inception, there has been a general consensus in the industry that VoIP has progressed through at least three generations and that its impact has been felt widely in both the carrier and the enterprise markets through ever-more-sophisticated IP Telephony solutions, which are discussed in Chapter 8.
Partner Collaboration Design Considerations
The following questions are just some of the queries that you will need to address to develop a direction for deploying a collaboration solution:
What is the business value of collaboration with partners?
What exactly is the manner of the collaboration that an SMB envisions? Is it a matter of one of the following?
***begin indent***
Providing partners with remote access to internal proprietary tools or knowledge databases on the SMB's network to facilitate problem solving related to the SMB's products that the partners support
Having a team of individuals drawn from a group of partners being able to work together effectively for a short period of time on a marketing or an engineering project
Setting up an e-mail list to enable the required collaboration
***end indent***
Is the use of e-mail without even setting up a special list adequate?
Does the collaboration require exchange of design documents that are subject to strict version control?
Usually, a collaboration solution with business partners, vendors, or even customers boils down to providing them with appropriate access to some of the SMB's internal resources. That, in turn, can ease the pressure on the SMB's personnel to interact with the relevant parties over the phone, via e-mail, or in person.
The key issues to consider when granting access are as follows:
What is the level of access to be granted to the partners?
Does the resulting increase in the SMB's operational efficiency and the savings in personnel time sufficiently offset the resources required to set up the appropriate access levels and to offer the necessary training and technical support to ensure that the setup is being used effectively?
By definition, providing varied access levels from the outside to internal resources implies having to consider the issue of security, which in turn implies a security solution. And the implementation of a security solution should be subject to a security policy. The process of developing a security policy is discussed in Chapter 4.
The mechanics of enabling collaboration with partners, vendors, or customers could require setting up a server on one of the SMB's demilitarized zones (DMZs) or providing virtual private network (VPN) access to the SMB's internal servers residing on the private network. It is entirely possible that SMB's personnel might already have a VPN set up to access the internal network. If VPN access is offered to partners, it becomes a matter of configuring proper authentication, restricting authorization to the relevant resources, and periodically generating reports about their activities. Setting up access to a DMZ server could also take place via a VPN. Alternatively, it could be set up in a more open way, where everyone has access to that server but must log in with a password. More open access to the server on the DMZ could result in greater reliance on the server's operating system (OS) security features to protect it from being breached, which implies that the OS's security level would have to be consistent with the SMB's security policy.
Customer Care Design Considerations
What is the value of an effective customer care solution? It is the lifeblood of a business! Any self-respecting business is well aware that without properly caring for its customers and offering them value for its products and services, it is not likely to stay in business for too long. But what exactly is a customer care solution? Customer care solutions vary as a function of business size and sector.
However unique or standard a customer care solution turns out to be, it is generally enabled via the networking infrastructure. The solution could be as simple as having a well maintained website with routine updates about a company's products or services. The website could be further enhanced with online ordering capability and spruced up with regularly updated links to URLs deemed of interest to the customer base. Customer care might mean regular communication with select customers via e-mail about special offers. Or it could require an IP-enabled call center offering 24\7 technical or problem-resolution support. It could also call for access to internal resources as a function of the customers' relationship with the SMB. Those resources could be digital documentation, technical information relating to the purchased products, or downloads of software updates or bug fixes if the SMB is a software vendor.
Just remember that a key design consideration for any customer care solution is its ongoing availability after it is released to the customer base. If a customer care solution is offered but it is unreliable because it does not work well or it is routinely unavailable, the situation can lead to a high degree of frustration on the part of the customers and can ultimately defeat the very purpose for which the solution was developed.
Front Office/Back Office Integration
Perhaps you are wondering what front office/back office integration has to do with networking solutions to begin with. It is simple—think applications. As mentioned earlier in this chapter, the network routing/switching infrastructure, as well as any of the other networking solutions (security, remote access, or wireless), must support and integrate well with the existing or planned applications.
The applications that customers "interact" with directly that relate to sales and marketing are customarily referred to as front office (facing the customer) applications. Those applications could include order entry, customer profiles, or general account maintenance in a call center or via a self-service, web-based interface. The applications that support the processes that are not directly seen by the customer (order processing, production, inventory control, or other accounting functions) are typically considered the back office applications. The back office applications are also referred to as the enterprise resource planning (ERP) applications.
What is the value of having the front and back office applications integrated into an effective customer relationship management (CRM) system? That is the question that the SMB's executive stakeholders need to answer. Making that decision will probably be a far more complex process than deciding to deploy network security or remote access. However, if the SMB decides to proceed with a custom, in-house integration or an off-the-shelf CRM solution, it must ensure proper connectivity between the relevant locations and sufficient bandwidth and processing power within the networking infrastructure to allow for the exchange of data generated by the CRM solution. Although it might not be absolutely critical for you to understand the specific functions of each of the applications, it is critical to understand the load that they place on the network and their security features.
The integration process might also require a specific functionality, like the support for multicasting within routers and switches or the addition of wireless LAN because a portion of the CRM is useless without the wireless mobility. From a security perspective, with integrated applications, the level of granularity in access and authorization becomes far more critical than with standalone isolated application islands.