Riordan Manufacturing is a global leader in plastic injection molding. It uses state-of-the-art design technology to create their world renowned designs. They have facilities in Albany, Georgia, Pontiac, Michigan and Hang Zhou, China. These facilities are connected to the main headquarters in San Jose, California through a Wide Area Network (WAN). The network design documents have been provided for analysis.
The design documents only cover the basic layout and components of the system. It is difficult to determine the age of the system and components from the documentation. The documents have the main components that are necessary for the basic functioning of the system such as the connections, servers, routers, hubs, and workstation. The system probably serves their functions at the present time, but is it likely to become obsolete soon. An examination of the components listed indicates that the system is using a HP BL460P blade server. The documentation does not list the exact model, but this server is currently on generation 9 (HP 2016). Only general information was given on the IBM HS20 blade servers in the headquarters, but the model listed seems to be from approximately 2005 (IBM, 2016). The design documents need to contain exact model information and the dates purchased so that their age can be determined without extensive research.
Considering age of the system, it is likely that many of the components are out of warranty and no longer supported by the manufacturers. The warranty for the IBM HS20 was found and was written in 2006 (IBM, 2006). Warranty and warranty expiration information would also be helpful in the network documentation, as well as any service agreements. When this system breaks, an exact replacement model will probably not be available. Old peripheral equipment will more than likely not be supported either. This mean an entire system upgrade. This system cannot be expanded to meet the company’s future needs.
The age of the system also suggests potential bandwidth concerns too. A cloud-based system would serve their current needs and be more easily scalable than the current system. It is unlikely that the current system allows for the fastest and most secure data transfer. A wireless system with the latest editions of servers would better meet their needs.
The old system has several security concerns. The first is that that it is not up to current standards. Although the satellite link uses end to end encryption, there is no firewall between satellite base and the gateway. Although end-to-end encryption is considered to be fairly reliable, it is not infallible. There is a concern that the entire system at each location is served by a single UPS system. This is not enough to protect the entire system in the event of a disaster.
The diagrams presented are composites. The text description only provides basic information on system. The reader of the material has to do extensive outside research in order to determine the models and age of the system. In order to determine this for certain, the reader would have to either physically examine the machine or have someone take a picture of it and send it to them. All of the information needed to identify the components should be listed on the network documentation.
Proper network documentation serves several purposes. The first is that it makes troubleshooting more efficient (Posey, 2016). Keeping proper documentation can alert the administrators to components that might need to be upgraded and will alert to things such as warranty expirations or the end of service contracts (Posey, 2016). In addition, should a data breach occur and the company face litigation over data compromise, the network documentation would be the best defense (Posey, 2016). The company could prove that they took the necessary steps to protect data. In the case of Riordan’s documentation, the basic information provided serves none of these purposes. Network documentation can also be helpful in training new personnel.
The topology maps provided are only general. It would be helpful to provide more detailed maps, in addition to these general maps (Posey, 2016). The server names, roles, and IP addresses should also be recorded. A change log should be considered for each server in the system (Posey, 2016). It is not known if Riordan has one, but it was not provided in the provided documentation. The location of backup should be recorded as well, as well as backup procedures (Posey, 2016). The next step in the documentation process is to label the hardware (Posey, 2016).
Domain policies and protocols should also be in the network documentation. A maintenance and trouble log would also be helpful in the log. This could help the administrator spot common problems and how they are best resolved. This can also provide clues as to components that need to be replaced.
In the event of a disaster, the network documentation is expected to be the backbone of the recovery process. If the information provided is intended as the only source of network documentation, it can only be considered the bare minimum. It does not serve the intended purpose of providing a detailed account of the entire system and would provide little protection in the event of a real disaster. Network documentation needs to provide more than a general layout and list of equipment. It needs to be thorough and detailed. It also needs to be kept up to date and reviewed periodically. The example provided would only be a small section of an actual network documentation document. It barely provides the most basic of information needed.
- Hewlett Packard (HP). (2016). Quick Specs. HPE ProLiant BL460c Gen8 Server. Retrieved from
http://www8.hp.com/h20195/v2/GetPDF.aspx/c04380273.pdf - IBM (2006). Warranty and Support Information. Retrieved from
https://publib.boulder.ibm.com/infocenter/bladectr/documentation/topic/com.ibm.bladece
nter.hs20.doc/hs20_7981_warr.pdf - IBM (2016). IBM eServer BladeCenter HS20 blade servers. Retrieved from http://www-
01.ibm.com/common/ssi/cgi-
bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=EN
US105-01 - Posey, B. (2016). Ten Steps for network documentation: Channel checklist. TechTarget.
Retrieved from http://searchitchannel.techtarget.com/feature/Channel-Checklist-10-steps-
for-network-documentation
