Architecture Decision Records for Australian Campus IT

SONiCopen networkingcampusADRPoEautomation

In brief

An ADR framework for Australian campus IT teams evaluating SONiC white-box switching, PoE budgets, migration risk, support, and operations.

Key takeaways

An ADR framework for Australian campus IT teams evaluating SONiC white-box switching, PoE budgets, migration risk, support, and operations.

The ADR That Most Campus Teams Never Write

Every Australian enterprise campus network refresh starts with a decision that rarely gets documented: which switching platform and operating system to bet on for the next five to seven years. In most programs, the answer defaults to whichever incumbent vendor already holds the maintenance contract. The choice is never framed as an architecture decision. It is simply inherited.

An Architecture Decision Record, or ADR, is a lightweight governance tool borrowed from software engineering. It captures a single architectural choice, the context that led to it, the options considered, and the consequences of the decision. For campus IT teams in Australia facing a network refresh, an ADR forces the conversation that incumbent vendors would prefer you skip: is open networking with SONiC on white-box hardware a viable alternative to the proprietary switching stack we have always used?

This article gives you a practical framework to answer that question.

What SONiC Actually Is and Why It Matters for Campus

SONiC stands for Software for Open Networking in the Cloud. It is a free, open-source network operating system built on Linux that runs on switches from multiple hardware vendors and multiple ASIC families. Originally developed for hyperscale data centers, SONiC is now a Linux Foundation project with a growing ecosystem of enterprise and campus use cases.

The key architectural facts that matter for an ADR:

Multi-vendor hardware support. SONiC decouples the network operating system from the switch hardware through the Switch Abstraction Interface (SAI). This means your campus fabric can run on commodity white-box switches from different vendors without rewriting your operational tooling.
Containerized, modular design. Each network function runs in its own Docker container. You can upgrade or troubleshoot individual services without taking down the entire switch stack. For campus IT teams managing hundreds of access and distribution switches across multiple sites, this matters.
Standard Linux interfaces. SONiC uses standard Linux tools, JSON-based configuration, and programmatic interfaces. Your existing Linux and automation skills transfer directly. Teams that already manage servers with Ansible, Terraform, or Python can apply the same workflows to network infrastructure.
Production-hardened in the largest data centers. SONiC has been running at scale in cloud service provider networks for years. The feature set includes BGP, RDMA over Converged Ethernet (RoCE), VXLAN, and a full suite of Layer 2 and Layer 3 protocols relevant to both campus and data center designs.

For Australian enterprise campus programs, the practical question is not whether SONiC works at scale. It does. The question is whether your team can operate it, whether the hardware supply chain is viable locally, and whether the total cost of ownership beats the incumbent alternative when you document all the assumptions.

The Australian Context: Why This Conversation Is Different

Australian enterprise IT operates in a market shaped by several factors that make open networking more relevant than many teams realize.

Sovereign infrastructure focus. Australian data sovereignty requirements and government procurement frameworks increasingly reward transparency and supply chain diversity. Open-source NOS platforms like SONiC give enterprises auditable software stacks with no hidden licensing dependencies. When your compliance team asks who controls the code that runs your network, SONiC has a clear answer: a Linux Foundation project with public governance.

Colocation and edge expansion. The Australian data center market is growing rapidly. As David Hirst, CEO of Macquarie Data Centres, explained in a recent discussion about the Australian market, AI workloads are driving a shift from real estate thinking to chip-out thinking in data center design. Campus networks that connect to these facilities need fabric designs that can scale from 10G access to 100G and 400G uplinks without forklift hardware replacements. SONiC on white-box switches supports this path.

Skills shortage and automation pressure. Australian enterprise teams face the same networking skills gap as the rest of the world, compounded by geographic distance from vendor engineering centers. Open networking with SONiC and standard Linux tooling can reduce the specialized training burden. Your Linux administrators can learn SONiC faster than they can learn a proprietary CLI that only exists inside one vendor ecosystem.

Vendor consolidation risk. Many Australian campus networks run on a single vendor for switching, wireless, and management. If that vendor raises license fees, changes support terms, or sunsets a product line, your options are limited. An ADR that documents the open networking alternative gives your leadership a documented fallback position and negotiating leverage, even if you choose to stay with the incumbent.

Building the ADR: A Campus IT Evaluation Framework

Here is a practical ADR structure adapted for a campus switching decision in an Australian enterprise program. Use this as a template, not a finished document. Every site and team has different constraints.

Decision

What switching platform and NOS should we adopt for our campus network refresh?

Context

Describe the current state: vendor, age of equipment, number of sites, port counts, PoE requirements, uplink speeds, management tooling, and support contract terms. Include the business drivers for the refresh: end-of-life hardware, new building fitouts, bandwidth growth, security posture improvement, or cloud connectivity requirements.

Options Considered

Option A: Incumbent proprietary stack. Describe the current vendor, the proposed hardware models, licensing model, support terms, and estimated total cost over the refresh lifecycle. Note any feature gaps or concerns.

Option B: SONiC on white-box switches. Describe the candidate white-box hardware, the SONiC version, the feature parity assessment for your campus use case, the support model, and the total cost estimate. Include the PoE, stacking, and campus-specific features you need to validate.

Option C: Alternative proprietary vendor. If you evaluated a second vendor, document it here. If not, note why the comparison was limited.

Decision Criteria Checklist

Use this checklist when comparing SONiC white-box against proprietary alternatives. Each item should have a documented answer, not a guess.

Feature parity for campus access. Does the SONiC platform support the Layer 2, Layer 3, PoE, 802.1X, LLDP, and QoS features your campus requires? For PoE campus deployments, validate power budget per port, PoE scheduling, and LLDP-MED support.
Uplink and fabric scalability. Can the platform scale from 1G/10G access to 25G/100G uplinks and support EVPN-VXLAN or traditional spine-leaf if you extend to a data center interconnect?
Management and automation. Does the platform support NETCONF/YANG, gNMI, or the API-driven management your team uses? Can you manage it with Ansible, Terraform, or your existing NMS?
Support model. What is the support structure? Community support, commercial SONiC distribution support, or a managed service? For campus programs with 24/7 uptime requirements, this matters.
Total cost of ownership. Compare hardware cost, software licensing (or lack thereof), annual support fees, training investment, and operational tooling cost over the full refresh lifecycle. SONiC eliminates NOS licensing fees, but factor in the cost of building or buying operational expertise.
Migration path. Can you run the new platform alongside the incumbent during a phased migration? SONiC’s containerized architecture and standard interfaces make parallel operation more practical than migrating between two proprietary CLIs.
Compliance and audit. Does the open-source NOS meet your organization’s security audit requirements? SONiC’s public codebase and Apache 2.0 license support code review and compliance verification.

ADR Evidence Matrix

The ADR should not approve a platform because the architecture looks elegant. It should approve a platform only when the team has enough evidence to accept the operational consequences. Use the matrix below as the minimum engineering packet before the decision record is signed.

ADR criterion	Evidence to attach	Reject or rework trigger
PoE and endpoint readiness	24-port or 48-port model tested with APs, cameras, phones, badge readers, and at least 30% spare PoE budget	Any critical endpoint class depends on an untested LLDP-MED, 802.1X, or PoE behavior
Resilience	MC-LAG, STP/MSTP, uplink failure, power failure, and rollback tested during a maintenance window	Access VLANs, voice VLANs, or security devices fail to recover inside the campus SLO
Operations	Runbook covers provisioning, backup, upgrade, rollback, alerting, and spare replacement for 5-7 year lifecycle ownership	Support boundary is unclear between hardware, NOS image, integration partner, and internal team
Automation	NETCONF/YANG, gNMI, Ansible, or existing NMS workflow proves baseline deployment and drift detection	A switch can be changed manually without audit evidence or drift alerting
Commercial model	Hardware, support, training, optics, spares, and operational tooling are modelled over 60 months	The open option saves capex but hides an unfunded operational skill or support gap

Consequences

Document what changes regardless of which option you choose. If you select SONiC white-box, note the training investment, the new support relationships, and the operational workflow changes. If you stay with the incumbent, note the license cost trajectory, the vendor dependency risk you are accepting, and the opportunity cost of not evaluating the alternative.

Common Objections from Incumbent Vendor Advocates

When you raise SONiC in a campus refresh conversation, expect these pushbacks. Having documented responses in your ADR keeps the discussion grounded.

“SONiC is only for hyperscale data centers.” SONiC originated in hyperscale, but the ecosystem has expanded. The modular architecture and SAI abstraction layer make it viable for campus access, aggregation, and distribution roles. The feature set continues to grow with each release cycle driven by the SONiC community.

“Our team does not have Linux skills.” If your team manages any Linux servers, they already have the foundation. SONiC uses standard Linux tooling. The learning curve from proprietary CLI to SONiC is comparable to the learning curve when switching between proprietary CLIs, and the skills are more portable.

“Open source is less secure.” Open source means the code is auditable. SONiC security issues are publicly tracked and patched through a transparent process. Proprietary NOS vulnerabilities are often disclosed on the vendor’s timeline, not yours.

Where xSONiC Fits

xSONiC offers bare-metal switching hardware designed for SONiC deployment across campus and data center environments. For Australian enterprise teams writing ADRs, xSONiC provides a practical hardware path with switches built for enterprise SONiC workloads: campus access and aggregation with PoE, data center spine-leaf with 100G and 400G uplinks, and bare-metal platforms for teams that want to run their own NOS builds.

Explore xSONiC’s product lines to identify hardware candidates for your ADR:

Data Center AI Switches for teams evaluating open switching hardware with SONiC or custom NOS deployments
Access and Aggregation Switches for enterprise campus edge, PoE, and distribution roles
Access Points for Wi-Fi-led campus refresh programs where PoE, uplink, and switching decisions must be modelled together

For deeper technical guidance, review the xSONiC guides on Campus Refresh, PoE Campus, EVPN-VXLAN, and NETCONF.

Next Steps for Your Team

Draft the ADR using the framework above. Even if you ultimately choose the incumbent, the exercise is valuable.
Request a SONiC demo or proof-of-concept with white-box hardware for a non-critical site. Real experience beats theoretical comparison.
Evaluate hardware supply chain and support options for your specific Australian location and scale.
Engage your procurement and compliance teams early. Open source licensing and auditability can be an advantage, but only if the right stakeholders understand it.
Document everything in the ADR. Your future self, and your successor, will thank you for writing down why the decision was made.

The switching platform you choose for your next campus refresh will run for five to seven years. The ADR you write today ensures that decision is deliberate, documented, and defensible, whether you choose proprietary, open, or a hybrid of both.

Engineering FAQ

What should be tested before moving campus switching to SONiC or open networking? Test PoE behaviour, NAC integration, VLAN and policy design, STP or MC-LAG interaction, multicast, monitoring, upgrade rollback, and help-desk workflows. Campus readiness is an operations test, not only a forwarding test.

Where do campus refresh projects usually carry hidden risk? The risk often sits in closets: power budget, old cabling, undocumented uplinks, mixed endpoint types, voice devices, cameras, badge systems, and change windows. Those details should be inventoried before selecting switch models.

How should Australian campus teams structure a pilot? Choose one representative site or building, document endpoint classes, run PoE and failover tests, verify monitoring, train operations staff, and define rollback steps before expanding to the broader estate.

Sources Reviewed

Product fit

Where xSONiC fits

xSONiC can help validate the switch, optics, software image, telemetry, and support assumptions against the actual deployment before a production order is released.