I just thought I’d share a few of myviews on Design in general and Network Design in particular. I apologise now for anyone who is reading this and expecting some wise words or informed opinion of the merits of OSPF over EIGRP or if a 3-tier structure is better than a 2-tier structure, Iíll leave that to the relevant experts. What I’m more interested in is how we actually go about the task of designing a network.
- Creativity: Of all the disciplines that are needed by a Network Consultantí, the one of design is by far the most difficult for me. For years I wondered why I found designing solutions difficult. I’m a CCIE with over 15 years experience; I’ve worked with some great networking people and on some very complex networks. Iíve got a stack of excellent books, Iíve even read some of them, yet I still find it difficult to be decisive and confident when designing. I think Iíve found the answer. The secret is in the word “design”. The word “design” suggests creativity, the ability to express ones self, an artistic nature. Thatís where I fail. I’m neither creative nor artistic. At Secondary School I gave up Art so I could play more Basketball. When it comes to dressing myself I follow a set of strict guidelines regarding colour co-ordination that my wife laid down nearly thirty years ago. basically I lack the creative gene. Therefore, my designs tend to follow a rather formulistic approach, with lots of metaphorical straight lines and 90 degree corners and very little flair.
- This doesn’t mean my designs are bad, or don’t work, it just means they are “safe”, not particularly inspiring, possibly even boring and take far too long to produce. So what have I learnt from this revelation? I’ve learnt that although I’m not creative I can appreciate creativity, I can’t play a musical instrument, but I do appreciate good music. Therefore I’ve learnt that plagiarism is my friend. Now I appreciate that plagiarism has had a lot of ëbad pressí lately, what with students copying vast swathes of text from Wikipedia and inserting it into their essays. But I donít think there is anything wrong in looking at good examples of network design and incorporating them into my work. Obviously the difficulty is identifying examples of good network design and that takes experience.
- Requirements: It was easy for Van Gough and Manet, they just went out and painted a picture of whatever took their fancy. Look! A wistful looking waitress in a Paris Cafe.. yep, I’ll paint a picture of her. Michelangelo had a slightly trickier job when he grabbed the gig to paint the ceiling of the Sistine Chapel. Here he was working for a particularly difficult customer, Pope Julius II, who had some very exacting requirements and dire consequences if he didnít like the end result. But I’m sure that Michelangelo would agree with my advice of ëunderstand the requirementí. I think itís always a good idea at the start of the design to summarise what the customer wants and why they want it in 4 or 5 bullet points and always have those points close to hand to refer to. If you donít understand those requirements, go back and ask. If the customer is not clear on what they want then that is where you must use your consultative skills to help them decide what they want and most importantly document their requirements.
- Compromise: Every design will have compromise forced upon it. You need to adopt a grown-up and mature attitude towards compromise. Pick your battles, stand-up for what is important in your designs. If someone doesnít like your choice of hostnames, then concede the point and let them go off and form a sub-committee to discuss them while you concentrate on the important things like†simplifying the network resilience. When faced by objections to your approach or design take time to listen and let them to articulate their concerns. When theyíve finished they usually end up agreeing that†you were right all along.
- Practicality: One of the most impressive pieces of architecture that I have seen in recent years is the Millau Bridge in France. After the initial Wowî my next thought was “How the **** did they build that”. I guess thatís the engineer in me coming out, or my council estate upbringing. But it is an important point. Any fool can stand at a white board, draw a series of boxes that are fully meshed and call that the “New WAN design”. For me, the most important part of any design is how do we implement it. How do we replace those core 6500 ís that have been up and running for the last five years. How do we implement that WAN in a series of 2-hour change windows over the next six weeks with no down-time. There is often a division between the designers and the implementers (pre-sales and post-sales) that is caused by the lack of consideration of how a design is to be implemented. If it can’t be implemented it stays on the White Board.
- Simplicity: The simplest designs are the best… Any design should have the minimum amount of complexity in order to fulfil the requirement. Complexity usually increases cost, time to implement and difficulty of operation. Three things that will make your design less attractive.
- Cost: This is a factor in any design. Any customer, who tells you itís not, will certainly change their mind when you present them with the itemized Bill of Materials showing them the fully loaded Nexus7K with all those expensive line cards and lots of those little optical thingys. When you start a design always make sure you understand the budget. I’ve had some fairly depressing experiences where I’ve presented my design only to have it knocked back because using WS-X6748ís completely “blows the budget” before we even start thinking about the boring stuff like, PSU’s, fan trays and chassis.
- Testing: Unless youíve successfully done it ten times before make sure you allow for some kind of testing. Prototypes, proof of concepts, they all have a part to play in a design. They are also your Insurance Policy. When you put your name to a design the customer assumes that you are personally guaranteeing that the design will work first time and fulfil all their requirements. Now we all know that is completely unreasonable and laughable, have you seen bug list for NX-OS? By specifying the need for a PoC or a prototype site you are giving yourself the chance to tweak the design, set expectations and put together a realistic implementation plan.
- Documentation: I can hear you all groaning now. “He always brings up documentation”, well thatís because itís important. I’ve seen numerous examples where the design that was chosen was the one that was easy to understand and well documented and a better design stayed in the head of a very frustrated proposer. And by documentation I don’t just mean the High-Level Design and the Low-Level Design, I also mean the minutes from the design meetings. How did we decide on RIPv2? Also make sure you have the requirements document from the customer. Donít just assume that following a 2-hour tele-conference to discuss the need to strip out a load of cost from the design that everyone will have perfect recall of what was decided three months later. Make notes, distribute them and get everyoneís agreement, I guarantee that it will save a lot of heartache later on and may just keep you on speaking terms with the customer.
All of the above assumes that you have the basics of Networking under your belt. You know how a link state protocol works, you understand the limitations of load balancing on aggregated links, and you appreciate the relative merits of Junipersí and Ciscoís hardware architectures. Yep, design is not easy. But if it was easy they’d pay us less.
