Doyle on Networking

Taking the Art Out of Networking

05/18/2020 Category: Network Design
Chef

This blog is an updated version of an article I posted in Network World on 12/23/2008.

It’s been a long tradition around our house that I cook the Christmas dinner. I enjoy cooking but don’t get the time to do it as often as I would like; my wife does the great majority of day-to-day cooking, so she enjoys not having to cope with the Christmas feast.

I approach the preparations like I would an engineering project. Recipes are selected, ingredients and quantities go into an Excel spreadsheet, and a categorized shopping list is developed. When I bring the ingredients home, I sort them into groups on a table with a printout for the recipe under each group. Cooking schedules are worked out to optimize stovetop and oven availability, temperatures, and pot sizes.

Like most amateur cooks I measure my ingredients carefully. I often make modifications to a recipe from one time to the next (increase the baking time of the pecan pie by 15 minutes, add a little orange juice to the Waldorf salad, cook the cheese grits the night before so they firm up a bit), but when the action starts I adhere strictly to the specified measurements and temperatures.

wmi110804_hi
Have you ever watched a master chef work? There’s surprisingly little measuring going on. She knows the ingredients intimately, how their flavors interact, how temperature affects them. For the master chef, cooking is an art. For me, it’s an exercise in accurately quantifying components to get an expected outcome.

My Christmas dinner is predictable and consistent. It’s not art, but it tastes good.

Unlike cooking, when we design or operate a network we don’t want a “master chef” that is striving for something creative and exciting. Excitement is seldom a good thing in networking. We want predictability and consistency. We want quantification, not art.

Yet all too often we encounter people who claim that certain aspects of network design are “more art than science.” What those people are really saying is, “I have no idea how to quantify what I’m doing.”

The inability to put numbers around a networking project makes life difficult for us in a number of ways. How can we do a useful cost/benefit analysis of the project if we cannot quantify the benefits? How can we do a risk analysis if we can’t quantify the risks? How do we “sell” the project to upper management as an improvement in reliability, security, or performance if we cannot explain reliability, security, or performance with numbers? Even cost is not always quantified as accurately as it should be.

Take, for example, a simple change request form. Most of these have a section entitled “Risk Assessment” or something to that effect, and in most cases all that section contains is a requirement for you to rate the risk on a scale of 1 to 5 or perhaps as high, medium, or low. Maybe there’s also an area for you to write a brief verbal description of what you think the risks might be. Such subjective assessments are almost never useful and are usually there so that someone responsible for change management can say they at least asked about risk.

CC38174_hi
The vagueness and hand-waving that accompanies so many network project proposals can cause the CFO to view IT with a great deal of mistrust. Here’s a guy whose life revolves around numbers. If you go to him asking for a few million dollars for a new network project but cannot make a case – backed up by believable data in the language the CFO understands – for why those millions of dollars are a promising investment rather than just a cost, you are less likely to get your project funded.

For that matter, do you yourself know that the project will be worth the cost, even before you go to the CFO and swamp him with technical jargon and fuzzy claims that the project will improve network reliability/security/performance?

In the next few posts I’m going to write about how you can quantify things you might have thought were not measurable, how to better assess risks and benefits, and how to put numbers around your project proposals that will get the attention and support of the boardroom. I’m not going to torture you with Bayesian probability or stochastic simulations; I’m going to write about the sorts of questions you should be asking yourself in order to make a concept quantifiable, define a means of measuring it, and reducing the uncertainty around the concept.

Here's a couple of things to think about before the next blog:

  • What is the difference between counting something and measuring something?
  • At what point does increasing the accuracy of a measurement begin returning decreasingly valuable results?

Mull that over while I try out a new lasagna recipe.