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.
as it happens I need to recertify my CCDP in a couple of months and had just covered the PPDIOO process in my ARCH-studies which seems to be opposite to your approach.
The first P (prepare) already looks at architecture/strategy and technology.
The second P (planning) then goes into looking at the already deployed technology and performs a GAP analysis.
Your approach takes a contrary approach by first looking at deployed technology before even looking at new technology.
Of course both are just methods and maybe the one is more suited for large scale design (i.e. complete new DC infrastructure) while the other is more suited for smaller scales (designing a new DMZ for remote access).
I’d be interested in hearing your take on this or am I comparing apples with oranges here (it’s early in the morning on this side of the pond so I might just need more coffee).
In my experience, if you get wrapped up in “why” too early in the observe portion of the process, you end up not seeing the gaps as easily. Intent is (mostly) mirrored in action, but sometimes actions don’t mirror intent. It’s hard to see the places where actions don’t mirror intent unless you start from the action end of things. It’s like reading your own writing — you can skip words, and you never see it, because your mind fills in what you intended, rather than seeing what’s actually there. Once you say, “this was done to solve that,” then you stop looking at what was actually done, which means you can, all too easily, miss things.
I understand why most models start from the other end — the business driver, intent, etc. — and I think that’s probably best in a greenfield, but in an already deployed system you really need to just look at what’s out there without any bias as to “why this was done” at some point. Otherwise, you’re going to end up with unintentional consequences…
Thanks for stopping by!
Nice article, Russ! You should check out this: http://www.plexxi.com/2014/08/network-engineer/ <– You're notion of "period of observation" fits neatly with the concept of "modeling" I talked about there.
Thanks for pointing this out — yes — this is very similar to the type of thing I’m thinking about in the design mindset.