by Richard Maring
The idea of computer networking is new to some people and almost always seen as a highly technical and rapidly evolving process. Every day, computer professionals are called upon by their employers to evaluate, judge, and implement the technologies necessary for the rapid communication of dissimilar groups in order to enhance productivity or lessen complexity within the organization's processes. Most see the task as a formidable one, and many feel they are not qualified or fully prepared to drive the creation of a Local Area Network (LAN) or Wide Area Network (WAN). The purpose of this chapter is to break this creation process into small digestible chunks, giving even the most inexperienced a blueprint for success.
Let's start with the term networking. Networking can be defined as a pathway. The term "network of tunnels" is an example. Networking is by no means a new concept or one exclusively restricted to technology. Whether it be a network of railroads or the telephone network, the same image comes to mind: a pathway by which something is transmitted. Thus a computer network is an electronic extension of the same concept. The purpose of a computer network is to link two or more "clients" together in order to exchange information.
There are three basic rules without which no computer network could be created. Although these three rules may seem trivial, they are the cornerstones for a successful development initiative.
In order to do computer networking, you must
2. Speak a common language.
3. Determine the rules for a dialogue: Who talks first? Who responds? How are errors handled?
The majority of problems that most existing networks face are based on design factors: either they were ill-conceived or they were not proactively designed to allow for the existence of growth. Design is the most important ingredient if a network is to meet all the necessary milestones for success. Regardless of how limited the business requirements are or how many networks your group has built in the past, approach each new network as a challenge. Cutting the design time a week to shorten the schedule could add four weeks of re-engineering at the end of the project.
Documentation follows as a close second to design as a critical part of the network. Not only does the documentation validate the effort and time you put into the project, it also provides a built-in "sanity check," always setting the tone from the start of the project to its fruition. Proper documentation can save untold time just as a means to eliminate the endless routine of searching for that one piece of critical information necessary during a physical failure or preplanned upgrade. If the network has grown beyond the capabilities of your current IS department, documentation will provide the evidence to justify the increase in budget to gain the necessary resources and manpower.
As an additional primer to give the inexperienced a chance to test their decision-making skills without costing their companies untold amounts, included in the next section are three different company scenarios, allowing the reader to experience each step for themselves and evaluate their decisions. In computer networking, there are no "right" or "wrong" decisions, only "better" and "easier" implementations. What is listed in this book is one interpretation; critique it for yourself. It will be good practice should your IS group ever be called in to do a network upgrade of an existing system.
The purpose of this chapter is for you to gain enough confidence with the basic ideas and concepts of networking to make informed decisions. There are numerous books that devote several hundred pages to what will be covered in these few. Although not all the possible answers can be explained, if you walk away asking the right questions and know where to go for the answers yourselves, then your time spent on this chapter is well used.
Make it a practice to carry a highlighter with you to place emphasis on what elements must be applied to your design as you take notes talking to your user community. Non-technical people will often approach the idea of connecting their companies together from a business perspective. They will tell you what they want and what capabilities they feel would be good to have. It will be your job to determine what they really need and what the limitations of the technology will allow for their organization.
You are a new hire as the third member of Acme's IS department. The 73-year-old company is expanding at a rate of 120% this year compared to last year. Due to the overwhelming demand for their products, Acme would like to implement a computer network to connect their corporate office with their remote offices and speed up the turn-around time necessary to distribute their products. Acme's president, Wallace Kiote, has an "old school" mentality, feeling that automation is unnecessary, and he would have preferred increased manpower to handle the new influx of orders. After discussing the idea with his Board of Directors, he agreed to provide the resources necessary to implement a limited network connecting the corporate office with two of the busiest offices. If this goes well, the total connectivity of the 11 offices will occur.
Acme Industries still uses typewriters and hand-processes every order. Their customer support center, although quite organized, has difficulty researching every problem presented to them in a timely manner. They spend a small fortune on the use of mailings from office to office. For important correspondence, they often rely on couriers to hand-deliver the materials.
Each department has its own internal hierarchy, having developed its own way of doing things as the departments have evolved. Although the departments do not resist the new technology, they are aware of the potential of possible problems or errors that they do not have in their current system.
| Company Name: | Acme Industries |
| Employees: | 217 |
| Locations: | 3 (1 corporate office and 2 remote offices) |
Your neighbor approached you during a cookout in the park. He heard you were into computers and wants to know if you would be interested in setting up a small network for his law office. He has a computer, as does his secretary. He wants to link together his other two partners in the firm who still write their case briefs by hand. He has two legal assistants in the field who fax him progress reports as they work on a case. He wants to connect all these people together and streamline his organization more effectively. He stresses that in his line of work he needs a secure computer environment where no one except the six of them will have access to their files. He tells you that only he and his secretary are fairly "computer literate."
| Company Name: | Linux, Dynix, and Ultrix--Attorneys at Law |
| Employees: | 6 |
| Locations: | 1 fixed at main office |
| 2 in the field on assignment |
You are a member of a 20-person IS department working for a multimillion-dollar health insurance brokerage. Your company has recently bought out a smaller competitor, and your purpose is to integrate the new company's existing network architecture into your own, allowing total communication between the two branches. The competitor's computer environments are using 8-year-old technology, and they were paying support to a company to maintain their custom-made proprietary systems. Each of the competitor's remote sites were using whatever technology they independently budgeted for. The sites range from a site with just a simple word processor to one of their larger remote sites, which had a small network installed. Upper management wants you to take a design team into the field and analyze the hardware, time, and money necessary to move the new holdings up to the company's standards. The personnel from the smaller company were retained; they see this acquisition as a good thing and will do whatever is necessary to work with the parent company. Management wants the acquisitions absorbed as soon as possible so they can incorporate their new patient files into their existing database.
| Parent Company Name: | Best Care Inc. |
| Parent Employees: | 600 |
| Parent Locations: | 8 (1 corporate office and 7 sales branches) |
| Child Company Name: | Better Care Inc. |
| Child Employees: | 418 |
| Child Locations: | 6 (1 corporate office and 5 regional offices) |
These three examples, while not the norm, provide a good cross section into the obstacles you would face going into a completely new situation. Each scenario presents its own challenges with multiple resolutions depending on what criteria your design stresses. For someone who has never done networking, they may seem unrealistic.
However, these three cases are actually based on jobs I once worked on at one time in my career. When I was learning networking, all the examples I read were these perfect, neat environments where everything pointed to one solution exclusively. To be good at networking, you need to be well informed of the technologies involved, and you need to be creative enough to adapt to the situation as it presents itself.
The design team is a logical breakdown of areas of responsibility that need to be addressed in order for each major piece of a network to be developed properly. Note the emphasis on the word logical. In many cases, one or two people will fill the roles of several of these areas of responsibility based on the relative simplicity of the network design or the lack of IS resources to commit to the development. Either way, remember to place equal emphasis on each of the areas of responsibility, for a lack of focus in any one area of responsibility could weaken the whole network.
The areas of responsibility are as follows:
Project Management
Business Responsibilities
Networking Responsibilities
Hardware Responsibilities
Applications Responsibilities
Security and Reliability Responsibilities
Training Responsibilities
These areas of responsibility listings do not always cover all the uniquely possible design events that might occur; however, the breakdowns show that appropriate coverage of all areas of responsibility is necessary in order to maintain an understanding of all the factors involved. Once again, as mentioned above, these areas of responsibility may rest on the heads of a few based on many factors. Personnel, money, time, and other factors may make one to two people responsible for covering all of the areas.
Now that the design team is assembled, it's time to go to your customer and determine what his actual business needs are. Remember, the users that are polled to provide requirements rarely have the technical background that you have. They will usually speak in terms of the business side of the corporation. Before even speaking to the user community, take along this list of important topics. Although the topics will not be discussed directly, the design team should be able, at the end of the meetings, to meet and determine all the necessary components for the functional design. The key points are as follows:
- What does the company do?
- Why do they think they need a network?
- What divisions/departments would be impacted by the network?
- What is the projected growth of the company?
- Are new divisions/departments planned to be developed in the near future?
- Where does the company see itself in one year? Five years?
- How will the network impact and improve user performance?
- How will the network allow users to grow within their current roles?
- What type and amount of resources must be available to each group?
- What are the levels of security within the company?
- Are there different levels of security when dealing with outside sources?
- What is the physical security in the company?
- If the company had a major network failure, what would the impact be?
- How fast does the network need to be repaired in the event of a failure?
- How critical is fault tolerance and redundancy for this network?
- Does the company have an existing network?
- Can that network be successfully upgraded or retained?
- What would be the impact of replacing the legacy network?
- How much time and resource management is necessary to maintain the network?
- What level of network management does the company expect?
The first step when venturing to a site location is to obtain an organizational chart of the corporation both at that location and for the whole corporation. This will usually give you a tentative breakdown of each site as most branches are set up with specific departments in mind. Focus on interacting with the layer known as middle management. These are the people who understand the purpose and vision of the corporation and at the same time can provide information as to daily operations and procedures. Make sure you ask questions as necessary to break the discussion down into as simple a workflow design as possible. The objective is to understand enough of their and their department's job function to make educated decisions as to what equipment they need.
Try if at all possible to have only one person from your design group interact with each department. Define these people as the support liaisons for their respective departments.
It's often easier, especially in large design initiatives, to break the network down into smaller pieces in order to focus on the user's needs more effectively. My recommendation is to make each location its own little site. Everything that connects the sites together is considered a WAN link. Everything inside the site is considered a LAN link. Because of the differences in technology and speed between WANs and LANs, this approach is usually best to spot inherent weaknesses in the design.
All the background information has now been gathered, and it's time to design a logical map of the company's proposed network environment. A logical map helps one understand the potential bottlenecks as well as what the areas of relative performance need to be to provide consistent performance evenly across the network.
This map is often designed at a high level, and then attachments are added to the map that logically map each site in greater detail down to individual segments.
The way I design a logical network like this is to draw out the logical map and print out three copies onto clear transparencies. Each transparency will hold a different segment of the network, and when they are held together, they provide a comprehensive guide to the network's logical flow. This way, each layer can be analyzed individually and optimized based on budgeting and time constraints to provide design alternatives. Figure 24.1 provides a possible logical mapping of the three scenarios described.
FIGURE 24.1. The logical mappings for each of the scenarios.
Whereas the logical design deals with the transfer and flow of information, the physical design deals with the logistics of users and resources. Questions like the following will commonly be asked:
If at all possible, get each location's floor plan to help not only with the physical design but to aid in capacity planning for personnel and equipment. Once all the physical questions have been answered, draw connecting lines on the floor plan showing potential cabling pathways. Be aware that these connections may change repeatedly based on your choice of network model, network media, and the sophistication of the network's connectivity hardware. The hardware and network specialist usually work on this map as it deals with concrete physical equipment. Figure 24.2 gives a breakdown of each scenario with example remote offices for reference.
FIGURE 24.2. An example of a physical mapping.
The network model is a set of implementation standards around which the network you design is built. Every network ever created follows one of these models; they govern where data is stored and define the information pathways from which the data is accessed.
There are basically four models that are currently being used in the network world to deliver applications and information to the user community:
This model was the first of its kind and still popular today. It focuses all its resources into a server that handles all the data manipulation and storage for the company. Each user will "query" the server using video terminals or diskless workstations in order to start processes running on the server. Some advantages and disadvantages of the mainframe environment are listed here:
- Single point of failure on the server.
- No need to upgrade client workstations in the field to support new applications.
- Server can become a bottleneck if its resources are overtaxed.
- The server's proprietary solution may limit upgrade and expandability.
- Security and physical access to the server can be maintained easily.
FIGURE 24.3. An example of a main-frame environment.
In this age of connectivity and information sharing, the client/server model has surfaced as perhaps the most popular and technically scaleable model available today. The basic premise is that of a main server similar to the mainframe environment. However, the server is simply used to provide applications and space to hold the data generated. All processing is done on the client workstations as a way to bypass the potential bottleneck caused by an overtaxed server. Some advantages and disadvantages of the client/server environment are as follows:
- Involves more planning than the other models.
- Client workstations can function even if the server is not present.
- When an upgrade occurs, each workstation must be upgraded as well as the server.
- Security can be an issue if all critical data is not kept on the server.
- Scalable to an enterprise level.
FIGURE 24.4. An example of a client/server environment.
- Cost-efficient due to the lack of a dedicated server or connectivity hardware.
- Workstations must be left on to access all the resources available.
- Lack of a centralized administration or security.
- Not scaleable to larger networks.
- Each machine has the potential of failure, crippling part of the network.
FIGURE 24.5. An example of a peer-to-peer environment.
- Cost-efficient in an LAN\WAN solution.
- Easy to install and deliver new versions of applications without visiting each client's workstation.
- Single point of failure on the Web server.
- May require multiplatform support.
- Security issues have not been reliably defined across the industry.
- Good for low-bandwidth or high-traffic environments.
- Integrates into the existing Internet.
FIGURE 24.6. An example of a Web-based environment.
When you have reached this point in your development process, there are three important areas that merit careful consideration. First, you must choose the various applications your network will use. Second, you must decide upon a network operating system. Last, but not least, you will finalize all your decisions concerning hardware requirements.
The network model will drive the location and types of applications needed to meet the users' requirements. However, the following basic guidelines/areas must be adhered to:
After you choose the preferred network model and the list of application options that you and your users feel are necessary, the intersection of these two sets of data should lead to a list of potential network operating systems (NOS). Issues to address are very similar to those of a application perspective, including:
Be careful not to get trapped in a proprietary NOS solution, which only supports hardware, software, and services all coming from one company (Apple and IBM during their heydays are examples of these principles). Although the level of functionality between the software and hardware is higher, you end up paying more due to a lack of competition. Also, if the company's support services do not adequately meet your network's repair and functionality needs, there is no other place to get support. In most cases, the NOS will be the one that either the company currently has running as a different site or one that the design team agrees on as the best choice.
Hardware requirements constitute three classifications:
Server hardware is determined by the Network Operating System that is selected. My recommendation is to always go with the industry leader that is well supported. Some system administrators try to push the envelope and buy the absolute fastest, coolest, most feature-packed hardware they can find. Always make sure that the hardware company has updated drivers for all the hardware you purchase on the NOS that was chosen. Check to see how they handle problems and if the hardware vendor has any known incompatibilities with any other hardware.
Whereas server hardware was based on the NOS, workstation hardware is based on the applications that will be run on them. I usually recommend that when you choose a workstation solution, you test it thoroughly to work all the compatibility and functional bugs out of the planned desktop setup. If a choice of components is given, stick with the companies who will be providing your server hardware as a point of guidance. When I select a vendor, I usually have them create specifications for three different profiles: the average user, the power user, and the developer. If at all possible, get these three systems in house and try to "break" the desktop setup. Ask the following questions during the assessment to validate your findings:
The final point to cover is that of the peripheral hardware. This is usually driven both by the business needs of each department as well as the physical site map. An example of this would be that there is a need in a department for a printer. Based on the business needs of the group, the relative complexity/expense can be determined. (Does it need to print graphics? Does it need to be high speed? Does it need to print color?)
Once a specific series of printer is selected, the model can be selected by the number of users who are going to be physically using it daily. The physical map also allows physical placement of the printer to make it accessible to the greatest percentage of its user community.
Although there are many little details in the selection, validation, and finally implementation of system hardware, follow the standards, and don't be afraid to ask a vendor to describe in detail the standard their products support. Just be aware that their job is to sell their product, so analyze everything they say carefully and always get a second opinion from other sources as necessary.
This step is often left out due to either budgeting issues or time constraints placed on the implementation. Depending on the simplicity of the design or the ability to modify the network design while in production, this step may not be necessary. It is recommended usually as a second check to verify that what the hardware and software vendors specified as far as compatibility and performance was correct. This step can also be utilized to allow users the first look at the functionality of the applications to gauge their reactions to the implementations. Various pieces of hardware and software can be "swapped" in and out of the test laboratory in an effort to find the optimal configuration. At this point in your process, it will be necessary to allow users a chance to see and possibly use the beta systems you put into operation in your test lab. However, make sure you explain to the users that the speeds and operations being attained may not necessarily be the same as what will occur when the actual network is assembled. No matter how effective you are at putting together a test lab, it can never duplicate the "real thing." However, it is a good idea to ensure all the pieces of the puzzle "fit" together and work with each other the way they are supposed to.
The test laboratory is also a useful staging ground for training support and installation personnel who will aid in the implementation effort but are not part of the support team. Although written documentation can sometimes be enough for a remote site to upgrade their systems, it is often more beneficial for the support person to visit the test lab and do an entire installation/upgrade from beginning to end. This allows the support professional to ask any questions or address their site specifics in detail. These extra little details may provide more insight and help to focus the testing initiative.
As a basic test lab design, set up two individual subnetworks with a router or bridge linking the two together. Place two workstations on each of the subnets to be used for application testing/benchmarking. One of the workstations will be set up with the standard user client profile, and the other will have network monitoring/sniffing software installed on it. This allows for passive monitoring, which will not impact network traffic and cause the monitoring software to read more traffic than what is really on the segment. Figure 24.7 gives a logical diagram of such a test network.
FIGURE 24.7. The test laboratory.
After the final configuration has been determined, it is sometimes desirable, especially in larger networks, to evaluate the bandwidth needs in order to determine scaleability and in what places network devices (routers, bridges, gateways) should be placed to load-balance the potential traffic. To do this most effectively, connect a network protocol sniffer to the test laboratory and run the applications from different workstations, first singularly and then together, to gather preliminary time and bandwidth needs. Based on this data, the following questions can be answered:
With these questions answered, you can define options to limit application activity to the area where it is used in order to limit performance degradation across the entire network. If you determine that an application that is very bandwidth-intensive will be run all day across the whole network, it may be best to add redundant routes within each segment to allow the delivery of packets more effectively to the server.
The other chapters of this book will do a good job educating the user as to the various connectivity hardware options (routers, bridges, gateways). Instead of going over the definition of these tools, I am going to go from a design perspective and show where the hardware should be implemented based on the network traffic patterns. Start by going back to the instructions in the section "Breaking Down the Network." A network device will primarily be placed where the LAN areas meet other WAN areas. This will keep all local packet traffic within each area or segment and allow only the traffic that needs to traverse the WAN link out. Connect the transparency that you created in the section, "Creating a Logical Design," with the application benchmark and bandwidth data captured according to the instructions in the section, "Evaluating Bandwidth Needs." Place additional network devices within every LAN segment based on the three criteria defined in the section, "Creating a Logical Design." If the data needs to be fast and the application takes up a lot of network bandwidth, perhaps the segment needs to have a switch or multiple routes to get from point to point. Ultimately, the purpose of connectivity is to meet the needs of the user community. Just remember, the more devices that are implemented to enhance performance, the more that need to be configured and supported.
I have included the following guidelines from my experience as a way to aid in the decision as to whether to implement a router or a bridge for a given network situation. Even experienced networking specialists will argue among themselves as to what the best implementations are.
Throughout this chapter, the emphasis on documenting and drawing the networking structures has been obvious. At this point in the creation process, the design phase should be completed. The whole network should be laid out with knowledge of both the needs and expectations of the user community as well as issues of support, performance, and reliability. It is time to pull all the research and documentation together in order to prepare a business proposal that allows the project manager to educate the management of the company as to its needs and the final results to be expected. Go back through each of your pieces of documentation starting with the first one. Was there anything you would like to change in the design based on what you learned? Are there alternative solutions that will meet the needs of each step more efficiently or more cost-effectively? Before finishing the final documentation, revisit the options and redesign the whole network as necessary. It is better at this point to lose time redesigning than to be caught in the middle of an implementation that does not meet all the users' needs. On each step, add additional documentation as to why each specific choice was made and what the alternatives were. In most cases, before management will provide a budget for the project, they will interrogate the project manager as to how he determined the best solution. Make sure the project manager has plenty of information to support the team's decision.
At a minimum, the documentation should include the following:
Once all the data has been documented and collected, it is time for the final project design meeting. The topics of cost-effectiveness and determination of rollout method should be discussed in great detail from all members' perspective to get an overall view of the necessary resources that need to be made available. The following is a list of usual weaknesses in an implementation plan that could be missed. Consider their impact carefully before presenting the final plan to the management of the company.
Once the project manager feels secure about all phases of the implementation and that all issues have been properly addressed, the manager will present the findings to the management of the company in order to get proper funding for the purchase of equipment and additional manpower to complete the implementation. The project manager must present the findings using the most English-like language and analogies as possible to convey the message. Management may not always have as much computer literacy as you would like. Make sure to emphasize the benefits in productivity both in the time saved by using automation as well as the security and greater reliability.
Go through the documentation packet, educate the management as to why that is the best choice for each level and stand by the decision the group delivered. If money in the budget becomes an issue, present them with the possible alternatives and make them aware upfront what the negatives to the alternative will entail. Have management sign off on the official proposal in order to place responsibility for the project in their hands.
Once management signs off on the project proposal, the design team shifts focus to plan, prepare, and implement the rollout schedule. The first phase of this rollout schedule is to select a beta test site in the field where all the systems that were designed in the test laboratory are field tested. If at all possible, try to set the first site near the test laboratory in case there are inconsistencies between the two sites. When engaging in a beta test site, always provide the user group with a comprehensive description of how the system works as well as polling them periodically to get their feedback on various facets of the network. These users will not only be able to provide valuable information as to how well the network design meets the business needs, but they in turn will reinforce the points that were made to management when the project's budget was approved. Key points to emphasize and discuss with the user community during this initial period include
Give the users time to adjust to the new system while you are compiling the results of the preceding questions. If any major or obvious problems appear within the system, repair them and update the systems for the beta test site. An important thing to note is that no matter how well crafted the network is, the users will always ask for more and more functionally. The need to determine a cutoff point is important to the success of the project. After this "stable" platform is configured (usually takes at least two weeks), follow up the finalized survey before proceeding to the next phase. This survey will provide more personalized points including
The first set of comments meets the technical needs of the network, allowing the improvement in the design and functionality. The second set of comments provides insight as to the amount of user training and future enhancements that may be addressed in future releases. Remember, with the implementation of any type of organized or automated system, the effort levels to do the hardest tasks will usually be reduced from days to hours. This extra time can directly enhance the productivity of each department.
If the beta test site is a successful installation and both the design team and the beta users feel that the implementation goals were met, then the next move is to create a standards sheet for the installation and maintenance of the new network. This allows groups other than the design team to install, troubleshoot, and maintain the new network. Opinions vary as to whether this milestone is really necessary because it does not directly impact the project. Standards are most useful for connecting to external networks outside the one that is being designed or in the case where an existing internal network is being upgraded. If the network will lack a centralized IS department, opting instead for an onsite support person who will maintain that piece of the network, then standards allow the support person to communicate effectively with the other members of the support structure in the case where a problem or difficulty is beyond their comprehension or technical competence. Based on the feedback from the user community when the entire project is done, the standards provide a valuable framework on which current design considerations can be re-evaluated, and the next network upgrade will have a baseline for installation.
The following list gives some specifications for a standards document. Based on the level of security, replication, or the variety of technologies on each site, these specifications will help with the selection of vendors, determine important network administration roles, and preserve/enforce a consistent plan for all future changes to the network.
Systems make and model (list all three systems separately)
CPU
Memory
Hard drives
Monitor Network interface cards
Systems make and model
CPU
Memory
Hard drives (list redundancy methods: mirroring, duplexing, RAID level) Network interface cards
Make/model of peripheral
Site-specific settings Interfaces used (serial, parallel, proprietary)
Operating systems supported
Memory requirements
Space necessary on workstation
Space necessary on server Site-specific configuration parameters
User naming conventions New hire/termination guidelines
Volume naming conventions
Directory structure (applications, user directories, department directories) Directory size restrictions (these are optional)
Server naming conventions Routing and gateway information
Password restrictions
Login hours
Department rights/login scripts Auditing (file, directory, user)
Standard naming conventions for problems/resolutions Take all the standards information and bind it together to form a notebook that contains all relevant information from the preceding list. This will help to isolate/troubleshoot complex problems as well as dealing with purchasing and replacement (RMA) issues. Keep it at the same location onsite where all the server equipment will be kept. Add the following to aid in the event of problems:
"Network administration" is usually a catchall phrase that encompasses every facet of the network's user/group and file/directory setup and maintenance. Although the term network administrator usually carries the same meaning in most network environments, network administrators are very different from site to site.
All have different levels of technical skill and job experience. The best that you can hope to achieve is consistency in the administration practices. Whereas the previous section dealt with issues and standards to consider when implementing the network, the network administration section deals with applying those standards. The following is a list of responsibilities that fall into the network administration phase:
Although this list may lack other job functions found at existing sites, it comprises a general area of user and system-based responsibilities that must be instituted to maintain the site's integrity.
A network is no good if it is not running. The company spends money to design, develop, and propagate its usage; if it is not running or there is a failure, the network is useless. To combat this, develop a strong disaster recovery and maintenance plan. A typical disaster recovery plan will include
These issues, even though they might seem trivial or outrageous, are the key to both protecting the network and the career of the network administrator.
The way a failure is handled in a properly planned and documented network is as follows:
There is a serious failure, but the person who found the failure documents what has happened. What is the level of severity? Is the failure in the software or the hardware? Additional on-site support people are pulled from their other duties as needed to combat the failure. The support group consults the disaster recovery plan to review the options in the event the problem cannot be remedied immediately. A call to management is made making them aware of what the situation is and how it will impact the environment. Management is told what the support personnel are in the process of doing and what realistic time schedules for network restoration will be. The company has invested in critical replacement hardware and has it onsite in case of total failure. If an agreement has been made with the vendors, the vendors will provide support in a preset timely manner and report the status to management as necessary. The network is restored, and management feels that they were kept informed. The problem is handled effectively, and there is no wasted effort or miscommunication.
The bottom line, when dealing with equipment that is used in a production environment, is that failures can occur. They may take a year to manifest themselves, but they will occur. It is better to plan for them and define clear guidelines as to how they will be handled before the system is even implemented. If the development team has determined that additional equipment needs to be purchased to provide a better response time, the requests are taken to management and approved as management decides. In the event of a failure, the decisions management makes will be the level of support that can be provided. The better the network functions, the better the IS department functions.
Not all problems that occur on a network will be covered in the disaster recovery plan. If a user's printer jammed or they cannot connect to the network, the network's productivity does not stop, only the individual user's. However, if enough problems occur and the users do not feel that their needs are being met in a timely manner, a user's perception of the network and the IS department is impaired. Even if the users just have questions about what they are doing on the network and need reassurance, they have to feel secure. Always create a tracking system and have support people prepared to help. A problem tracking system can be as simple as having a central number that all users call if they have problems. A secretary enters the information into a database or simply writes it down on a trouble form and sends the "trouble tickets" to the support group who follow up with the users, based on their availability and the severity of the issue. It does not need to be sophisticated, but it has to be there when the first users in the field are installed. Within the user manuals are procedures for the users to follow in the event of a problem. These should be emphasized to make sure the users feel comfortable with the procedure.
The following is a list of suggested fields that should be included. Each environment is different and depending on the availability of support personnel, whoever is taking the call should be able to selectively screen the problem to keep the IS people from doing nothing but handling problems all day. The fields include:
It's important to track these problems. Databases are always useful because if the tickets are entered using a standard naming convention, then a count of failures of a certain type can be made and a trend analyzed. (Is certain equipment faulty? Are there factors in the application's stability that were not determined during testing?) The analysis could lead to decisions being made for future upgrades or network environment replacement as necessary.
The other element often overlooked is one of effort. At the end of the year, if the group is running around trying to handle a workload of problems and not getting anything else done productively, then more personnel may be needed. By polling the database and determining the person-hours spent in support broken down by problems in a monthly basis, it will show management the commitment to the user community and the need to continue this commitment by allowing the hiring of additional personnel. The IS department group is often seen but not always heard; in most cases, someone in management will try to determine if all the expensive skilled manpower is really necessary once the network is stable. Consider the problem tracking system as job security.
This section more than any other is one of communication. An implementation is like a battle. The purpose of the battle is to place troops and equipment at key locations to create an "information supply line." The opposition is the user community, whose ignorance of technology and focus on current systems make it difficult to gain ground quickly. Consider the following "battle plan" before deploying the troops and resources:
With these basic factors in mind, every implementation will occur seamlessly and all problems will be dealt with before they escalate into crisis.
Although most sites decide to send their personnel offsite to handle the issues of training their workforce on the new network and the applications run in it, this is not always necessary. Based on the feedback from users who participated in the beta test site, the development team should have an idea as to what problems the average user might encounter and be able to both offer tailored internal training as to the operation of the new equipment as well as answering common questions the users might have. When the new system is being installed, it is often useful to provide each user with a user handbook that details their new desktop system and discusses issues such as
The important thing is not to overwhelm the users. It is often better to divide the applications into two courses instead of one. The first course will address starting the applications and using their common functionality. The second class will deal with the more advanced features of the application as well as issues such as troubleshooting and personalized customizations. About 80 percent of the users will be happy with the first class, allowing their experience to lead them into the additional functionality as they need to learn it. The remaining percentage will take the advanced classes. This group of people includes power users, developers, support personnel, and technical management who want to have an overall understanding of the application.
NOTE: If multiple departments are located at the same remote site, it is often useful to form user groups among the power users and developers at the site to allow for the free flow of information and aid.
How the network functions is different from its perceived functionality. If the users feel their needs were met, they will usually continue to work uninterrupted. If there is a problem, the IS department is the first to know. In a large user community, it is often very hard to determine how well the network is received. A need for feedback is essential to validate the network and determine any weaknesses or unplanned events that the original design team and design constraints did not take into consideration. Sometimes this feedback will take the form of accommodations for different departments as to how well the support team has performed. It could be that the users send their comments to their department head or manager who passes it to the IS manager. It could simply be an e-mail from a user to a support person thanking them for a job well done. Regardless of what form it takes, both management and the IS department need to know that what they had planned, designed, and provided is making a difference in the user community and if there are weaknesses or problems in the design, how they can be remedied.
The implementation has been completed. The users have all been installed and trained, and problems for the most part have been resolved. It's time to reflect on what was done and whether it could have been done differently. Have the IS department get together (success parties are a common theme) to discuss the different phases of design, development, and implementation. The project manager (or project leader) should take notes to determine the following:
Ask the group one final question, "If you were doing the same project now, knowing what you know now, what would you have changed?" Have each group member answer this independently based on their area of specialty. Then as a group collectively, determine what areas the group can improve upon for future upgrades/installations. The purpose of this type of "post mortem" exercise is to both learn from mistakes made and focus on the core set of success factors that make for a properly built network.
Designing a network from scratch is not an easy job. A lot of factors go into a successful network, and many are out of anyone's control. The emphasis throughout should be on documentation and communication. It is better to have a well-documented network that fails and needs additional resources than a network which, although functional, has an IS department afraid to touch it for fear that it will break and they will have no way to troubleshoot it. Many of the key points are not technical but organizational. The project manager is a pivotal figure in the entire scheme; if the project manager is not sufficiently prepared or does not have the necessary support from the group, the initiative has failed. Technical problems are rarely the cause of a network project's failure because everyone on the design group usually has a highly technical background and has learned the methodology to handle the technical problems. Never lose sight of the fact that the network is a tool with which the user community can become more productive. Productivity and reliability are always the ultimate byproducts of a well- functioning network, and a well-functioning network is the best scenario that can ever be achieved.
© Copyright, Macmillan Computer Publishing. All rights reserved.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}