So…you’re sick of troubleshooting that takes forever, fed up with buying IT stuff just to realize 6 months later you didn’t really need it or already had it, and you’re completely exasperated by those expenditures that keep going up, up, and away? You’ve finally decided that you want – no, scratch that – need to document the network. Two questions pop up right away: what will you document and how will you do it?
The way in which you document the network will probably depend on both what you need to document, what you need to do, and the resources you have available (from budget to technology to manpower to administrative buy-in). The kind of network documentation you do may vary….for example, you may call it: DCIM, DCM, logical drawings, physical drawings, that thing over there on the wall, the knowledge napkin…and, well, you get the idea.
An example of a DCIM floor plan
An example of a Logical diagram
But…the biggest problem with documenting is this: you can’t document and diagram the network unless you have some information to actually document. Maybe you’ve got some data kicking around that you could document… but it’s bad data: that’s tough to document.
If all you’ve got is bad data, and hey – maybe it’s not all bad (some of it is correct) – I suggest that you sit down and spend some time reviewing what you have. As you work, minimize just how bad that data is before you start documenting. Remember this: your network diagrams and documentation will only be as good and useful as your data is current and accurate.
When looking into some kind of automated IT documentation solution – whether it’s network diagrams or DCIM – it’s all too easy to get distracted by the shiny new features that can do some pretty cool things. Here’s a warning: those shiny new features can only do so much:
Once you push data into the project, you may very well end up exposing issues you probably already knew about. Invest a chunk of time into the data. How will the data be used; how will it be gathered? As you gather your data, put some checks and balances in place to ensure that the data is vetted and/or good. Depending on the condition of your data, you may want to budget in some time to do cleanup so you don’t end up with cool features that can do cool things to your not-so-cool bad data.
Bottomline? Network documentation can transform the way you work. It can give you powerful, and actionable, insights that help you solve some major problems that have been haunting the network. It can be as easy as clicking some buttons…eventually. Before you get there, however, you need to find the right solution…and you need to make sure you’re using the right data.