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.
USE CASE
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.
