As I revised my network design course, I had to decide whether to treat network design like product engineering or like service design, similar to building a software application.
The most useful way to think about it is this: a network is a service supported by physical infrastructure. Switches, routers, cables, and configuration state form the foundation, but the network itself is the capability to move data reliably, securely, and with enough performance for the people and systems that depend on it.
Whether you frame the design problem as a product or a service shapes what you measure, what you document, and, most importantly, the order of your design decisions. Getting that framing wrong is a common cause of misalignment between what designers deliver and what stakeholders actually need.
What a Network Designer Actually Does
Network design sits at a challenging intersection. On one side, you are an engineer thinking about packets, paths, and failover timers. On the other, you are a service architect thinking about requirements traceability, SLAs, and business continuity. In practice, these two perspectives must be integrated from the start.
When you design a network as a product, the deliverables are concrete and finite: a bill of materials, a topology diagram, a cable schedule, and a configuration baseline. The work feels complete when the last switch is installed and the final ping succeeds. Success is largely binary: it works or it does not.
When you design a network as a service, the deliverables are ongoing and behavior-focused: an SLA, a monitoring approach, a capacity plan, and a change management process. The design is never truly finished because it evolves with the applications it supports. Success is measured in service outcomes, not just connectivity.
The best approach is to do both, in the right sequence.
Start with the Service, Then Build the Product
A common mistake in network design, especially among students, is choosing hardware before defining requirements. I have seen teams discuss switch models long before they understand which applications the network must support.
A better sequence is:
Define the service: Identify the applications, their latency, bandwidth, and availability needs, and the users who rely on them. Clarify what a network outage actually means to their work. Every later design decision should trace back to one of these service requirements.
Design the service architecture: Before choosing a vendor or model, create a logical topology that meets the service requirements. Decide on redundancy zones, QoS boundaries, and failover behavior from the application’s perspective. At this stage, the design should remain vendor- and hardware-agnostic.
Select the products that deliver the service: Choose hardware and platforms that implement the service architecture. Base that choice on service needs such as port density, forwarding capacity, feature support, power budget, and lifecycle fit.
Operate the service, not the product: In production, the goal is service availability, not just device uptime. A switch can be fully operational and still fail the service if an upstream link is misconfigured. Monitoring should reflect the application experience, not only device status.
The Metrics That Actually Matter
Hardware metrics are easy to collect. Device uptime, CPU utilization, and interface error rates tell you about infrastructure health. They matter, but they are not enough.
Service metrics tell you whether the design is actually working:
- Application availability: shows whether users in all segments can reach the application, not just whether a switch responds.
- Round-trip latency to critical services: shows whether you are meeting the SLO, not just whether an interface is up.
- User-experienced packet loss: shows whether video calls degrade during peak hours, not just whether uplink utilization looks acceptable.
- Mean Time to Restore: shows how long it takes for users to recover after an outage, not just how quickly a device comes back online.
This distinction matters because a network can show perfect device uptime while still delivering poor service. BGP and OSPF may both be stable, yet users may still be unable to reach a file server because of an unnoticed asymmetric routing policy.
Design for service metrics. Choose hardware, redundancy, and topology based on what is required to meet them. Document results in terms stakeholders understand, such as application availability, rather than interface counters.
The Plan-Build-Operate Framework in Practice
Modern network design increasingly follows a Plan-Build-Operate lifecycle, which explicitly recognizes that a network is a service.
Plan is the service design phase. It includes requirements gathering, capacity planning, and risk assessment. The output is not just a topology, but a set of design principles and service requirements that guide every later decision.
Build is where product decisions are made. Here, the service design becomes physical and logical architecture. Hardware is selected, configurations are developed, and the infrastructure is staged and validated. Tools such as Ansible, Terraform, and NAPALM belong in this phase because manual configuration at scale is slow and error-prone.
Operate is where the design proves its value. It includes monitoring, incident response, capacity management, and continuous optimization. In mature environments, operational data feeds back into planning for the next design cycle.
Many organizations invest heavily in Plan and Build but treat Operate as an afterthought handled by a helpdesk and ticket queue. That is backwards. Operate is where the service either meets its SLA or fails, so it deserves the same design rigor as the other phases.
Automation Changes the Equation
The rise of network automation has shifted the product-service balance toward the service model, and that is largely a positive change.
When networks are managed with Infrastructure as Code, version-controlled templates, automated deployment pipelines, and configuration validation, the physical product becomes more abstract. You are no longer just configuring a switch; you are declaring the intended state of a service, and automation translates that intent into device-specific settings.
This matters to network designers for two main reasons:
First, it raises the level of abstraction. A designer focused on VLAN IDs and interface descriptions is working at the product level. A designer focused on service zones, policy domains, and intent-based declarations is working at the service level. The latter can move faster, make fewer mistakes, and produce designs that are easier to validate and audit.
Second, it changes how failures are handled. In a manually configured network, recovery often means logging into devices and making changes under pressure. In an automated network, recovery can mean reapplying a known-good baseline quickly and consistently. The design question shifts from how to configure failover to how to automate recovery.
Automation does not remove the need for deep product knowledge. Designers still need to understand hardware capabilities, behavior under load, and likely failure modes. What changes is how that knowledge is applied: less through manual configuration and more through design and validation.
Talking to Stakeholders Like a Service Designer
One practical benefit of thinking in services is that stakeholder conversations become more productive.
Stakeholders do not want a rack of switches. They want the ERP system available during month-end close, reliable video calls for remote staff, and IoT sensors that report consistently across buildings and parking areas.
When presenting a network design, translate each technical choice into a service outcome:
- “We are implementing dual uplinks with LACP” becomes “your applications will stay available if one link or card fails.”
- “We are deploying QoS with a six-class model” becomes “voice and video traffic will be prioritized during congestion.”
- “We are using route summarization at the distribution layer” becomes “routing instability in one building will not spread to the rest of the campus.”
This is the right level of abstraction for the audience. The technical implementation is your concern; the service outcome is theirs.
Where the Product Still Matters
The infrastructure still matters. It is where the service design becomes real, and those infrastructure choices have real consequences.
A switch with too little TCAM can silently drop ACL entries. A router with limited buffer memory can drop traffic during microbursts that average throughput never reveals. A device at end of support will miss security patches, creating risk that no SLA can hide.
A network designer must understand the product layer well enough to see where it can limit the service layer and make decisions that keep those limits from becoming service failures.
Vendor choice, lifecycle planning, capacity headroom, and power and cooling margins are infrastructure concerns, but they directly affect service outcomes. They should be part of the design, not left as procurement afterthoughts.
The Deliverable That Actually Works
The strongest approach is to produce two design documents:
The first outlines SLAs, service requirements, availability targets, recovery objectives, and user impact. This is the version for stakeholders because it explains design decisions in terms of business outcomes.
The second includes topology diagrams, interface tables, routing parameters, QoS policies, and automation playbooks. This is the version for the team that will build and operate the network.
Both documents describe the same network from different perspectives, and both are necessary.
Conclusion: The Network Is a “Productized” Service
Routers, switches, and cables are means to an end. They are the products that deliver the service. Stakeholders will rarely see or care about them as long as the service works.
The job of a network designer is to understand both the means and the end, and to ensure the former reliably delivers the latter. Start with the service, design the architecture, choose the products, and keep operating the service.
The network is never finished; it is always performing.