Problem solve Get help with specific problems with your technologies, process and projects.

Taking the 'Oh, no!' out of network design

Ever experienced the feeling of panic when you discover you're in charge of a big networking project? This article will help you approach the job in several steps.

David Lease

You just completed a long, grueling proposal complete with orals on a huge network design and implementation for a major customer. And you won! After the celebratory elation wears off, the reality of doing what you often stated you could do finally sets in. The voice in the back of your head softly asks, "What have I done?"

Panic is an option, but not a very constructive one. A better choice would be to gather your technical team and start planning to do what you were taught as an engineer: define the problem set, break it down into manageable pieces, assign responsibility, design, review, and implement.

At a high level, these are all the correct steps to follow. But, as we all know, the devil's in the details. Here are some details you should pay attention to.

Analyze your customer's environment. This doesn't mean you simply take an inventory of the equipment and circuits currently in place. This means understanding the applications they use, the time of day/week/month/year they are used, the kind of servers currently being used and planned for, the way work flows from desk to desk and site to site, where and what kind of mass storage is being used, where the continuity of operations (COOP) centers are, and, finally, how stale data is archived or disposed of. Periods of data burst are especially critical indicators as to how you should design the network.

Reuse what you can. Most networks are in some stage of flux, meaning that there are hardware elements you can either directly reuse or reuse with upgrades. This goes back to truly understanding what your customer has in place and how they use it. Anytime you can save your customer money, you come out ahead.

Plan for growth. In over 20 years of networking, I have yet to see a network remain in its original state. Applications are demanding more bandwidth. We can now accumulate data we never dreamed of having and in volumes that haunt our nightmares. It's a common programming practice to "put in the hooks for future enhancement," and it should become a common design function for you as a network designer. Consideration should be given to the low-level transport technology used (ATM, Frame Relay, OCx, etc.), rack space, environmentals, communications closets, punch-down blocks, and the ability of the selected routers and switches to be upgraded with new functions or features.

Put a plan in place to upgrade and/or replace equipment on a 20% per year growth curve, with a maximum equipment life of five years. Even if it is not utilized, it's a valuable tool to bring forth when you start having capacity issues, because it allows you to determine what needs changing in order to achieve a certain performance level.

Include COOP in the initial design. One of the most overlooked functions is COOP, or as we used to think of it, disaster planning. Doing data synchronization, backup and recovery, and system cutover are data-intensive and complex functions. Incorporating these after the fact will lead to unexpected costs and design complexities that could have been initially avoided. Working with the customer to understand their critical data needs and the data flow are invaluable in this area.

Get customer buy in. Now that you've got a preliminary design in hand, review it with you peers. Then review it with the customer. Making sure the customer understands the impact of any constraints imposed on the design and the resulting performance limitations will prevent difficulties down the road. Customers who understand the design and its limitations are much easier to work with through the life of the contract. Keep the customer involved during the evolution of the design (see "Plan for growth"). While the customer may be the reason for the design change, they may not necessarily understand the impact.

Be involved during implementation. As a designer/architect, it's very tempting to do the paperwork and throw it over the wall for the field engineering staff to figure out. If you've ever had to be in the field building a system in this way, you know how often reality contradicts what is in the design. Staying on top of the initial implementation not only helps make the process go smoother because you can adjust the design to reality, it engenders respect from the field staff and your peers and eventually makes you a better designer. Once you've made a mistake and had a field technician point it out to you, you're not likely to make it again.

Being involved with the rollout also helps with customer communications as to the status of the project. It's much more credible to explain that you watched the backhoe cut the fiber cable accidentally than to simply state that there was an outage.

Large projects can be intimidating, frightful things. But they don't need to be the cause of panic or long-term heartburn. Go back to solid engineering basics, build a good team, break the project down into manageable pieces, and you'll be successful. You'll probably never get rid of the "oh, no!" reaction of winning a big design contract, but if you follow some general guidelines, the feeling won't be as intense or last as long.

David Lease is chief architect responsible for solutions definition and architecture for customers of WamNet Government Services, Inc. WamNet Government Services is a leading architect and manager of secure enterprise networks for public sector and defense agencies. Contact David at
This was last published in May 2004

Dig Deeper on Network Infrastructure

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.