I’ve been reading up on what the Internet says about ‘best practices for network documentation’. There’s a decent of material out there and, honestly, many of the articles I’ve read raise good points. That being said, I bring a slightly different perspective to what I consider ‘best practices’ for good network documentation. There are hundreds of different practices you can adopt for your documentation, but if these practices aren’t actually serving your goals…you’re going to end up with 100 different ‘best’ practices you’re doing (or features you’ve added) for no good reason.
When it comes to network documentation, a best practice (or a new feature) isn’t truly ‘best’ unless it does what you want it to do. Before including anything as a best practice, ask the following three questions:
1. Does this do what we want it to do?
2. Does this solve the problem we had in the first place?
3. …did we even have a problem in the first place?
All too often, we go looking for a solution and get distracted by all the shiny features we see. We go, ‘hey, that’s cool’ and all of a sudden, we end up buying a sports car when what we really needed was a minivan. The sports car is fun, sure…but for getting the kids to school and soccer, it’s not that useful.
When it comes to best practices, take a long, hard look at what you want to accomplish: focus on that. If what you really need to see are your primary circuit connections on a logical diagram, for example, figure out the most efficient way to see ‘em. Do you need DCIM and the features that go along with it…or do you need a tool that’s specific to discovering the network’s devices? Stick to the task at hand and make that your best practice.
It’s possible that down the road you will want to move something, or add in some features — but if focusing on what’s possible in the future distracts you from what you need to do right now, avoid it. Focus on the real pain point you have…and fix that first.