Top Down Design

A top-down design model considers availability, performance, scalability, security, usability, flexibility, manageability, and cost in alignment with business goals.


Using a top-down approach to design produces the best overall result for the business. I’m really not sure why network design is treated in such a different way than other types of engineering. I don’t think it’s intentional, but I often find that management seems to use narrow focus when making decisions about the network. This is more of a bottom-up approach and unfortunately it has unintended consequences .

Can you imagine if we were designing a car and in the final stages before production someone decided that the engine cost too much so we changed to a less expensive one, without regard for the miles-per-gallon produced or the weight load on the chassis? It’s sounds absurd, but that actually happens with network design, not because of malice on anyone’s part but because of a symptom I call the “stakeholder of the day.” Whatever seems to gain the most attention at a point in time is what receives focus instead of stepping back and looking at what is happening to the overall design and function of the network or systems asset.

The result of a bottom-up approach is that underlying changes take place in the design that go unnoticed, There are soft costs in places that aren’t accounted for. The network is not meeting the business need properly. The behaviors continue until there is another crisis situation and a different stakeholder takes the podium.

Top-down design looks at the network or system design problem from a business perspective and aligns the goals of the network with the goals of the business. With network and systems costs taking up more and more room on the income statement, keeping these goals aligned is crucial to business success. 

So let’s start by taking a look at the top-down process and what to expect. As the Design Engineer it's your responsibility to gather and evaluate all the stakeholders requirements. While it’s tempting to just gather everything and make the design decisions alone, some of the best designs come out of the inevitable conflicts that arise during discussions about design priorities. Engineers are extremely innovative folks and can come up with novel ways of meeting design requirements when they are well defined.. The real value of the design comes about as a result of this “brainstorming” process so it should be encouraged.

Are you going to please everyone? While that would be nice, the design parameters need to be balanced and there may be a few frowns from the stakeholders along the way. Just keep in mind that the business goal is what the focus is.


Let’s look at a practical example. For a network expansion project the Finance department has put together a budget number that is congruent with the business plan after much review with marketing and looking at sales projections. After putting together the network design it’s evident that it will be over budget when considering all the requirements and desires. The knee-jerk reaction of the design engineer might be to specify a cheaper and possibly less reliable brand of hardware to compensate and bring the project under budget. But instead,, a dialogue is opened with the affected stakeholders and the discussion yields the fact that the design being considered can actually offer “on-demand” features that could reduce the cost of transport (operating expense) if they were exploited. Unfortunately, those features would need to be included in the provisioning and network management systems which would add some capital labor cost there. But that side effect would also open the door for marketing to launch subsequent “on-demand” products at a later date with minimal effort and in a timely fashion. Marketing hadn’t put that into the initial requirement as they didn’t have it well defined at the time. But it made sense to consider. Finance decided that they could depreciate the capital labor to lessen the impact to the income statement, push out the additional capital equipment cost through financing, and overall it resulted in a better ROI on the five year business plan.

This is just one example but I’m sure you can think of many more. As the design engineer, you need to facilitate these discussions, cycle through the stakeholder requirements, present options, and contribute greatly on the technical side. At the end of each iteration of design review, your network plan will take more shape and conform more closely to the needs of the business. Remember that a conflict in requirements is an opportunity to show your expertise as a designer and bring home the win.


Stakeholders will have different needs. As a designer, you have the responsibility to gather these upfront so consideration can be given to all affected parties.


  • Support staff want manageability to perform their job functions easily.
  • Operations wants high availability to meet SLAs.
  • Users want performance and usability, they place these demands on the systems.
  • Sales department wants scalability and flexibility so that they can sell more product and shorten time to market.
  • Finance department wants low cost to meet budget requirements and give ROI to investors.
  • Regulatory wants security as a priority to comply with industry requirements and standards.


Translating stakeholder needs into a set of requirements is a balancing act. Changing the priority of a deisgn objective will often affect one or more other areas. It is the job of the designer to put the correct values together in a way that will best satisfy the complete list of requirements.

One way to approach this is to think of having a fixed number of chips. You can place any number of chips on any design category. The end result balances everyone's needs and becomes the template for later stages of design work.


Now that there are established goals for each area of the design, it's time to start putting together the actual design elements. Each of the elements are listed out and bullet points drawn up that are in line with the overall design goal.

Some of the decisions to make might be:

  • Hardware choices
  • Software
  • Network routing protocols
  • Access controls and methods
  • Physical topology


As a designer, it's important to realize that an end-state rarely exists. Instead the design must change along with the changing needs of the stakeholders or introduction of new technologies. The elements of the design are then revisited. Components are then evaluated against the new targets for each category. Examples:

  • New applications added to infrastructure
  • Conversion to cloud based services
  • Expansion or reduction of workforce
  • Change in geographic or market footprint
  • New networking or server technologies developed
  • Change in transport costs

© 2018 MONTCO.NET. All rights reserved.