Posts Tagged ‘design mindset’

The Design Mindset (5)

So far, in our investigation of the design mindset, we’ve—

We also considered the problem of interaction surfaces in some detail along the way. This week I want to wrap this little series up by considering the final step in design, act. Yes, you finally get to actually buy some stuff, rack it up, cable it, and then get to the fine joys of configuring it all up to see if it works. But before you do… A couple of points to consider.

It’s important, when acting, to do more than just, well, act. It’s right at this point that it’s important to be metacongnitive—to think about what we’re thinking about. Or, perhaps, to consider the process of what we’re doing as much as actually doing it. To give you two specific instances…

First, when you’re out there configuring all that new stuff you’ve been unpacking, racking/stacking, and cabling, are you thinking about how to automate what you’re doing? If you have to do it more than once, then it’s probably a candidate for at least thinking about automating. If you have to do it several hundred times, then you should have spent that time automating it in the first place. But just don’t think automation—there’s nothing wrong with modifying your environment to make your production faster and more efficient. I have sets of customized tool sets, macros, and work flows I’ve built in common software like MS Word and Corel Draw that I’ve used, modified, and carried from version to version over the years. It might take me several hours to build a new ribbon in a word processor, or write a short script that does something simple and specific—but spending that time, more often than not, pays itself back many times over as I move through getting things done.

In other words, there is more to acting than just acting. You need to observe what you’re doing, describe it as a process, and then treat it as a process. As Deming once said—If you can’t describe what you are doing as a process, you don’t know what you’re doing.

Second, are you really thinking about what you’ll need to measure for the next round of observation? This is a huge problem in our data driven world—

Perhaps the greatest challenge facing the big data world is the recognition that data analysis is not the same thing as question answering.

Being data driven is important, but we can get so lost in being doing what we’re doing that we forget what we actually set out to do. We get caught up in the school of fish, and lose sight of the porpoise. Remember this: when you’re acting, always think about what you’re going to be doing next, which is observing. The more you work being able to observe, think about what you’re going to need to observe and why.

The Design Mindset (2)

In a comment from last week’s post on the design mindset, which focuses on asking what through observation, Alan asked why I don’t focus on business drivers, or intent, first. This is a great question. Let me give you three answers before we actually move on to asking why?

Why can yuor barin raed tihs? Because your mind has a natural ability to recognize patterns and “unscramble” them. In reality, what you’re doing is seeing something that looks similar to what you’ve seen before, inferring that’s what is meant now, and putting the two together in a way you can understand. It’s pattern recognition at it’s finest—you’re already a master at this, even if you think you’re not. This is an important skill for assessing the world and reacting in (near) real time; if we didn’t have this skill, we wouldn’t be able to tolerate the information inflow we actually receive on a daily basis.

The danger is, of course, that you’re going to see a pattern you think you recognize and skip to the next thing to look at without realizing that you’ve mismatched the pattern. These pattern mismatches can be dangerous in the real world—like the time I bumped against an engine part that was so hot it felt cool, leaving me with a permanent scar on my leg. So the point of “observe first” is to deal with reality as it is on the ground, rather than seeing the pattern, inferring the intent, and moving on to the “next thing.”

Once you’ve observed, it’s time to try and understand why. When you’re asking why, you don’t ever want to stop with the obvious answer. Instead, you want to be like the pesky eight year old who’s discovered that “why” is the ultimate question to drive your parents nuts.

“Why is this aggregation configured here?”
“Because we needed to break up the failure domain.”
“Why did you need to break up the failure domain just here?”
“Because we thought it was too big.”
“Why did you think the failure domain was too big?”
“Because we had a convergence problem once around that area.”
“Why did you care about the speed at which the network converges?”
“Because we have this application, you see… And if you don’t stop asking why, I’m going to slap you silly!”

Why is a multilevel question; ultimately you want to get back to the actual business driver for any particular item of configuration. In the end, if you can’t connect a configuration to a business driver (and don’t settle for, “it’s a best common practice,” by the way), then you need to set that bit of configuration or reality aside in a special pool to be considered later. Using this process, you’re likely to find a lot of stuff that might not need to be there. By making the connections, you might be able to find another way to look at the problem that will help you radically simplify the design.

What’s often hiding behind the why that can’t be connected to a specific business driver is either “because we could” or “because we know that technology.” The time that I worked through converting a network from OSPF to IS-IS because several folks on the networking staff were studying for the CCIE comes to mind…

The complexity model can, as always, help guide your why questions—specifically focusing on optimization, as this is where you’re most likely going to match network design with actual business requirements. Within the complexity model, of course, you’re going the be trading off optimization against state and surface, so the process is going to look something like this most of the time:


Business drivers often lead to primarily optimization requirements, to which the designer can respond either by increasing the amount or speed of state in the network, or by adding overlays and other systems, which in turn increases the surfaces in the network. At some point, someone cries “uncle!,” and says, “it’s time to reduce complexity here, because this network is eating our OPEX!” This is where really understanding why starts to prove useful, because it allows you to start seeing where optimization can be realistically traded off against simplicity by rethinking the relationship between optimization, state, and surface.

We’ll consider this more deeply when we get to the decision phase in the next post.