Network documentation: Benefits and best practices

“Nobody reads the documentation.”

People who spend their time creating technical documentation hear that phrase quite often. It’s always nice to have your life’s work summed up in four simple words.

The truth is, nobody in their right mind sits in a comfortable chair with their favorite drink and reads a technical manual from beginning to end or glances through depictions of their company’s server rack for fun. Nobody reads documentation—until they need to. 

But, as you’ll learn from this article, there are many circumstances where network documentation will become essential in your organization. Learn what you should start documenting and what value you’ll gain from these resources.

What is network documentation?

Network documentation is a technical record of the hardware, software, servers, directory structure, user profiles, data, and how it all works together.

Network documents should include any information that helps administrators and IT professionals to keep the network up and running smoothly. This information can be in any format you want (although you’ll see that we recommend diagrams and other visuals for quick reference and improved communication with non-technical employees). 

What matters most is that the information is easily accessible and can be understood by all who need to refer to it. Using network diagram software can help visualize the current and future state of your network and allows you to create network diagrams according to industry standards.

Why do you need network documentation?

Consider the following scenario:

You have landed a good job with a great company as the head of IT after the previous IT head left the company to pursue other interests. When you start, you meet with your manager who tells you what is expected of you in this role. Your predecessor had done most of the groundwork for ordering new servers and software to run the network. You are expected to act quickly to complete the orders and implement the network changes.

Back in your office, you look for documentation that will help you understand the network’s current setup. However, you quickly find out that there is not much documentation other than a few notes here and there. There is no IT plan and nothing that describes current resources and architecture. You can’t find anything that justifies the request for new hardware and software.

It takes you more than three months to draw up plans and figure out where everything should go. How much easier would your job have been if your predecessor had taken the time to produce network infrastructure documentation?

Network documentation is important for the following reasons:

• Proper documentation can save you from time-consuming research to fix recurring problems.
• When everything is in place and everybody follows the same processes and procedures, consistency across the network helps to reduce problems and errors.
• You won’t lose important information when a knowledgeable employee leaves the company.
• The documentation helps you to onboard new hires much more quickly.
• You can troubleshoot your network faster when issues come up.

In addition to providing detailed documentation, you should also try to make it a practice to ensure that more than one employee has all the knowledge. That way, you are double-covered when your knowledgeable employee leaves because you have a reliable set of documentation as your backup.

What should you document?

Proper documentation should be created as you work. Don’t wait until everything is in place before starting to document what you’ve done. It’s much easier to document in the moment than trying to remember what you did later. Make documentation a habit and make it part of your process. Don’t risk potentially embarrassing situations because of the lack of network documentation.

But, what should you document?

Your goal with network documentation should be to ensure that your company retains all the knowledge that went into creating the network as well as how to maintain and upgrade it.

You should seek input from your IT team, other network administrators in various departments throughout your organization, and managers to determine what you should document. The following are just a few examples of the types of information you should record to help your network to stay in good working order (plus you’ll find templates to help you start your own documentation).

Network topology

The topology is the physical or logical map of your network. It lets you visualize how the resources in your network are connected. Knowing the topology helps you to determine where new hardware can fit in your network.

Cloud architecture diagram

Whether your organization uses AWS or GCP, these diagrams visualize the components within your cloud architecture. Cloud architecture diagrams can come in handy when explaining the current state of your infrastructure, planning a future state, troubleshooting, and demonstrating compliance.

Server rack diagram

This type of diagram shows the organization of equipment on your server rack, including components such as monitors, hard drives, power strips, routers, etc. Server rack diagrams can help you determine the size of rack you’ll need during the design process but also see where computers and other devices connect to the server when you’re troubleshooting.

Hardware directory

This directory documents the hardware pieces of your network and should include information about serial numbers and descriptions of physical configurations. This information helps you to locate and fix hardware problems that occur.

Software directory

This directory represents your software inventory. It lets you know where all of the software applications that are authorized for use in your organization are located, what the names of these applications are, on which computers they are installed, proof of software license for each application, and service level agreements for those applications.

In large organizations, maintaining a software directory can be a daunting task. But if you are ever subject to a software audit, you will be glad you took the time to document what you have, where it is, and how many licenses you have so you can prove that your company is in compliance.

Wi-Fi diagram

You may find it useful to document or diagram how your wireless network is laid out. The diagram can include:

• The number of routers, switches, and servers used in your wireless network
• A map of physical access points to help you track down problems
• Radiofrequency patterns
• Security measures such as employee and guest SSIDs

IP address allocation

You should keep a detailed list of internal and external IP address assignments to help as you design network expansions and recycle IP addresses to be allocated to other locations. Documenting your allocation process gives you an understanding of subnet size, subnet assignments, and the devices that have been assigned to specific IP addresses or to a dynamic range of addresses. This documentation helps you to define allocation standards going forward.

An asset management diagram can give you a bird’s-eye view of your organization. This customizable template can give your IT team a quick overview of employee location, asset tags, physical Wi-Fi access points, IP addresses, software installations, and so on.

Cable diagram

Documenting where and how the cables run through your building can help when troubleshooting and diagnosing network problems. The diagram should map jack numbers to physical locations.

Recovery plan

Do you know what you are going to do if you need to restore lost data? How do you preserve data from failing hardware? Do you know where your backups are housed? You need to document details of where backup data is located, how often backups occur, which type of data gets backed up, and how backups are accessed and restored to those who need it.

A step beyond a recovery plan, a fault-tolerant system is designed to give you uninterrupted service in the event that one or more network component fails. Even if you experience a catastrophic failure, the fault-tolerant system should let your employees remain productive and working without any knowledge that there has been a system failure. 

A fault-tolerance plan should include:

• An analysis of the business impact in the event of a failure.
  • Outline potential threats and the impact they may have on your business.
  • Assess how likely it is that these threats will occur.
  • Consider the effects if you don’t have a fault-tolerant plan in place (lost sales, lost productivity, lost development, and so on).
• Planned redundancies. Duplicating everything in preparation for potential disasters can be costly. Be sure to understand which business-critical assets and systems must start up immediately. Let the data and systems that are not mission-critical wait to come back online after proper fixes have been put in place.
• The location of your fault-tolerant system, whether in the cloud or on-premises.

Improve your documentation process

While it may seem like no one reads your network documentation, network diagrams are essential to understanding existing technology, communicating with stakeholders, onboarding new employees, troubleshooting issues before they escalate, and creating a vision for future innovation.

Get started with the templates above or learn more about how the Lucidchart diagram maker can help your team with understanding complex systems.