House of Quality for Networks: Turning Requirements into Real Architectures – Part 1

There’s a question that shows up in almost every engineering channel eventually:

It sounds technical, but it isn’t. It’s the same question as “What’s the best smartphone?”, and it usually gets the same kind of useless answers. iPhone loyalists on one side, Android fans on the other, each convinced their choice is objectively superior without knowing anything about how you actually live or what you need.

When you choose a phone properly, you don’t start with the logo. You start with requirements: a battery that lasts all day, specific apps that must run well, a screen you can read, a camera that doesn’t embarrass you, and a device that doesn’t shatter the first time it hits the floor. Only then do model names and spec sheets become meaningful.

Network engineering is no different. Asking “What’s the best router?” or “What’s the best protocol?” without spelling out scale, failure domains, services, operational model, observability needs, and economic constraints is just vendor fandom with better acronyms. If you want to operate like a principal engineer, you need something better than preferences: you need frameworks.

This article takes that simple smartphone analogy and turns it into a full decision-making playbook for network technologies. We’ll translate “battery” into capacity and performance envelopes, “apps” into protocols and services, “screen” into observability, “camera” into diagnostics, and “durability” into real failure behavior. Then we’ll layer on the tools serious engineers use, such as Quality Function Deployment (QFD), decision matrices, Pugh analysis, TCO and risk modeling, trade studies, and bake-offs, to show how you rigorously compare routers, protocols, architectures, and vendors without falling for hype.

If you hang around engineers long enough, you’ll hear the same lazy question over and over:

And it sounds a lot like another, equally lazy question you hear in everyday life:

Ask that in any room and watch the tribes form.

On one side, you have the Apple faithful:
“Obviously, the iPhone. Best ecosystem. Best camera. Best everything.”

On the other side, the Android crowd:
“Samsung Galaxy. Pixel. Whatever. More freedom, more customization, fewer walled gardens.”

No one is asking anything about you: your actual life, actual constraints, or actual needs.

It’s all brand, identity, and preference.

But when you strip that away, and you sit with the question seriously, the answer becomes much more boring and much more powerful:

In your own metaphor, you outlined a sane smartphone decision process; one that almost nobody uses, but everybody should.

You didn’t start with a brand. You didn’t start with “who has the best marketing campaign.” You started with requirements:

That’s it. That’s your world.

Notice what you didn’t include:

Weight might matter for someone else. Cost might be the primary constraint for someone with a different budget. Another person might care about gaming performance, stylus support, or specific accessibility features.

For you, these five criteria are your definition of value.

Once those are written down, the argument “iPhone vs Samsung vs Whatever” completely changes. You’re no longer asking:

You’re asking:

“Best” is no longer an absolute. It’s best-for-purpose.

You might end up with an iPhone. You might end up with a Galaxy. You might land on another Android device that nails battery life and durability while being “good enough” on camera and apps.

The key insight is this:

Now translate this to our network engineering world.

People say:

And the answers are usually just as tribal as the smartphone argument:

This is just fanboy culture in a different uniform.

They’re not answering for you. They’re answering for themselves, their habits, their biases, sometimes their certifications, or their last successful project. They’re reliving their previous wins and assuming your context is identical.

But in a serious network engineering setting, the real question isn’t:

It’s:

You already hinted at the complexity:

On top of that:

And beyond purely technical aspects:

Ask “What’s the best router?” without specifying any of this, and you’re making the smartphone mistake at enterprise scale.

You’re asking for an answer in a vacuum.

Why is this so dangerous?

Because when you don’t start from requirements:

It’s the same as buying a phone because “all the cool kids have one” and then discovering:

At the consumer scale, that’s annoying and expensive. At the network scale, it becomes:

That’s why the smartphone analogy matters. It’s not a cute story; it’s exactly the same mental failure at different scales.

Until you do the work of saying:

…you have no business asking “What’s the best router?”
You’re just picking colors and logos.

Let's take this metaphor further:

But it all starts here:

Let’s stay with the smartphone for a bit longer, but treat it as we would an actual engineering decision.

Most people decide on a phone with vibes:

That’s the same level of rigor as choosing a core routing architecture because “I saw it in a cool conference talk.”

You already did something better in your post without calling it by name: you wrote down requirements. Now we’ll go one step further and turn that into a structured decision.

Your list was:

We can turn this into a set of evaluation criteria:

Already, you’ve done more than 90% of what people ever do. You’ve made your decision auditable. Someone could argue, “But what about weight or gaming performance?” and your answer is simple:

This is the foundation of any serious decision framework: explicit criteria.

The second step is admitting that not all criteria matter equally.

For you:

So we assign weights. One simple example (out of many possible):

Do we have to argue whether the battery is 30% or 35%? No. We just need:

The point is to nail the shape of your preferences, not get lost in decimals.

Now, if someone says, “What about the color of the phone?” your answer, structurally, is:

This is precisely what you’ll do later for networks: e.g., “fancy proprietary GUI” gets 0–5% weighting; “convergence behavior” and “telemetry support” get 25–30%.

Let’s make this concrete.

Suppose you’re comparing:

We create a simple decision matrix. For each criterion, you score each device on a scale, say 1 to 5:

Then multiply each score by the weight of the criterion and sum up.

Example (numbers illustrative, not absolute truth):

Now calculate each option’s weighted score:

You don’t need to obsess over the exact arithmetic here. What matters is:

You’ve moved from opinion fights to a multi-criteria decision that can be reasoned about.

That’s precisely what we’re going to do later with “Vendor X vs Vendor Y,” “EVPN vs Legacy L2,” and “SR-MPLS vs RSVP-TE.”

So far, we’ve stayed at the user-facing layer: what you, as a human, care about.

Quality Function Deployment (QFD) goes one level deeper. It asks:

Think of QFD as building a little translation matrix between:

This is often visualized as the House of Quality, a grid that maps user requirements to technical parameters.

Let’s do a simplified “QFD-lite” for your phone:

In a QFD/House of Quality, you’d build a matrix:

Visually, it might look like:

Once that mapping exists, engineers can say:

Now the smartphone choice is no longer:

It becomes:

That’s QFD-lite in action.

Everything we’re doing here with a phone is exactly what you should be doing when you pick:

You:

The smartphone is just a friendly way to show the same thing:

Let's take this metaphor and fully bring it into our world, mapping each smartphone dimension to concrete network engineering concerns: protocols, architectures, hardware, and OS design. Then we’ll start layering the frameworks (decision matrices, Pugh, TCO, risk) on top of that.

Now let’s cross the bridge.

You already know how to choose a phone by looking past the brand and into what you actually care about. The next step is to realize that every one of those smartphone dimensions has a direct analogue in network engineering.

We’re going to map:

…and then add three things that phones barely touch but networks absolutely must:

Because just like with phones, obsessing over “the latest chip” or “the hot buzzword protocol” is meaningless unless it moves the needle on what you actually need, technically and economically.

On a phone, “good battery life” means:

The spec sheet might show “5,000 mAh,” but what you care about is real-world endurance.

On a router or switch, the equivalent is your capacity and performance envelope:

A device that looks amazing in a brochure but melts when you feed it a realistic production route table is like a phone with a “huge battery” that dies at 4 PM.

This is also where CAPEX vs OPEX begins to show up:

In TCO terms, “battery life” for a router is about:

A cheap chassis that you outgrow in 18 months is often more expensive over 5 years than a pricier one that comfortably rides your growth curve.

On your phone, if it can’t run WhatsApp, Telegram, LinkedIn, Instagram, Notion, Outlook, and a browser smoothly, it doesn’t matter how pretty it is. App ecosystem is non-negotiable.

In networks, “apps” are:

Your “app support” requirements might look like:

And interoperability is the cross-platform equivalent of “apps working properly together”:

From a cost/ROI perspective:

The economic question isn’t “Who has the longest feature list?” but:

A good phone screen isn’t just big. It’s usable:

In networking, your “screen” is how clearly you can see and understand the network:

Visibility and observability directly impact:

A router with poor telemetry is like a phone with a dim, low-resolution screen. It might technically “work,” but you’re constantly squinting, misreading, and making mistakes.

The camera on your phone is how you capture reality and inspect it later. For many people, it’s the most-used feature after messaging.

In a router, your “camera” is everything that helps you see what’s going on when something is wrong:

When the network is on fire, this is what determines:

Operationally and financially:

On a phone, durability is:

On a router/switch, durability is reliability and failure behavior:

Reliability feeds straight into TCO and ROI:

In phones, the hardware story is:

In routers and switches, the hardware architecture is:

From a cost perspective:

Just like buying a phone that’s too big for your pocket is a usability issue, buying a power-hungry chassis that your DC can’t cool is an architectural mistake that shows up as OPEX pain and reliability issues.

On phones, software architecture is:

On routers:

Software architecture heavily influences operational cost and risk:

Finally, phones live in ecosystems:

Routers live in ecosystems too, and they matter even more:

Economically, this is a huge chunk of TCO and ROI:

When you zoom out, you see that price tag is just one facet of cost. The real question is:

In the phone world:

In the network world:

The smartphone metaphor isn’t just cute; it’s the same thinking pattern:

In the following article, we’ll map these dimensions and plug them into the actual frameworks: decision matrices, QFD, Pugh analysis, TCO and risk modeling, trade studies, and bake-offs, so you have a concrete, repeatable method for choosing real network technologies the way a grown-up engineer should.

See you then!

Leonardo Furtado