IT-Documentation needs to fit your needs

Don’t fall for the hunter-gatherer trap! Try to consider what your needs are in the daily business, what questions you want to have answered and define a set of information that you need. Set this information as a baseline that is known not only by you but also your coworkers. If you document too much, you will never be able to keep the data up-to-date. Another drawback from collecting too much information is that important information might get lost within useless information, and you simply don’t find the information you want.


IT-Documentation needs to be planned and organized

Here are also two things to consider.

  1. Documentation takes time. So plan the time needed ahead and make this fact accepted in all your coworkers and bosses minds. There should be no arguing about extra time needed for documentation.
  2. Include your documentation in your processes and projects. There is a guide on how to set up new servers? Include the necessary documentation as a must do. New Exchange servers are being set up by third-party consultants? Inform them how to include these in your IT-documentation. Let them know the exact requirements you have.

Technical and Operational documentation

These two belong together. Have one place where you document both kind of information. Technical information is the minimum, but why and how something was installed should also be there.

Keep these information asset- and/or service-centric. If you are looking at an E-Mail server, do not explain the MX DNS records in the E-Mail server context, explain it in the DNS server context. If configuration information like this is connected, have an additional service documentation that explains how and why these configurations belong together.


But now hands-on

Let’s get the hands on the practical side. We start with different aspects that your IT-documentation can cover. After reading about the different parts below, you should be able to decide which aspects should be covered in your IT-documentation or not.

Physical Infrastructure

There is only one reason not to document your physical infrastructure.: If you haven’t any. It’s mostly very statical (so you only need to do it once) and in many situations you need to know where things physically are. The level of detail is up to you. If you have a large datacenter you might want to document your IT-components down to the rack position. If you only have a small computer room, you just document the room the components are located at.

Floorplans can come in handy when dealing with complex infrastructures.


Active components (Servers/Switches/Routers/…)

All active components of your IT-infrastructure should be documented in some kind of way. Set yourself rules for what information should be documented about what kind of hardware. As stated before: Set your own goals of which active components should be documented, if it needs to include e.g. mobile phones etc.

Information to consider when documenting:

  • Basics (Name, Location, Serial number)
  • The IT-service it belongs to/purpose of the device
  • Physical location
  • Hardware (Vendor/Model and Hardware Information)
  • Networking (IP-addresses, Subnets, Ports, VLAN, DNS, etc.)
  • Operating System (Type, Version)
  • Installed Software
  • Installed Server roles and services
  • Specific Configuration settings
  • Accounts and passwords
  • Access (URLs)
  • Backup Up (How?/Where?/Cycle?)
  • Contact persons (and responsibilities)
  • Accounting information
  • Warranty information / Support contracts

Step 3