Years ago, I had the opportunity to work with a real network architect. I’ll call him Rani Doisman. 
I’m talking about someone who could put his fingers on a keyboard and make things work while being able to whiteboard out designs using various protocols and vendors, and dealing gracefully with the myriad logistical problems we face in our IT niche. All in a leadership role, and all while giving the rest of us guidance without making us feel inferior or stupid.
He gave me a simple methodology for taking a network from the embryonic state to what we might consider “graduation” – passing live traffic. In the intervening years, I’ve changed jobs twice and gotten my CCIE, and not only have I been unable to find something better, I’ve seen every deviation flail around unecessarily to some degree.
So what’s the super-duper sekrit? Just being organized and following a logical order of operations centered on a diagram.
1. Gather requirements. This is the obvious step 1, but is so often skipped or glossed over because no one can articulate the goals of the network. The key, in my experience, is to hound people as gracefully as possible until you get a firm idea of what needs to happen, then put it into writing, often in the form of an email to an entire group asking a single recipient to confirm the contents of the conversation you just had with him.
2. Draw a physical diagram! A logical diagram should happen too, but if it’s a simple data center with 1-2 routers and a default out, or something cookie-cutter that is well understood, it can be skipped. Physical diagramming is pretty much ignored in about half the builds I’ve been a part of in various places. The point of the diagram is to help in every other step, including step one since the first thing you do with the diagram is send it to the people dictating requirements and ask them to verify that the network will do what they need. After you nail down the network design in a diagram and get sign off….
3. Make a BoM. ”BoM” in this case is a Bill of Materials, a detailed list, usually a spreadsheet, of every piece of gear you need with quantities and prices if you can get them (to compare solutions). Your vendor(s) should help with this to make sure you do not forget a fan tray or something. The diagram is critical for this because you can literally put your finger on every point where a line touches a box and see that you need to account for the fiber patch, optic, line card and switch/router/whatever.
4a. Once a BoM is approved and the gear is ordered, that BoM serves as one of your checklists when you receive all the gear; other departments can use their own method, but you want your own when the buck stops with you. A complicated build can see pieces come in months apart, and you might need to bring things up with half the bandwidth planned or no redundancy, then add the rest as parts arrive. If you are tracking things with the BoM and diagram the situation is less confusing.
4b. That physical diagram is a great starting point for building configurations while you wait for gear to arrive. It lets you see where links are going and what they will be doing, any loops you need to account for, port-channels, ISP links, network administration/security boundaries, etcetera.
4c. Whether it is you and the CEO building the company’s first site, or a dedicated data center team, whoever is racking and stacking will want that diagram. Especially if you clearly denoted interface numbers and other details they will be interested in.
4d. A diagram keeps people both informed and honest. I have not once had someone dishonestly claim I missed something that they really just did not mention (honest mistakes however …). That is because I shot an 11×17 drawing out to three teams any time something changed. If that diagram gets sent to someone five times, there is no ambiguity to exploit.
That’s it. There is no crazy advanced secret knowledge, but the diagram is critical for several reasons:
- A network build will always have speedbumps, but when the diagram is skipped, I see more things go wrong. Sometimes big like not ordering power for a crucial rack, sometimes small like having too few fiber patch cables, but always more often.
- The level of confusion is at least double, and it increases with every person trying to figure out what the network will look like. People start making assumptions and that never ends well.
- Building configs and troubleshooting is a nightmare for anyone but the person who did the design, and he may have forgotten the details as well.
- Because of the increased confusion, the most common reason I hear – “I don’t have time to draw a diagram,” – just is not accurate. You do not have time to *skip* the diagram.
Finally, as someone once opined to me, there are two types of people who document their networks – the people who do it before they build it, and the people who do not do it. While I can’t guarantee that diagramming your network and working from that will result in a cleaner, more sane environment than building configs in your head and then documenting the result, based on my roughly 12 years of doing this, I’ll put money on it.
About Keith Tokash
