So, you've done a great job so far. You've developed network design templates. You then went and wrote down your network architecture. You even established an Architecture Review Board to discuss changes to the architecture. Great job! Only one more thing to do.
Now you have to create an architecture revision process. These are the rules that govern changes to the standards. The last thing you want is to have standards that change all the time. If that happens, then you don't have standards at all; just confusion. So, you need to establish some rules for revisions to your architecture.
The first thing to do is to define the types of architecture changes that can be made. We categorize changes into "Minor" and "Major" changes. Minor changes are design fixes, simple enhancements, and configuration changes that can be implemented across the network immediately. For example, a new SNMP configuration would be a minor change because it is easily deployed. Conversely, major changes are changes that cannot be implemented across the network. In this case, an example would be a new router version to use for a certain template. Obviously, this cannot be immediately deployed across the entire network, now would you probably want to.
Now that you have categorized your changes, you can version them. Major changes should be released on a regular schedule, perhaps every 6 months. These would be full point changes - 1.0, 2.0, 3.0, etc. People should be alerted to these major releases and shown what has changed from the previous major release. You can even have some fun by naming these releases, like software companies do. We name our releases after Transformers. Minor releases are "dot" releases of the current major version. So, 1.2, 1.5, 2.4, 2.6, etc.
The last thing to do is track your releases, major and minor. You should list what changes create each minor release and what are the large changes that are rolled out with each major release. You then need to match designs in the network (for example, your site in NYC) to which architecture version it is built to. That way people can understand which architecture version is used for a specific network. This may mean that some parts of the network are built to different standards. That is fine. You cannot expect a global network to be constantly at the same architecture version. This is analogous to PCs. Never will every PC in a company be on the same OS. Some will run Windows XP, some 2000, some Vista. But, you should have a list to know which version each PC is using. Same rule for the network.
You now have the parts needed to create, update, and track your architecture. If you've done all this, you now have a dynamic, mature network architecture that will be the envy of other IT groups and organizations.
More >From the Field blog entries:
Do You Have an Architecture Review Board?
NX-OS's Best Feature: Virtual Device Contexts (VDCs)
* Tips on spending your time well at Cisco Networkers, plus: bring back the CCIE party!!
* NX-OS - Some Software For all that New Nexus 7000 Hardware
* A CCIE job that only offers $150K - ummm...maybe...well...no.....
* The DC3....err....Nexus 7000 brings some exciting hardware to the DC LAN
Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.
20 useful sites for Cisco networking professionals
Network World's IT Buyer's Guide: Cisco products
Subscribe to Network World's Cisco Alert, which includes a weekly digest of all Cisco Subnet items
Michael Morris is a communications team lead and network architect 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.
|
|
How about ITIL?
Morris,
I started reading your blog today and this is something I have been trying to do at my various jobs i.e. "Write everything you do; do everything you write"
For last few years I have looked at ITIL processes and it might be a good idea that if you customize the ITIL process so every time you touch a the network for a CR you ensure to update the relevant documents however the needs to have a baseline document and the needs to review the architecture is more then ever now.
The templates were excellent. The challenge is to develop this habit within the organization to ensure that all the documentation is updated and is reflective of the network running.
/Majid