Orientation

Quick — can you OODA? Last week we talked about the general idea behind the OODA loop; this week we’ll cover one more step; next week we’ll cover the last two steps, and then, in the last post, we’ll review and wrap up.

Orient is the second step: once you’ve made a set of observations, you need to decide what it is you’re actually observing. To help this make sense, let’s take a look at a simple optical illusion — you might have seen it before.

Do the blue squares look square, or… ?? If you’re like most people, the squares don’t look square at all — but they are. Remember the blue or gold dress? In both of these situations, we face the same sort of problem: our ability to perceive is often influenced by the context.

This doesn’t, as some people try to say, mean that our senses are all just a jumbled up mess, and the entire world is disconnected from our brains — you must be careful in life not to make the hard or odd case the rule by which all other cases are measured. Every measurement system has its limits; that doesn’t mean the measurement is useless or generally untrustworthy.

So what we must do, as network engineers, is to learn to figure out when the context matters, and when the context is simply messing us up. To separate the blue squares from the lines in the background, so to speak. How do we do this?

First, understand the operation of the network, protocols, and applications at a theoretical level. Reaching beyond the command line, and into the actual operation of the devices in the network — understanding how a router forwards packets, or how OSPF actually builds and processes packets, can make a huge difference in your ability to orient yourself to what you’re observing.

Second, learning and applying models is a huge help. The only reason you probably have trouble with the optical illusion above is that the boxes appear close enough to being squares that you immediately think they must, in reality, be squares. It’s easy enough to verify they are, actually, squares, but if we didn’t have the expectation of seeing squares there in the first place, we wouldn’t have suspected there was an illusion in play here. We have a “model of a square,” in our heads, and when see things that are close to that model, we try and make the object fit. Sometimes this works, sometimes it doesn’t. Now imagine someone who has only ever seen squares on seeing a rectangle for the first time. Try as they might, they can’t make the object fit into their model. This isn’t a problem with the model, or the object, it’s a problem with the person’s “model collection” in their head.

So it’s important to know a wide array of models into which any problem can fit — or, in the networking world, a wide array of models you can use to “see” protocol, application, device, and network operation. Each additional model you add to your “mental model set,” allows you to orient yourself that much faster.

This entire process is much like what I learned in orienteering in my younger days. First, get the map pointing north. Then, find the features on the map that match where you are, and work from there to the destination, feature by feature. Not orienting the map is failing to separate the background from the information. Not being able to see the surrounding area is failing to collect the information necessary to match the map to the reality. Not knowing the symbols on the map is failing to have enough mental models to make the match between map and reality happen.

All three are important in the orientation phase — so as network engineers, we need to try and gain all three skills.

The OODA loop is covered in some detail in The Art of Network Architecture, available wherever fine books are sold (because if they don’t sell my books, then they don’t sell fine books — see how that works?).

OODA Part 1: Getting Inside the Loop
OODA Part 2: Orientation
OODA Part 3: Decide!
OODA Part 4: Act!