UTS’s network upgrade: buying a platform, keeping control (Part 2)
Choosing a campus network also means choosing how the institution will operate it: which tools explain a fault, how access decisions are enforced, what the support partner can see, and which skills the university needs to retain.
That is the more consequential part of UTS’s planned move to Nexon and Extreme Platform ONE. Bringing those activities together could save staff substantial effort. It also makes the supplier’s software, subscriptions and support arrangements more central to the life of the network.
I would judge the investment by whether it leaves UTS better able to understand, operate and change its infrastructure. That means looking beyond the AI label, including at the years of development behind it.
More than Wi-Fi 7, Part 2: A modern campus for what’s next. Part 1: From strategy to selection examines the decisions that shape the service long before installation.
Campus networking already had an operational history
UTS’s earlier environment was substantial. An Alcatel-Lucent Enterprise case study records a January 2015 implementation serving more than 37,000 users, with OmniSwitch switching, OmniAccess wireless and OmniVista management tools. ALE’s separate customer account discusses automation, guest access and resilience using Shortest Path Bridging.
Those vendor accounts are historical snapshots, rather than an inventory of everything still installed. They nevertheless establish that central management, resilience and easier administration were already part of the campus-network story.
The current UTS-attributed announcement identifies Wi-Fi 7, Extreme Platform ONE, campus-wide wired and wireless renewal, security controls and an 18-month build. Detailed hardware choices, enabled AI functions and the commercial breakdown remain unpublished. The discussion here examines the implications of the platform approach, rather than claiming those implementation decisions are known.
Aruba and Extreme were doing this before the current AI wave
Hewlett Packard Enterprise’s Aruba business provides useful context. It is not named as a delivery partner in this UTS announcement, and this history says nothing about who bid for the contract.
2020 is a sound reference point for Aruba’s explicit AIOps positioning, with earlier AI analytics work already visible in 2018. Extreme’s own announcements also take its AI-assisted cloud-management story back to 2019.
| Date | Documented milestone |
|---|---|
| March 2018 | HPE’s Cape Networks acquisition announcement describes its relationship with Aruba NetInsight and AI-powered analytics and assurance. |
| October 2019 | Extreme announces ExtremeCloud IQ with machine learning and AI, and introduces Co-Pilot automation features with initial use cases planned to roll out that year. |
| June 2020 | Aruba introduces ESP, explicitly combining AIOps, security and unified infrastructure, with Aruba Central managing wired, wireless and SD-WAN operations. |
| May 2021 | Extreme announces a CoPilot public beta offering network baselines, anomaly detection, possible root causes and recommended remedies. |
These are dated product milestones, not a claim about who invented AIOps or when every promised feature became available. AIOps applies AI and analytics to operational information so staff can identify problems and decide what to do about them. Earlier platforms already promoted automated remediation and natural-language search.
There has been further development. In March 2024, HPE announced generative-AI additions to Aruba Central’s AI Search, complementing its existing machine-learning capabilities. Today’s language interfaces and agent workflows therefore need to be assessed against an established operational baseline.
For a buyer, that history raises the standard of proof. A supplier should be able to demonstrate which tasks its current platform makes easier, how reliably it does so and what staff still have to investigate themselves. The presence of AI in the product name cannot answer those questions.
The useful gain is a shorter path from symptom to cause
Extreme Networks CTO Nabil Bukhari makes the case that the company builds the full networking stack, from hardware to AI, at Extreme Connect 2026. Photo: Mitch Wagner for Fierce Network.
Extreme’s Platform ONE material describes integrated networking, security and AI assistance. Agent ONE Coworker is presented as analysing operational information, identifying emerging problems and guiding investigations.
Consider the student from part one who connects to Wi-Fi but cannot open a teaching resource. An administrator may need evidence from the wireless network, authentication system, access policy and upstream services. A platform that connects those observations could save time otherwise spent gathering logs and moving between consoles.
That is a meaningful operational benefit if it works reliably. The important demonstration is whether the administrator can follow the evidence to a diagnosis, recognise what the platform cannot see and restore the service.
Wireless capability still matters. Wi-Fi 7 introduces options such as Multi-Link Operation and wider channels, described in the Wi-Fi Alliance’s certification announcement. Their value depends on compatible clients and the campus design. A newer radio cannot, by itself, fix a failed identity service or an incorrect access rule.
Similarly, the network requirements of an AI application depend on where it runs and how it moves data. Using AI to support research and using AI to diagnose a network fault are separate use cases that need separate evidence.
The platform also changes the supplier relationship
Combining tools can reduce integration work and give the university a clearer support path. It also means that more of the institution’s operational knowledge may accumulate in the supplier’s system: device history, policy, investigation records and automated workflows.
I would make access to that knowledge part of the evaluation. Can the university export useful records and configurations? Can its staff inspect the evidence behind a recommendation? What remains available during a management-service outage? Which tasks depend on an active subscription, and what happens when the institution changes service provider?
Those are questions to resolve in the design and contract, not findings that UTS’s selected solution has deficiencies. Different platforms and deployment models will answer them differently.
There are real distinctions within the product offering. Extreme says its Platform ONE Security subscription adds Universal ZTNA, cloud public-key infrastructure and certificate lifecycle management. Those capabilities should be evaluated against the licences actually purchased. Platform ONE product details.
For any multi-year platform purchase, I would want the operating budget to explain renewals, staff training, support responsibilities and the cost of an eventual transition. Close integration can be worth paying for. The institution needs to understand the continuing commitment it creates.
The university still needs people who can challenge the answer
In education IT, an incorrect network diagnosis can consume time the classroom does not have. Faster recommendations help when staff can evaluate them and choose an appropriate response.
Suppose a system recommends changing wireless settings after detecting congestion. Someone still needs to understand the affected space, the devices using it and the timing of the change. A technically plausible recommendation may be unsuitable during an assessment or for specialist equipment with particular requirements.
I would expect an operating model to distinguish observation, recommendation and permission to act. Routine, well-understood changes might be automated within agreed limits. Changes with wider consequences need an accountable owner, an understandable record and a tested recovery path.
The internal team’s work can change as routine effort falls away. Architecture, identity, policy, integration and incident judgement still need attention. A support partner can add capacity and expertise, while the university retains enough knowledge to set requirements, assess advice and direct recovery.
That is why staff development belongs alongside the platform investment. An institution should be able to explain why its network behaves as it does, even when software performs much of the routine work.
A more capable institution is the outcome to look for
I would want the project to establish a baseline before migration: how often users fail to connect, how long incidents take to diagnose, how many changes need recovery, and how readily the internal team can investigate without escalation. Those measures connect the promised efficiency to the experience of students, staff and support teams.
The results also need an owner after handover. An initial improvement means less if knowledge gradually disappears, routine changes become harder to obtain or renewal decisions arrive without anyone understanding the dependencies.
UTS’s modernisation will eventually become the environment another generation has to replace. The strongest outcome would be a university with clearer knowledge of its services, better tools, capable staff and greater confidence in making that next change.
That is the thread joining these two articles. Good procurement establishes what the institution needs to be able to do. A successful platform investment gives its people the means to keep doing it.
Read Part 1: From strategy to selection.
This article draws on the linked UTS announcement, historical customer material and dated vendor releases. Aruba’s history provides industry context; it is not evidence of participation in UTS’s procurement. The operational examples and proposed evaluation criteria are my analysis.