Skip Links

Network World

Michael Morris

Network Design Process

By michaeljmorris on Thu, 12/06/07 - 9:32am.
Newsletter Signup

I had an interesting e-mail discussion with a man from Germany this week (let's call him Hans). Hans has very good technical experience working at a German service provider. He has a lot of hands-on experience troubleshooting and supporting networks. However, he's in a new job now as a pre-sales design engineer focused on small to medium enterprises. So, not only are the networks different, so is the role.

His question was how to get network design training. Not specifically about OSPF or LAN switching design, but general training and guidelines for network design. I though this was an interesting question. Most Cisco training is technology focused - how to design BGP or QoS, but very little about the network design process.

Cisco has developed the PDIOO (Plan, Design, Implementation, Operations, and Optimize) approach.

While this is more of a framework than specific processes for network design, it is a good place to start. I am sure people could write an entire book on Network Design, but, since this is only a blog, I will try to provide a bullet list of tasks in the "Planning" and "Design" phases using the guidelines of Top-Down Network Design. Sort of a tip list for these phases of the framework.

Planning

  • Research your client - before you even meet your new client research their company. Their website and, if public, the company's SEC filings are great sources of information.
  • Develop requirements - "develop" is the key here. Customers will often (1) not know what they really want or (2) not be able to articulate it. You will need to discuss requirements several times with key stakeholders, ask detailed questions, provided what-if scenarios and listen intently to everything the customer says. Defining specific requirements can be very tricky and take a while, but in the end, it's worth it.
  • Build Relationships with Decision Makers - your success will ultimately be determined by the people you are working for. No amount of network statistics or graphs will make up for strong relationships with your customer.
  • Remember Politics - beyond building relationships, all organizations made up of people have some sort of politics. Even though it usually has a bad connotation, politics are not a bad thing; they are just how people communicate. Learning the politics of your customer's organization will make you more successful.
  • Define what is the overall driver for the project - even though the project may have a list of requirements, there will be one thing that drives the project. These can be summarized as one of three - "Cost", "Schedule" or "Performance". Does the customer need to reduce or minimize costs? Does the customer need to get it installed by a certain date? Does the customer need the best damn network money can buy? One of these will be the driver of the entire project.
  • Set the Scope of the Design - a customer asking for a DC LAN design should not have a requirement to determine best ISP BGP peering.
  • Set General Timelines - nothing exact or to a project plan level, but some general timelines so the customer can understand the impact to their business.
  • Remember Applications and Users - investigate traffic flows and user populations. The network will exist for users and their applications, so you need to understand these two groups. You wouldn't build a passenger plane without considering the people who will ride in it. Networks, outside of a lab, exist to support people using applications.
  • Understand the Current Network - most likely this project will replace an existing network, or, at least, will connect to an existing network. Get a good understanding of the current environment and how your new network will be a part of it.
  • Document everything - documentation provides two key things. First, you will not remember everything, so write everything down. Second, customers feel much more comfortable when everything is documented. It shows a level of professionalism and accountability and gives them the ability to gauge the projects status without having to rely on your memory.

I'll cover the Design phase next week. Feel free to add any to this list.

A nice list

0
By tuomoks on Fri, 12/07/2007 - 1:41am.

Yes, it is a sales process in beginning and, as the list says in some places, learn the customer, client and network requirements / hopes / dreams / politics / current situation / players / etc.

Don't let any sales or management person sneak behind your back, you will regret that later a lot if anything happens you don't know before it is too late. And remember the network is end to end, it doesn't terminate on NIC or whatever but goes to end where the information is processed/saved or consumed.

Most corporations unfortunately don't have traffic / access / usage patterns, you have to find them very early in design process, otherwise the network will have capacity problems sooner or later ( lunch time, Christmas, whatever ). Same with security, security and its overhead/personnel requirements/costs/etc are not easy to add later.

If you have an access to a simulation or emulation tool, start building models early on. They are great both for your own understanding and showing the customer / users what they will get, how it will work and why it costs a "little".

And one thing that I didn't see on list, keep your customer informed of progress, risks, etc. It is much easier to negotiate early than late. And that way you can synchronize your work with other groups, organizations, vendors, etc much easier. Make friends, they are valuable in this kind of business.

Tuomoks hits a very

0
By Sabine (not verified) on Fri, 12/07/2007 - 4:13am.

Tuomoks hits a very interesting point: Keep the customer informed of progress.......But how deep would you inform the customer? Some customers have not a good technical background at all.
Therefore you have to analyze your customer (decision-maker) as well as the normal users arround.
The question is, what is probably the limit between "enough information" and "information overflow"?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Welcome, visitor. Register Log in
Advertisement:
About From the Field

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 a team of 10 engineers responsible for large-scale IT networking projects and architectural standards for data networks, storage area networks, IP telephony, contact centers, and security. Michael is CCIE #11733 and recently became one of the first three Cisco Certified Design Experts (CCDE) ever (#20080002). He 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 and is working on his MBA from NC State University. In 2008, he was awarded the Network Professional Association (NPA) Professional Excellence and Innovation Award for his work on network architecture, templates and enterprise MPLS design.

Contact him.