I was recently reading (ok, ok…listening, I’m lazy…) to a book. So, it was a book about habits…maybe to get some less lazy habits going on in my life, but hey: I am going off topic already!
Anyway, what does me reading a book about adopting less lazy habits have to do with network documentation software or DCIM or Outside Plant?
Well, here we go….
Network Documentation: Set Goals
In one part of this book, there was an interesting part about goal setting. Yeah, yeah, we all know about goal setting. Afterall, don’t we all set a goal or two on the first of each new year? My most successful goal setting is the one where I have a goal of not meeting my new years eve goal. Now, that’s always a winner!
The point of a goal is to give you something to aim for — and aiming for something is all of us are always told is key when we try to achieve something… I’m going to lose X pounds or stop smoking. Those are big goals…but goals are just the prize or the end results. To me, the goal setting part is the easiest part.
So…let’s say your goal is getting the network documented…finally. Sounds like a good goal, but how do you get from A to Z?
Network Documentation: Break Down the Steps
I am going to lift a car. Whew, look at that goal! Ok…how do I lift a car? It’s not the goal that’s the hard part or even the goal setting. It’sthe how to achieve the goal that’s the hard part. The work that needs to be done and the path that needs to be followed, now this is the hard part.
If you’re still reading and I haven’t lost you yet, you may be scratching your head and thinking ‘why is this guy blathering on and what does this have to do with network documentation?’
I’m blathering on because the steps it takes to achieve a goal is one of the most important aspects of network/IT documentation (DCIM, OSP, etc).
I often have calls with people looking to implement a documentation software package. Some of the questions I get are: how long will it take, can we import data, how does it work, how much is it and so on.
That all matters, of course, but the single most important thing to consider with a network documentation project is the path/process. You may end up purchasing a software product, get your people trained and get data into the system..but…on the day after you implement, if you don’t have a process in place to maintain the system (or, in other words, develop the habit) then what you have done is spend a lot of time and money on a system that will fail. At least…I can’t see how it will be successful until you have a process to keep the documentation up-to-date in place.
Network Documentation: Define the Process
What kind of process will you need? What you need will depend on many things, such as: users, departments, other workflows, etc. Ideally the process is automated and involves using discovery or a collection of data that is done as a timed event to bring in new or update existing data.
It could be very simple: just a manual process in which new equipment is ordered and arrives and then a simple process where the person installing that equipment is tasked with opening the network documentation software tool or spreadsheet or other document and updating the information. But it should be specific and documented. The process needs to be written down and updated and maintained like any other process should be. But most importantly: it needs to be followed.
A process not followed is not a process (or is it…how profound)… I do know it’s not much use to you and it certainly won’t help keep your documentation up to date if you’re not following your process.
Network Documentation: Make a Blueprint
We have a house and one day we decided (i.e.: my wife decided) that we needed to make some changes. Let’s redo the kitchen! That led to a new kitchen, a small addition, a redo of the basement and a new entrance. Yeah, let’s face it: sometimes one thing leads to another!
To get started with said project, we needed to have a starting point. The starting point is where you are today (in the case of our house, it was our kitchen needing some improvements). To really capture what you have today, and where you want to be in the future — at least in the case of a house — you need to document what you have.
There are different ways of doing this I suppose but I think the most common in this case is to get yourself an architect. Go out, talk about what you want to do…and then go from there. But the architect will want to capture what you have today. So…get out some drawing tool like Autocad and capture all the details. Get those rooms and floors and windows and pipes and so on documented. Then the process of adding or changing can really begin. Then some updates and additions and changes can be added in for reference…and decisions can be made.
I think it’s a fairly solid metaphor for network documentation. At least when it comes to wanting to know what you have today…if changes are wanted or needed for your network, you will have a blueprint from which you can work.
No, the network is not a house — but if you don’t know what you have, it’s a bit harder to make decisions about how to add on or update what you do have.
Network Documentation: Visualize Your End Point
Now…what would you want to document if you are getting your house in order? Well there may be a few paths to follow depending on what the need is. In the case of a network overview, this may be a simple network diagram(s) that show some core equipment and how its connected. For instance, I may have core equipment tied to some aggregation equipment that is tied into campus switches. Maybe you document this in a logical fashion where you display the basic connections. One big drawing to rule them all and traditionally this has been accomplished with something like Visio.
Is it a must-have? Maybe not. That being said, if you need to make changes to the network or want to troubleshoot some issue, it’s nice to have this type of documentation around (assuming its been maintained). Now, if you want to create some detailed documentation that’s always an option too. Maybe some detailed inside plant and DCM diagrams. Some nice rack elevations with detailed equipment locations? And don’t forget to throw in those connections. Speaking of connections…let’s not forget those Outside Plant fiber connections. Hey, splices rule!
Bottomline? If you’ve been avoiding documenting the network, don’t just set a goal that you’re going to finally do it and say, “yeah, that will happen…one day.” Think of it like you’re going to do a home renovation project: set the big goal, define the smaller steps you need to get there, plan how exactly you’ll document (tools needed, etc), get an overview of where you are currently, and visualize the end point where you’d like to be once your goal is accomplished.
One last thing….if you want to check out the book I was referring to you can check it out here (afterall, it kind of helped me get a few of my lazy habits in check). And maybe it will help you, too, get into the habit of following your process to better