Modern Network Architecture

Mar 16 2013   7:57PM GMT

Documentation for IT Expert

James Murray James Murray Profile: James Murray

As a Seattle IT Consultant, I meet with IT departments on a regular basis.  When I ask, 95% of the time there is no documentation on the network.  I know I talk about this regularly but I’m working with fortune 500 client who is struggling with this very problem.  So I thought I’d talk about this subject again.  Recently, for example, I called in when the network is slow or there has been some type of catastrophic failure.  The first question I ask, “Do you have any documentation?”  The answer was (…and almost always) is  no.  I think that probably if the network was being documented, the network probably wouldn’t have failed.  Or they would have been able to figure out the problem on their own.  Still despite the stereotype (IT guys never document) I really don’t think it’s anyone’s fault.  I’ve spoken with hundreds of system administrators about this topic and very few have no idea where to get started.

This Post (and the following posts) is about getting you started on documenting your systems.  When documented properly, your network will never fail.  (Notice the caveat, documented properly.) I am working with another client who needs a knowledge management system for their network.  I was once again reminded that documentation is truly a problem in our industry.  I’ve put together some principles for documenting networks and put together layouts for some basic network documents.  Most of what I do is based on ITIL principles so it’s not an industry secret.  You could discover most of this if you look around for yourself. The first thing to understand about any system is that there are three variables to describe any system.

  1. Hardware
  2. Software
  3. Unique Settings

What I do when I am doing my documentation is to imagine I will need to setup an exact duplicate of that system.

This assumes you can match the hardware, software and the unique, non-default settings you will have the exact network that you started with.  The problem is that most people, try to keep all that in their head.  So when their is a failure they have to depend on their memory.   Too often I’ve seen a system administrator realize he was in over his head and leave a month or so before the network fails.

Start with the hardware.  How would you describe it.  Using Visio or even a spreadsheet, you’ll need to describe each hardware object on the network by,

    • Hardware type:  (Server, printer, router etc)
    • Maker: Model: Serial #:
    • Components:
      • RAM,
      • Drives,
      • Power usage,
    • system baseline.

These are some simple characteristics you need to know to talk with a helpdesk to fix your system.   Of course there are more.  The more detailed you can get, the more accurate your documentation.  But you don’t need much more than this.  Even without more details, with these simple fields your hardware manufacturer can probably identify your system for you.

A hardware Inventory will list each hardware device on the network.  Hardware devices include routers, switches, servers, printers, workstations, cell phones and so on.  With just these simple information you can save yourself a lot of time, crawling around looking for this information in a poorly lit server room.  Check out this site for layouts you can copy to document your own network.  If you need someone to create a knowledge base for you check out,   I am creating a list of document descriptions you’ll need to document your systems including, How to…, Settings, Topology and other documents you’ll want for your network.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: