How to create, select and justify network designs to meet elicited requirements
You have asked for all of the requirements eliciting questions and more importantly, you have actively listened to what your customer had to say, which produced a requirements specification document (including but not limited to, business requirements, technical requirements, user requirements, application requirements). Now what? How do you go about creating the network designs that will meet these requirements? My “thank you” to Hitesh Lodhi and Indika Prasad Kumara, who provided input to this blog.
Creating a network design to meet requirements within constraints
Make sure to incorporate all relevant pillars of a good design (aka go back to the elicited requirements!): redundancy/resiliency/convergence time/reliability/availability, speed, security, cost (CAPEX), simplicity (OPEX), time-to-market, manageability, scalability, and modularity/flexibility.
Unless you are working on a bleeding edge project, chances are someone else had already created a similar design and you can take advantage of the experience of others to ensure faster and more reliable designs. Look for network design best practices on the Cisco Validated Design Program site.
But don’t just blindly copy and paste solutions, instead make sure to adapt them to the situation at hand by observing previously identified constraints, and determining whether or not there will be a negative impact on the existing network. Documenting both constraints and impact will be important for the justification of your design solution.
A (not “the”) methodology for resolving conflicting requirements
What if these requirements are conflicting? How will you be able to justify your design choices? Being able to use a methodology to compare apples to apples is helpful. Below is one sample of a methodology that may help in your decision making:
1. List all of the business and technical requirements in rows of a spreadsheet.
2. As with anything in life, some requirements will be more important or carry more weight than others. You can use, for example, a weighted system with a high-medium-low weight. Is there any requirement that is so critical that it overrides others? This step is optional, depending on the complexity of your design project, but it can be a tie-break though when there are many and/or conflicting requirements.
3. Most customers appreciate having choices. List all of the possible solutions, technologies or features in the top column of the spreadsheet, side by side.
4. You can objectively compare and contrast the design solutions by marking the degree of which the solution meets the given requirement, for example fully vs. partially meet the requirement, against each solution. This will give you the ammunition to justify your design choices, and also the reason why you discarded others.
|Requirements/Constraints||Weight (optional)||Design Solution 1||Design Solution 2||Design Solution 3 etc.|
|Requirement 3 etc.|
|Total 1||Total 2||Total 3|
|Constraint 3 etc.|
5. For each requirement, multiply the weight factor (for example H=5, M=3, L=1) by the degree (for example fully meets=3, partially meets=1) of each design solution, and sum up each column. Also, check the box where the design solution faces the given constraint or undesired impact.
6. The quantitative approach provides the solution with highest number of points, but is this always the best possible choice? I wish it was that simple. You may need to ask your customer to compromise if a single design solution doesn’t meet all of the critical requirements within constraints or if it has an undesired impact. A comparison table will help you better communicate the options. Maybe a single option is not available at all the locations and you may have to adopt a combined approach. Lastly remember, you’re not on the side of a technology choice; you’re on the side of your customer!
How do you go about creating a network design to meet requirements within constraints? Do you have ideas for my upcoming blogs? Add them to the comments field!
Elaine Lopes is the CCDE and CCAr Certifications Program Manager and Team Lead for the CCIE program team, and she’s passionate about how lives can change for the better through education and certification.
Here are a few additional ways for us to engage and keep the conversation going:
- Cisco Learning Network CCDE Study Group
- Connect on Twitter too:
- CCDE study materials for the Written and Practical exams
- Related Unleashing CCDE blogs: CCDE: Book of Questions, CCDE: Rock & Roll-out, CCDE: The Pillars of the Earth - Part 1, CCDE: Design Use Cases - Part 1, CCDE: Come Together, Customer Engagement in Network Design with Emanuel Lipschütz
- Related links: CVDs Cisco Validated Design Program - Cisco