How to Establish an Architecture Revision Process

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)

Come Visit Me at FutureNet

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.

Recent Cisconet blog entries

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

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2008 IDG Communications, Inc.

IT Salary Survey: The results are in