Does “On-Net” Still Matter?
As suppliers use software and partner networks to deliver service across owned and third-party access, the old on-net/off-net distinction is becoming less straightforward. Customers may not need to manage every underlying circuit relationship themselves, but they still need to know who provides the access, what changes because of it and whether the supplier remains accountable when something goes wrong.
In this 11-minute episode of Staying Connected, Tony Mangino is joined by TC2’s Julie Gardner to discuss what Lumen’s Multi-Cloud Gateway expansion says about the changing network market and how enterprise customers should rethink sourcing questions around access, accountability, digital operating platforms and network diversity.
If you would like to learn more about our experience in this space, please visit our Strategic Sourcing & RFx webpage.
Transcript
Tony:
Hello, I’m Tony Mangino from TC2, and this is Staying Connected—the podcast where we talk about what really matters to enterprise buyers navigating today’s technology and sourcing decisions.
Lumen made an interesting announcement recently that caught our attention because, on the surface at least, it sounds like a straightforward networking story. I’m joined today by Julie Gardner, my colleague here at TC2 to discuss what I think is the more interesting story that sits underneath the announcement.
In late August, Lumen announced that it was expanding access to its Multi-Cloud Gateway beyond locations connected directly to its own fiber network. According to Lumen, qualified sites connected through third-party providers can now participate in the same broader cloud-networking environment as its on-net locations.
Lumen says that it can extend the service to more than 10 million U.S. business locations.
Julie, welcome back to Staying Connected, always a pleasure to have you on the program. Let’s start with a simple question – if the customer can increasingly get a common network experience regardless of who owns the physical access, does the traditional distinction between “on-net” and “off-net” start to matter less?
Guest:
Maybe operationally. But commercially and from a sourcing perspective, I’d be careful about saying it matters less.
What Lumen is really demonstrating is that the service layer and the physical access layer can increasingly be separated. The customer may see one portal, one set of network policies, one cloud-connectivity environment and one provider relationship even though some of the underlying circuits come from other carriers.
That can be a very attractive model. The enterprise may no longer want to manage all of those underlying relationships itself.
But there’s an important distinction here: you may want to care less about managing the underlying network. That doesn’t mean you should know less about it.
A Common Experience Over Different Networks
Tony:
That distinction is probably the heart of the episode.
One of the things Lumen emphasizes in the announcement is consistency. A third-party-connected site can participate in the same environment as an on-net location, with common routing policies, segmentation controls, digital management and API capabilities.
If I’m running a large distributed enterprise network, that sounds pretty compelling.
Guest:
It can be. Think about an enterprise with hundreds or thousands of sites. Historically, the architecture and operating experience could vary depending on which carrier had facilities in a particular market.
If a provider can abstract some of that complexity and give you a more consistent operating model, there’s real value in that.
But from the buyer’s side, I immediately start asking: how consistent is the commercial and contractual experience?
If Lumen is saying the network can behave consistently across its own infrastructure and third-party access, does the customer get the same provisioning commitment? The same SLAs? The same escalation process? The same remedies?
The technology can abstract the underlying carrier. The agreement needs to determine whether the accountability is abstracted too.
Tony:
That’s a really important point.
I don’t want to discover during an outage that one location is treated differently because the physical access happens to belong to somebody else.
“Off-Net” Can’t Become an Excuse
Guest:
Right. If Supplier A chooses to procure a circuit from Supplier B in order to deliver the service it sold you, that sourcing decision should generally remain Supplier A’s problem.
That doesn’t mean every third-party access service can carry identical technical commitments. Sometimes there are legitimate differences.
But they should be visible before the customer buys the service.
Tony:
And “off-net” is a catch-all explanation, dare I say excuse.
“The install is taking longer because it’s off-net. The price is higher because it’s off-net. The SLAs are different because it’s off-net.”
Guest:
And some of those explanations may be legitimate. But this is where Lumen’s own proposition creates an interesting sourcing question.
If Lumen can make the service experience look largely the same whether it owns the access or not, then buyers have every reason to ask why the commercial and support experience still needs to be so different. Some differences will be real. Others may just be the way carriers have always done it.
Should We Still Ask “On-Net or Off-Net?”
Tony:
So does the question—“Is this location on-net or off-net?”—need to evolve?
Guest:
I think it does.
I’d still want the answer, but it’s no longer enough by itself.
I’d want to know who provides the underlying access. I’d want to understand whether that changes pricing, provisioning, service levels, repair or escalation. And I’d want those differences presented consistently across every bidder.
Because two suppliers can both label a service “DIA,” for example, while delivering it in very different ways.
One may own the access. Another may procure it directly from a local carrier. A third may use an aggregator. Those differences can matter.
Tony:
Which gets us into comparability.
If suppliers are increasingly able to wrap a common software and service layer around different physical networks, maybe buyers need to become more precise about what they’re actually comparing.
The Digital Experience Becomes Part of the Network
Guest:
That’s another interesting part of Lumen’s announcement.
They aren’t just talking about reaching more buildings. They’re talking about customers managing the environment through Lumen Connect and APIs, applying common policies and bringing locations into a broader cloud-networking model.
That tells you something about where the market is going.
The enterprise-network buying decision isn’t only about fiber footprint and POP locations anymore. The digital operating experience is becoming part of the service.
Tony:
And I’m not sure traditional network RFPs always give that enough weight.
Guest:
I agree.
Can you provision services digitally? Change bandwidth? Retrieve inventory? Access performance data? Apply policies consistently? Integrate that information into your own systems?
Those capabilities can materially affect how easy the network is to operate.
So perhaps one implication of this market shift is that enterprise customers need to evaluate the operating platform with the same rigor they evaluate the physical access.
But Don’t Let Abstraction Hide Diversity
Tony:
There is one place where I absolutely do not want the underlying network disappearing from view, and that’s diversity.
Guest:
Neither do I.
This is one of the risks with aggregation. You can have two different supplier names and still have common underlying infrastructure.
The primary circuit may be sold by one provider, the backup by another, but both may ultimately rely on the same local access carrier or a common physical route.
If resiliency matters, supplier diversity is not the same thing as network diversity.
Tony:
So if the market is getting better at hiding the complexity from the customer operationally, or if it’s simply more opaque, the customer may actually need better disclosure during sourcing.
Guest:
That’s exactly the balance.
You want abstraction where it makes your life easier. You want transparency where it protects your risk position.
Bidders should disclose underlying providers and substantiate diversity rather than simply checking a box that says the two circuits are diverse.
This Is Bigger Than One Lumen Announcement
Tony:
There’s another reason I think this announcement is worth paying attention to.
It doesn’t appear to be an isolated move by Lumen.
The company has already expanded other on-demand network capabilities beyond its own footprint, and earlier this year it completed the acquisition of Alkira. Lumen has described the broader direction as creating a more unified control plane across its own network, off-net services, cloud environments and other parts of the enterprise estate.
So perhaps the bigger story isn’t ten million additional locations.
Maybe it’s that Lumen increasingly wants the customer to stop worrying about where the network boundary is.
Guest:
I think that’s fair. And from a customer standpoint I’d modify that slightly.
I may want to stop operating around that boundary. I don’t necessarily want to stop understanding it.
If Lumen—or any other provider—can give me a consistent experience across a mixed underlying environment, that may be exactly what I want to buy.
But I still need visibility into the things that affect my cost, risk and flexibility.
What Should Change in the Next Network RFx?
Tony:
So let’s bring this back to a customer preparing for a network sourcing event.
What should they do differently?
Guest:
I’d start by changing the questions.
Instead of simply asking, “What percentage of my locations are on-net?” ask what changes when they aren’t.
Instead of just asking for a network footprint, ask how much of the estate can operate under a common digital service model regardless of who owns the physical infrastructure.
Instead of asking whether the supplier has APIs, ask what the customer can actually provision, change, monitor and retrieve through them.
And instead of asking whether two proposed circuits are diverse, require evidence supporting the diversity assertion.
Those are much more useful questions in the kind of network model Lumen is describing.
Tony:
And I’d probably add one more.
If the supplier is selling me abstraction, then I want the supplier to own the abstraction.
I don’t want the complexity hidden during the sale and handed back to me when something goes wrong.
Guest:
That’s the standard I’d use.
The best service model reduces complexity for the customer without reducing accountability to the customer.
Closing
Tony:
And I think that’s the takeaway.
Lumen’s Multi-Cloud Gateway announcement is interesting because it gives us a glimpse of how enterprise networks are evolving.
The provider delivering the customer experience, software controlling the environment all while the carrier owning the physical circuit increasingly may not be the same company.
That can create broader reach, greater consistency and a much simpler operating model.
But simplicity shouldn’t come at the expense of visibility.
Enterprise customers may eventually care less about managing whether every service is technically on-net or off-net. They should still understand, however, who is underneath the service, what changes because of it and whether the supplier is truly accountable for the integrated outcome it is selling.
To our listeners, if you would like learn more about how to structure your next RFP in a changing network environment, or if you’d like to discuss other technology strategy, sourcing and cost reduction needs with Julie, me, or any of our TC2 and LB3 colleagues, please give us a call or shoot us an email.
You can also stay current by subscribing to Staying Connected, by checking out our websites, and by following us on LinkedIn.