Too many directions, too much to think about

Too many directions at once

It’s been a busy time. I have been settling into a new consulting role as a Network Architect. Starting is always tough, there are a lot of new people and new politics to understand. Plus the burden of understanding the procedures because every business does the same thing differently (and no, I don’t understand how that is possible).

This role is almost purely a design and architecture role. That means to receive the output from the Business Analyst (a work of fiction and guesswork that includes estimates on how much the project will cost) and turn it into a Detailed Design. The Detailed Design will then go to an engineer for implementation.

So far, normal for most people who do this kind of work.


Over the years, I have become competent at writing documents, finding and communicating with the various people, developing a consensus for a design that is acceptable to everyone.


The thing that I am finding most challenging is the diversity of technologies. This week has seen myself working on projects that have too many vendors and too many technologies and my head can’t hold all the data. The following is an overview of the technologies / products I have been involved with this week:

  • Blue Coat ProxySG, ProxyAV doing HTTP proxy, scanning and content filtering.
  • Cisco ACE load balancer deployment
  • Packeteer traffic shaping
  • BGP Site-of-Origin / EIGRP MPLS Site-of-Origin
  • Nokia/Checkpoint firewalls to build a DMZ
  • Cisco ASA / PIX firewalls for the same DMZ.
  • PVLANs for another DMZ, using trunks on multiple switches with VMWare servers. Meaning configuration of Cisco switches, VMWare and the firewalls.
  • creating a new site including IP phones for a PABX over a IPSec VPN over Radio network.
  • New VLANs/SVI versus secondary addresses

you get the idea, I am sure.

Its Detailed, alright

If I was working on any one of these, I think I would be OK. But doing all of these in single week I am losing my ability to complete designs. The point of preparing a Design Document is to capture the detailed information like IP Addressing, VLAN numbers as well as the big picture that sets the business requirements, and keep an eye on what problem is so that project actually delivers a result.

A design has two parts – the creative writing part that covers the business and project delivery and technical writing part contains highly detailed and precise information that the implmentation team will need. I find that doing both of these is hard, especially the creative part.

I can be happily working on one design, only to take questions on another —- instant brain wreck and concentration loss.

Is there an CCIE angle to this ?

Well yes. One of the things that the CCIE exam taught me is how to function with stuffed full head. Most mendicants tell you about how their head is overloaded and not sure how they will cope on exam day. For what it’s worth, I get that feeling most days. It doesn’t get any easier.

But the exam does teach you about yourself, and more or less, makes you find a way to cope with large amounts of diverse information.

And that is part of the reason that many successful CCIE’s go on to senior roles, and are at forefront of new developments in most companies. Sure, technical knowledge and competence is important, but it’s not the only thing. The ability to “grasp and mentally hold” the entire network for a large company, including the higher layers such a Servers, Applications, Databases requires practice.

A good engineer knows technology. But the mental discipline and practice to gather, hold, sort that data, and then extract meaning from it and being able to comprehend a wide range of technology means you have a chance to be a great engineer.

I guess I’m still working on it. Sigh.

  • Ethan

    A good engineer knows technology. But the mental discipline and practice to gather, hold, sort that data, and then extract meaning from it and being able to comprehend a wide range of technology means you have a chance to be a great engineer.

    Well said. Bravo.

    • Anatoly Gavrilov

      I’m wondering what your implementation engineers think about your work. I’ve realised that it’s hard to make a distinct line between design and implementation phase. May be some requirements were missed or implementation didn’t go as planned and you have to implement a workaround which may affect your design.

      And I saw a lot of various interractions between design and service delivery people:

      Smart Designer with a lot of field exp(CCIE) + Dumb Implementators = Design include detailed configurations of the hardware with detailed physical layouts. Field engineers simply connect devices as described, put IOS and configs. In case of problem, design engineer log in remotely and investigate what’s going on.

      Smart Designer + Smart Implementators = Designer starts giving more general configs, service delivery engineer can make IP allocation by himself, etc… Troubleshooting is done together. Usually smart field engineers go out from field work especially people with families as they don’t have time for kids if they travel too much.

      Dumb Designer + Smart Implementators = Designs will be very high-level. Like cloud to cloud connected with one link without any details. Service Delivery will eat a lot of shit dealing with the implementation. Basically they have to make a new design (we can call it low-level, but it’s completely different kind of job). It’s very easy to talk to customers and draw clouds in Visio. But if there are no good implementation engineers, dumb designer will be screwed (or promoted to high management as it usually happens)

      Dumb Designer + Dumb Implementator = Fail! :)