Ahh, the steady state life of your network documentation…
Usually outdated, most of the times scattered across different uninspired drawings and Excel files to be found on the big kahoona file server (or maybe on that other folder thingy that was on the z: network drive) and always in your to-do-list, your network documentation has turned into a hermit. For some it’s even a mythical creature, and rumor has it certain citizens claim it actually doesn’t even exist.
Always deemed important in hallway conversations, but never an urgent task in your day to day activities, your network documentation is collecting dust until, one day, it becomes the center of attention.
When the ‘sh’ part of IT hits the fan
Your manager all of a sudden tells you to drop everything and grab those darn network diagrams, because the Bobs are coming to audit the company for PCI/NERC/<fill in your favorite mandate here> compliance. Or maybe something just exploded.
What happens next? The NOC operators, the engineers, the whole IT department and their mothers are running around like headless chickens, desperately scrambling for files, sheets, anything that can tame the auditors, the outage, or both. Once the storm is over (and a few tens or hundreds of thousands of dollars disappeared in lost revenue, fines, etc.), some companies under or overreact and do the following:
a) Nothing. People get back to their routine tasks, your network documentation is put back into dormant mode and the cycle simply repeats itself.
b) Scream, kick, throw punches and then do lots of talking. Once the dust settles somewhat, grandiose ideas are proposed and some sort of master plan for the implementation of “processes” and “tools” is set in motion. Some of it is legit but most of it is just a feel good exercise, rhetoric with little actual upper management support, so the task gets thrown at a trainee or the navel (you know, that guy that has the middle cubicle but nobody has a clue what exact useful purpose he serves). After a few months things go back to firefighting mode.
c) Implement the mega system (this usually happens after a category 5 hurricane). The lack of network documentation is flagged as a piece of a much bigger problem, so the powers-to-be decide to tackle this and a dozen other evils in one fell swoop: the company issues an RFP for a monster CRM/OSS/BSS/ system. This requires a whole new department to operate and an army of expensive consultants to implement. A year of customization and deployment is followed by company-wide training, disgruntled adoption and the realization that this wicked child is unusable. A root canal is more pleasant than entering data into this Dreadnoughtus so the data turns into garble, people start using clandestine backdoor spreadsheets to fill in the blanks and the seven figure system is downgraded to shelfware.
Pay your taxes, don’t drink and drive and document your network properly
Unlike the dramatic examples mentioned above, many companies do understand that network documentation is a key component of their IT strategy. With a moderate budget and blessing (well, and some enforcement or pressure) from upper management, IT departments should be empowered to put a detailed, very flexible, yet easy to use system in place that automates as much of the network documentation process as possible, while documenting all IT components that are critical to the business.
Corporate networks have become a crucial part in the success and efficiency of a business, and they are not just about layer 2 and 3 networking. There has been a large increase in the amount of teleworkers in the field. Smartphones with access to corporate applications have replaced simple click and dial phones. Laptops and PCs are accessing servers on virtual machines via wireless, VPN tunnels, and the like. Add to that, a myriad of applications running on end user systems and servers, database engines of all kinds, with employees accessing them concurrently from anywhere and the picture gets really messy. Oh, and I have been told I must also use the word “cloud” in this article.
And when any of that fails?
Of course, “it’s the network that went down”. Or so claim the users, you know, the ones that are coming with the pitchforks and the torches when they can’t access the system to fill out their TPS report. A proper network documentation system helps you trouble shoot problems quickly and then some:
1) Find and report on stranded or underutilized assets: according to analysts stranded or underutilized networking and IT assets account for 5% to 40% of the IT install base. How about that for an ROI justification!
2) Improve capacity planning: without a proper inventory of your IT assets, budget allocation suffers due to lack of data on growth rates. With the proper system in place, you can plan in advance what really needs to be purchased and deployed instead of buying unnecessary hardware, pile up on VMs or allocate extra bandwidth that was never needed to begin with.
3) Shorter mean time to repair: your network documentation doesn’t have to be a sophisticated root cause analysis engine but at a very minimum it should give you a clear picture of how a component X that is affected by an outage connects from A to Z, how it is connected to the rest of the network and what other systems or services it affects.
Unless your corporate network fits in a shoe box the case for a proper network documentation system is a slam dunk. Whenever you need to design, optimize, trouble shoot or plan for capacity, it is imperative to keep track of the configuration items and relationships that comprise the whole IT landscape in an organized system that the appropriate stakeholders can access concurrently, from anywhere and with the proper security and permission levels.
If you are deciding to upgrade from notepad or excel and graduate to the big leagues, there are many options for your network documentation. But instead of beating our chests with netTerrain, in the next blog I will talk about what network documentation is not. Stay tuned.