The Design Mindset (1)

How does a network designer, well, actually design something? What process do you use as a designer to get from initial contact with a problem to building a new design to deploying a solution? What is the design mindset? I’ve been asking myself just this question these last few months, going through old documentation to see if I can find a pattern in my own thinking that I could outline in a way that’s more definite than just “follow my example.” What I discovered is my old friends the OODA loop and the complexity model are often in operation.

So, forthwith, a way to grab hold of a designer mindset, played out in an unknown number of posts.

Begin with observe. Observation is the step we often skip, because we’ve either worked on the network for so long “we don’t need to,” or we’re “so experienced we know what to look for.” This is dangerous. Let me give you an example.

A long time ago, in a small shire on the borders of reality (it seems now), I worked on a piece of equipment we called the funnyman. Specifically, this was the FNM-1, which was used to detect runway visibility range (the distance from which you could see a light set to a specific intensity, or brightness). I don’t want to dig too much into how this worked (it did involve drum memory, though, which the RVR-400, a similar unit, replaced with diode memory, so-to-speak; the first tech order in the series is here), but there was a reason we called it the funnyman. You would trace through any given circuit (discrete component digital logic, yay!), until you came to an inverter. “Well,” you’d say to yourself, “I know what an inverter does, so I know what the signal should look like on the other end of this path.” So you check, and find it’s not. How did that happen? Because, grasshopper, you didn’t really observe. If you trace the circuit a bit farther, you’d find a second inverter (and sometimes even a third, something we called the brother-in-law effect, because we figured the brother-in-law of the guy who designed this thing must have supplied the components).

But what should the designer looking into a design problem observe? That’s precisely the right question: what? Good questions might be something like—

• What protocol has been deployed?
• Where is information being hidden?
• Where are the failure domains?
• Where is redundancy introduced in the network?
• Where are there failure points?
• What quality of service is applied where?

Do not, at this stage in the game, even think about asking why any of this is. You need to clearly separate “what” from “why;” once you start down the “why” question, you’re going to get lost in a narrow silo of thought, which is going to cut your observation short, and hence you’ll miss the second (or third) inverter in that circuit. It’s very important to truly observe what has been done carefully, and as fully as possible.

Let me give you a hint about what to ask “what” about: the complexity model.

You should specifically ask—

• What is generating the state?
• How fast is the state changing?
• What surfaces?
• What is being optimized for?

If you ask about each of the three items in the complexity model—state, surface, optimization—it will help you uncover much more of the what you need to be observing. The first step in the design mindset, then, is to observe and ask what.

P.S. If you really want to get your CCDE, you need to read this series of posts.