Network Design – Creativity and Compromise

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.

  1. 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.
  2.  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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.

  • JL

    Wise words.

  • Fernando

    Too bad there isn’t an option for more than 10 stars.
    Brilliant post!

  • Aneel

    I don’t think network design needs any significant amount of creativity, unless there are complex/odd/etc problems to be solved. The greater the said property of the problem, the greater creativity needed to solve it.

    I’ve had the [un?]fortunate luck of having had to design my way out of very complex requirements challenges.. out of which I came to to a creativity methodology spectrum. At the larger networking technical services practices, there’s a lot of methodology that institutionalizes lessons learned, ways to solve problems, questions to ask, etc. The methodology codifies past creativity for large scale application. The more methodology and the more applicable that methodology, the less all out creativity you need to apply.

    However, you need to be able to identify when the methodology is insufficient and apply your creativity levers to a challenge. And this is something that must be constantly evaluated against all the things you mention.

    • Kevin Bovis

      Perhaps what I’m saying is that the best designs are the ones where some creative thinking has been applied. My designs quite often lack that creative thinking. You’re right about most design problems can be tackled by applying a design methodology and 9 times out of 10 an adequate solution ‘pops out’, but I do think we should strive to be more creative.

  • mokum von Amsterdam

    Amen to that, brother!
    You just described 99% of all _good_ ‘IT designers’ I have had the plesure of meeting over the last 25 years. Let me give you one reading tip: Notes on the synthesis of form, by Christopher Alexander.
    You and me are in the same line of work, with the same ‘handicaps’. Only this summer I was introduced to this book and it changed my life as ‘designer’. I hope you’ll like it too.

  • Omar Baceski

    great post

    every time if had to use creativity in network design was beacause of flaws on layer 7, 8 or 9 of the OSI model (7 = you should know, 8= lovely users, 9= politics)

    in the end, after putting a lot of inventive, IF your design gets ever implemented, be sure layers 7,8 and 9 will fire back anyways at some point in the future… (don’t tell me you never withnessed an IT manager pointing at a powerpoint slide where the network is represented by a cloud, and saying, “we think the problem is somewhere there”). Definitelly documentation will help you out in those situations.

    anyway, be very cautious when an IT managers asks you to use your inventive to solve a problem (one that they normally don’t understand)

  • loopback0

    Creativity is the fun part of the job!

  • James

    Kevin – enjoyed the article greatly. I do have a question about where I would find information on the details of “Junipers’ and Ciscoís hardware architectures.” Thanks again. – KJ

  • Kevin Bovis

    That is a very good question. There is little from CiscoPress that really goes into hardware architecture. A simple question regarding such and such piece of hardware and whether such and such packet is switched in software or hardware can take several hours of research and several e-mails to a vendor S.E.

    There is a lot of good info on both Cisco & Juniper’s website. However, by far the best source of in-depth info is from events like Cisco Live (Networkers). There are a lot of very good topics covered by some real experts. The slide decks from these presentations are made available to non-attendees (at a price), or you can just badger your Cisco partner or Cisco A.M. to get access to them. I believe that they are also being filmed and put on Cisco TV. I’ve also heard of them being posted on file sharing sites, although make sure you get the most recent. I assume Juniper do the same thing, perhaps someone can confirm.