Some organizations build wonderful networks, but fail to document anything. Shortly after entropy sets in and instability begins to pop up in the network. More likely, if there wasn't a written network architecture to begin with, the network is never built correctly and problems begin from the outset. Many engineers and managers don't see the benefit of a written network architecture until it's too late.
The first blog I wrote on NetworkWorld's Cisco Subnet last July was "My First Rule of Network Architecture: Write it Down". I've also blogged about how Network Design Templates are one of the key part of a written network architecture. I even wrote about standard icons and naming conventions. As you can read, having a written architecture is key to a homogeneous, stable network.
However, I haven't detailed what should actually be in the written architecture; I've just said you need to have one. Obviously, everyone will have different architectures, but the following information should be in every written network architecture. Some of these can also be applied to other technology architectures, for example, IP telephony, Data Center Networks, and Storage Area Networks (SANs).
Ok, that is a lot of stuff. This is not something you're going to write next weekend. It took me 6 weeks to write our first architecture and that was just version 1.0. We are now up to version 5.0 and have a very robust, written architecture. As time goes by your architecture will get better and more mature also. In time, it will be the key differentiator for your network; more important than any piece of hardware, routing protocol design, or network management tool. A written architecture will go more toward making your network stable and scalable than anything you could ever buy from a vendor.
Now, get out there and start writing! ;-)
More >From the Field blog entries:
No Love For Central Office Techs
How to Establish an Architecture Revision Process
Do You Have an Architecture Review Board?
NX-OS's Best Feature: Virtual Device Contexts (VDCs)
Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.
Michael Morris is a communications engineering manager at a $3 billion high-tech company. His background is in enterprise WANs working with telcos, and developing large-scale routing designs. He has worked on networks at government and corporate organizations, including networks at two Fortune 10 companies. In his current role, he leads large-scale IT networking projects and develops and maintains architectural standards for data networks, storage area networks, IP Telephony, and security. Michael is a CCIE and has 11 years experience in networking and communications, including four years as a paratrooper in the U.S. Army. He has a bachelor's degree in MIS from the University at Buffalo. Recently, he was awarded the Network Professional Association® (NPA) Professional Excellence and Innovation Award for his work on network architecture, templates and enterprise MPLS design.
|
|
Where's the Book?
Mike,
You have proven that you have the writing skills and the ability to interest us in standardized diagrams and Design templates etc. I have always made some efforts to provide documentation, but you seem to have it down to a science that we should replicate.
Time to talk to Cisco Press.
Architect your operations and security, too
All of the aforementioned technologies (plus security) will have to be operated, sometimes by multiple groups within your organization. With IOS based firewalls, wireless security, and other modules for the ISR (or ASR functions) you may have a challenge with what logs go where, where to send traps, etc. How will network operations play with that new SIEM system that the security guys are running? You should think about that beforehand as well.
Appreciation
I second the book suggestion.
There is a lack of a good book about network
documentation and the not-technical aspect
of network management.
I have found on the cisco nsp mailinglist an
entry of what should be included in a decent
network documentation. You can find it here:
http://puck.nether.net/pipermail/cisco-nsp/2008-February/047966.html
My current company has all
My current company has all these things in place. Even too much. Well, definetely it gives some help while designing new pieces of our huge network and keep things smooth and stable. But what we really miss is a n ability to innovate. If you want to add something new you need to go through all that documentation which only adds burocracy and slow things down.
I think it's good to have all that papers, but we should always remember not to make these things as a our main product. We are working to build and maintain networks and not papers.