A few months ago, I got pulled into an escalation at a customer’s distribution center. The AGV fleet kept dropping packets in multiple aisles, and by the time I got into the conversation, several teams were already involved: the SI’s senior wireless architect, the WLAN vendor’s escalation engineer, the AGV integrator, the customer’s IT lead, and an operations manager who just wanted his robots to stop stalling.
There was a lot of data available, but it was isolated in different tools: the WLAN design, the post-deployment validation data, the WLAN OEM dashboard, the AGV dashboard, and the site’s operational history. None of those tools could see the others. The only place it all came together was in the heads of the people on the call, mostly the architect’s.
Around the same time, a VP of Engineering walked me through his Wi-Fi tooling. His team runs half a dozen tools for Wi-Fi alone — multiple vendor controllers, separate design and validation tools, monitoring and troubleshooting platforms, and an aggregation layer stitched across them. Half a dozen tools, one technology. Now add private 5G, DAS, IoT, OT, and security on the same sites, each with its own lifecycle and operating workflow.
Those two conversations are the same story, and I’ve heard versions of it from enough SIs over the past year that it now feels like a pattern — Wi-Fi shop, DAS specialist, private wireless boutique, carrier partner, Tier 1 multi-tech practice. The senior engineer is still the integration layer. The bottleneck isn't the engineer; it's how few of them exist and how much each customer site now expects of them.
These aren’t teams that lack expertise. Most have strong Wi-Fi engineers, RF specialists, DAS experts, private wireless teams, field teams, security teams, and NOC crews who know how to keep customer environments running. The strain is underneath that expertise, in the seams between design, validation, monitoring, troubleshooting, management, and security across multiple wireless technologies.
The customer still asks why the site isn’t working.
In Edition 1, I argued that physical AI is changing what connectivity has to support. In Edition 2, I argued that the limiting factor is the cross-domain expert who can make complex wireless environments behave in the real world. This edition is about the SI operating model: how to make that scarce expertise reusable across the full lifecycle of customer sites.
When people talk about converged wireless, they usually start with the technology stack: Wi-Fi, private cellular, DAS, IoT, OT, and security. That matters, but it is only half the problem.
The other half is lifecycle fragmentation. Design lives in one set of tools. Validation lives in another. Monitoring and troubleshooting happen somewhere else. Security policy and identity often sit with a different team. Managed services inherit alerts, tickets, and escalations, but not always the design assumptions that explain why the site was built the way it was.
That is the real convergence problem. Wi-Fi, private cellular, DAS, IoT, OT, and security never grew up as one operating discipline. Neither did design, validation, monitoring, management, troubleshooting, and security. Each developed its own tools, vendors, certifications, workflows, and handoffs.
For years, system integrators were the safety valve. The senior engineer who knew enough across RF, device behavior, segmentation, validation data, controller telemetry, change history, and operations could make the pieces work together. That became one of the SI’s greatest advantages.
It is also becoming a constraint. The engineer who could hold the technology stack and the lifecycle context in one head is now expected to do that across too many customer sites. That math doesn’t scale.
The expensive seams are not only between vendors. They are between lifecycle stages: design to validation, validation to monitoring, monitoring to troubleshooting, troubleshooting to managed services, and security across all of it. The customer experiences the seam as downtime, poor performance, slow troubleshooting, or uncertainty about who owns the issue. The SI experiences it as margin pressure. Every time a senior engineer reconstructs site context from old drawings, as-builts, RF survey files, controller dashboards, tickets, emails, and memory, cost enters the system. Every time the NOC escalates because it can see the alert but not the design intent, cost enters the system again.
This isn’t only anecdotal. EMA’s 2025 Network Observability Maturity Model research, published with BlueCat, found that 87% of organizations use multiple observability tools and only 29% of alerts are actionable.[1] Tool sprawl isn’t just an enterprise problem — it becomes the SI’s inheritance on every engagement.
Vendors aren’t standing still, either. Many are shipping agentic operations platforms, domain-specific digital twins, and AI-enabled observability aimed at this same pain point, and single-vendor consolidation is one answer to the seams. But most customer sites aren’t single-vendor. A WLAN vendor will naturally build the best view of its WLAN estate, a private wireless vendor will build around its RAN, core, spectrum, and device model, and a DAS vendor will build around in-building coverage and carrier workflows. Those tools matter, and SIs will keep using them. The SI’s problem is different: the SI isn’t accountable for one vendor’s view of the world. The SI is accountable for the customer site.
When a robot stalls, a scanner drops, a nurse’s device roams poorly, or a factory cell slows down, the root cause may sit across Wi-Fi, private 5G, DAS, OT segmentation, device identity, RF behavior, configuration, lifecycle handoffs, or a change in the physical environment. Vendor tools optimize inside a stack. Lifecycle tools optimize inside a stage. SIs operate across both.
The missing artifact is not another dashboard. It’s an operating memory of the customer site: a persistent model that connects technologies and lifecycle stages, from design and deployment to validation, monitoring, management, security, troubleshooting, managed services, and renewal — capturing what was designed, why it was designed that way, what was deployed, what changed, what failed, what was fixed, and which assumptions still matter.
In converged wireless, the mature version of that operating memory may look like a live digital twin. The label matters less than the operating discipline. What matters is that design intent, physical context, predicted performance, RF behavior, topology, telemetry, security policy, incidents, and change history start to live in one shared picture instead of separate lifecycle snapshots. A static model supports a project; a living model supports a service. For AI, the distinction matters even more: AI attached to fragmented dashboards can summarize alerts, while AI grounded in a converged site model can reason from context.
The model needs five layers:
No single layer is worth much by itself. The value sits in the comparison: what did we design, what did we predict, what did we validate, what changed, and what’s happening now? An engineer who can answer all five questions in one place is reasoning at a level fragmented tools don’t allow — and so is an AI. The difference isn’t simply AI; the difference is what the AI can see.
The honest objection: walk tests are snapshots, and an unmaintained site model is just the as-built problem all over again — a stale document with better graphics. Keeping the model live is real work. Telemetry has to be normalized across vendors that don’t share schemas, and drift between the model and the field has to be treated as a first-class signal, not an embarrassment. That maintenance is exactly what a managed-services tier is for, and it’s a fair test to put to any tool in this category: if it can’t show you where its model disagrees with reality, it’s a drawing, not a twin.
That's roughly how the AGV ticket has played out so far. It started as a Wi-Fi problem in multiple aisles and walked the usual multi-party path — SI, WLAN OEM, AGV vendor, customer IT — each investigating from inside their own tools, none of them able to see the others. The customer eventually moved the AGV fleet onto private 5G, and the symptoms came back on the new stack. The investigation is still open. When a site can’t explain itself, swapping the wireless layer doesn’t fix the problem; it relocates it.
In a converged operating model, the site tells that story faster. The physical layer shows the original racking and aisle assumptions. The design layer shows why that aisle mattered for AGV movement. The prediction layer shows expected coverage and roaming behavior across both Wi-Fi and private 5G. The walk-test baseline shows where performance was validated after deployment. Live telemetry shows the drift; change history shows what moved and what didn’t. The model can compare the network against the site, not just the network against itself — and when the symptoms persist across two different wireless stacks, that comparison is what tells you to stop looking at the radio and start looking at the environment.
That turns a broad escalation into a focused investigation, and it’s the larger point: converged operations isn’t about fewer tools or lower cost so much as a better reasoning system for the customer site.
There’s a business-model question underneath all of this. The customer should own the site data: floor plans, assets, telemetry, tickets, change history, operational records. The SI owns the methodology: templates, validation patterns, design assumptions, vertical playbooks, troubleshooting logic, and the operating process that turns the data into outcomes. That split keeps the model customer-aligned while letting the SI build reusable IP across sites.
It also means the operating memory shouldn’t become hidden delivery overhead. It can be a site-based managed-services tier: keep the model current, maintain the validated baseline, track drift, feed the NOC, and use every incident to improve the site memory. That’s a different commercial posture from “we installed the network, here’s the closeout package.” It says: we understand how this site is supposed to behave, we know when it drifts, and we can operate it with context.
Large integrators already have methodology IP: playbooks, validation checklists, reference designs, vertical templates, deployment frameworks, escalation paths, security handoffs, and managed-services processes.
The question is how much of that IP still lives in PowerPoint, Visio, spreadsheets, SharePoint folders, regional practice knowledge, and senior people's heads.
For Tier 1s, the opportunity is not more regional heroics. It is lifecycle consistency at scale.
I'd start in three places.
First, audit the methodology IP across the full lifecycle. Which discovery templates, design patterns, validation checklists, as-built standards, NOC runbooks, escalation workflows, security review processes, managed-services handoffs, and renewal playbooks should become repeatable operating assets?
Not everything should be encoded. Some judgment still has to be taught through apprenticeship. But a 30-day audit by senior architects will show what is repeatable, what needs structure, and what is still tribal.
Second, standardize the customer-site model across regions. A hospital wing, warehouse, stadium, or factory cell should not be modeled differently because a different regional team delivered it. Regional expertise matters; the operating model should travel.
That matters even more when the customer site moves from design to validation, from validation to monitoring, from monitoring to escalation, and from escalation to managed services. The site model should not reset at every handoff.
Third, move toward site-level profitability and risk. Most large SIs understand practice-level P&L, but converged operations breaks at the site level. The site is where design debt, escalation load, lifecycle handoff quality, security complexity, and managed-services margin actually show up.
Which sites consume disproportionate senior-engineer time? Which carry the most design debt? Which have the weakest design-to-NOC handoff? Which repeatedly create cross-domain escalations? Which would be hardest to hand over if a key architect left tomorrow?
You cannot manage an operating model you do not measure.
Build, partner, or buy is a real choice. Build the methodology layer where it differentiates you. Partner where platform plumbing, telemetry normalization, or model maintenance is not your core advantage.
The operating model is the non-negotiable part.
Tier 2 and specialist SIs usually do not have Tier 1 platform budgets. But they often have something just as valuable: customer intimacy and vertical depth.
A healthcare SI knows how a hospital behaves. A warehouse SI knows racking, scanners, shift patterns, loading docks, and AGV paths. A manufacturing SI knows cells, machinery, interference sources, maintenance windows, and OT constraints.
That knowledge is hard to replicate. It is also fragile if it lives only in the heads of a few senior people.
Their risk is dependence on those people. Their opportunity is making that vertical judgment reusable.
I'd start with two moves.
First, pick three lighthouse customers where the pain crosses both technology and lifecycle. Look for sites where Wi-Fi, DAS, private wireless, OT, IoT, security, and device identity interact with design assumptions, validation data, monitoring, troubleshooting, management, security review, and managed-services handoff.
These should be customers where the same senior person keeps getting pulled back in because the site cannot explain itself.
Propose the operating model around shared site representation, validated baselines, site-based SLAs, design-debt visibility, and managed-services context. Three customers are enough to prove the model and few enough to learn from mistakes.
Second, map where site knowledge disappears before choosing tools.
Does it disappear after design? After validation? During deployment? During monitoring? During security review? During escalation? During managed-services handoff?
That answer should drive the tooling decision, whether the answer is better source-of-truth discipline, RF planning, observability, automation, telemetry integration, digital-twin capabilities, or some combination.
The platform question matters, but it should not come first.
The better question is: which parts of our site knowledge disappear after every project, and which parts should become reusable across customers?
For Tier 2 SIs, the commercial motion should start small. This does not need to be a company-wide transformation program on day one. It can start as an enhanced managed-services offer for a few high-value sites: keep the site model current, maintain the validated baseline, track drift, and give the customer a clearer operating picture of the environment they depend on.
Tier 2 SIs do not win by acting bigger than they are.
They win by putting their best engineer's context on every site they support.
Wi-Fi 7 is already moving into enterprise production: IDC reported that Wi-Fi 7 reached 39.7% of dependent access point segment revenue in Q4 2025, up from 10.25% a year earlier.[2]
Private LTE and 5G are moving beyond pilots: Berg Insight counted 6,500 private LTE/5G networks deployed globally at the end of 2025, excluding proof-of-concept projects, and forecasts 32,600 by 2030.[3]
AI-enabled operations are on nearly everyone’s roadmap while trust and deployment maturity lag behind: Broadcom’s State of Network Operations 2026 found that 92% of companies plan to use AI-enabled network operations, only about two in ten (23%) have deployed them, and 71% don’t fully trust AI to make network operations decisions. The same research found that 76% of organizations rely on third parties to fill expertise gaps.[4]
That last number is the SI opportunity in one line. The market needs SIs more than ever, and the old labor model makes them harder to scale at exactly the wrong moment. The operating model has to change before customers feel this pressure at full scale — not after every escalation path is already overloaded.
Disclosure: my company builds in this category, so I have a point of view — but the operating problem exists regardless of which tools an SI chooses.
I think this is where the SI market is headed. Not because digital twins are fashionable, and not because AI will magically fix operations, but because the current model asks too much of too few people. The customer site has to carry more of its own memory.
The senior RF architect, wireless engineer, and NOC lead don’t become less important in that world. Their judgment becomes the highest-leverage asset in the firm, and the SI that can preserve it, apply it across sites, and put it in front of every engineer who touches the customer environment will have the advantage. That’s what scales in the converged era.
1. EMA, The Network Observability Maturity Model: How to Plan for NetOps Excellence (2025), published with BlueCat; 87% multiple-tool and 29% actionable-alert figures. BlueCat announcement
2. IDC Worldwide WLAN Tracker, Q4 2025: Wi-Fi 7 accounted for 39.7% of dependent access point segment revenue, up from 10.25% a year earlier. IDC summary
3. Berg Insight, The Private LTE/5G Network Market (4th edition, February 2026): 6,500 deployments at end-2025 excluding PoCs, forecast to reach 32,600 by 2030 (38% CAGR). Berg Insight release
4. Broadcom with Dimensional Research, The State of Network Operations, 2026: AI and its Effect on Enterprise NetOps (November 2025): 92% plan to adopt AI-enabled operations, 23% have deployed, 71% don’t fully trust AI with network operations decisions, 76% rely on third parties to fill expertise gaps. Report landing page
