[wp_tech_share]
follow us in feedly
Share

I attended Mplify’s member summit in Boston several weeks ago, where I also served as a judge for its NaaS awards. One theme stood out: enterprise networking and security are becoming more integrated, yet delivering that integration across the broader communications service provider industry remains surprisingly difficult. Technology providers are combining capabilities enterprises historically bought separately, while communications service providers are working to make their networks and operational systems function as a coordinated ecosystem.

Both efforts are moving toward the same objective: making enterprise networking and security simpler to consume and operate. In my Distributed Cloud Networking (DCN) research at Dell’Oro Group, this tension is becoming increasingly important. The question is not whether Network-as-a-Service (NaaS) will evolve beyond connectivity. It already is. The more interesting question is whether the industry can deliver an integrated experience without forcing enterprises to rely on a single technology provider.

Four observations from Boston stand out.
The Networking and Security Stack Is Converging, but Innovation Is Far from Over

In my DCN research, I look at the enterprise WAN through three interconnected domains: the user/WAN edge, WAN middle mile, and cloud/application edge. Each has traditionally been served by different technologies and vendors. SASE and SD-WAN address secure user and branch connectivity, WAN-as-a-Service brings greater flexibility and programmability to the middle mile, and multi-cloud networking extends connectivity and security controls closer to distributed applications and workloads.

The boundaries between these domains are becoming less rigid. Convergence is happening horizontally as providers extend their capabilities across the three domains, and vertically as networking, security, observability, and automation become more tightly integrated. For some enterprises, this creates an opportunity to collapse a complicated networking and security stack into a more unified operating model, with fewer control planes, fewer integration points, and more consistent policy enforcement.

However, convergence should not be mistaken for the end of specialization. Significant innovation continues within each domain, and some of the more interesting developments are happening outside the traditional SASE conversation. The WAN middle mile, for example, is gaining renewed importance as enterprises look to dynamically connect private data centers, public clouds, AI factories, and emerging neocloud providers. At the cloud edge, application-aware networking and security continue to evolve, while SASE vendors are extending beyond traditional user-to-application traffic into broader infrastructure use cases.

AI is accelerating these developments, but it did not create the underlying challenges. Cloud adoption, distributed workforces, and application decentralization were already reshaping enterprise networking. AI adds urgency through more dynamic workloads, distributed inference, and new requirements for data governance and security. The important takeaway is that the market is still innovating within individual domains even as the broader technology stack converges.

 

Two Paths Toward a Simpler Enterprise Experience

One response to these market dynamics is technology convergence. Providers are extending their capabilities across traditional product boundaries to deliver more networking and security functions through a common platform. The appeal is understandable: enterprises increasingly want consistent policy, visibility, and operational control across users, branches, cloud environments, and applications. A more integrated provider can potentially reduce the complexity of making those pieces work together.

However, there is another path: a federated ecosystem of specialized technology and service providers. Not every enterprise wants to standardize on one vendor, nor will one vendor necessarily deliver the best capabilities across every domain. Existing investments, geographic requirements, specialized security needs, and heterogeneous application architectures will continue to create demand for best-of-breed solutions. The challenge is making those independent technologies behave like a coordinated service rather than a collection of individually managed products.

I do not see these approaches as mutually exclusive. Even highly integrated platforms depend on third-party connectivity and infrastructure to extend their reach. Likewise, a multi-provider ecosystem can offer customers a unified experience if the underlying integration is mature enough. This creates an interesting competitive dynamic: innovation within individual domains remains valuable, but the ability to integrate and operationalize those technologies becomes equally important.

In that sense, the real competition is not simply single-vendor versus multi-vendor. It is about which approach can deliver the required capabilities with the least operational friction, while preserving the flexibility enterprises need as their architectures evolve.

 

Boston Highlighted the Gap Between Federation and Execution

Federation was one of the strongest themes throughout Mplify’s Boston event. There was broad agreement that no single service provider can deliver every component of a global enterprise network, particularly as cloud and AI workloads become more geographically distributed. More importantly, several presentations showed that industry collaboration is moving beyond architecture diagrams into practical commercial workflows.

Bob Victor, Comcast Business’s Chief Product Officer and Mplify Board Chair, discussed efforts to connect Comcast and Colt’s automated workflows. Both companies have invested in internal automation, but transactions between them have historically involved spreadsheets and manual handoffs. Verizon described its use of Mplify’s Lifecycle Service Orchestration (LSO) Sonata APIs for wholesale transactions and its direction toward replacing legacy Access Service Request processes with standardized interfaces. Equinix and Comcast also discussed efforts to simplify service discovery and connectivity procurement through interconnected marketplaces.

These developments stand out because they show progress toward making independently operated networks function as a coordinated supply chain. However, the discussions also exposed a significant maturity gap between today’s implementations and the vision of fully automated, federated networking. Automating service discovery and quoting is not the same as automating end-to-end delivery. A provider may return a quote in seconds while installation, provisioning, troubleshooting, and performance assurance still depend on manual processes.

Legacy OSS/BSS environments, inconsistent operational data, and limited automation among smaller partners remain obstacles. There is also a commercial dimension that received welcome attention in Boston. Standardized interfaces do not automatically resolve contractual complexity, layers of reseller margin, service-level accountability, or ownership of the customer relationship. These are not secondary issues. They directly affect whether a multi-provider solution can compete with the simplicity an integrated platform promises.

This was one of my biggest takeaways from Boston. Federation requires business-model innovation alongside technical interoperability, and the industry still has considerable work to do on both fronts. The opportunity is significant, but getting multiple providers to communicate is only the first step toward making them operate as one.

 

Standardization Is Becoming More Important, Not Less

Having participated in standards efforts at the IETF and Trusted Computing Group, I appreciate the work required to build industry consensus and turn technical specifications into interoperable implementations. Standards do not eliminate competition or technological differentiation. Done well, they provide a common foundation on which companies can innovate without forcing customers into proprietary integration models.

This is why I view Mplify’s work as strategically important. The alliance has spent years developing Carrier Ethernet service definitions, LSO APIs, common product models, and certification programs. These assets are increasingly relevant as enterprises seek cloud-like consumption models across multiple communications service providers. Standardization also creates an opportunity for smaller and specialized providers to participate in larger ecosystems without having to build custom integrations for every commercial relationship.

Now Mplify is extending that work toward agentic automation and federation. Its LSO framework now supports the Model Context Protocol (MCP), and ongoing initiatives are developing reusable AI-agent capabilities, trusted provider discovery, and agent-to-agent coordination. The direction is promising because it builds on the existing service definitions, data models, and transaction workflows rather than assuming AI agents can independently solve the complexities of network operations.

In fact, AI may increase the importance of standardization. An agent that can discover and order connectivity is useful, but an agent that can reliably coordinate those actions across multiple providers while respecting commercial agreements, workflow sequencing, and security policies is far more valuable. Achieving that requires common definitions of services, authorization, operational states, and expected outcomes. It also requires mechanisms to verify that the agents and underlying systems behave as intended.

The industry is not there yet. The agentic federation vision remains ahead of broad production adoption, and considerable work remains on conventional service automation. Still, I see the effort as directionally constructive. The challenge for Mplify and its members will be translating the standards and architectural work into repeatable implementations that deliver measurable improvements in service delivery and operational efficiency.

 

What I Will Be Watching

The next phase of NaaS will be shaped by two related developments. First, how far can technology providers simplify enterprise networking through horizontal and vertical integration? Continued innovation across the user edge, middle mile, and cloud edge will create new possibilities, but comprehensive technology coverage does not automatically translate into a coherent operating model.

Second, how quickly can the broader service provider ecosystem close the interoperability gap? Mplify’s standards and certification work can help, but success ultimately depends on adoption, operational integration, and commercial execution. The strongest evidence of progress will not be another architectural framework or federation demonstration. It will be the ability to consistently discover, order, deliver, secure, and assure services across multiple providers without pushing the complexity back onto the enterprise.

For enterprises, the outcome matters more than the architecture. Integrated platforms can absorb more of the enterprise networking and security relationship, while specialized providers can preserve their differentiation by becoming easier to integrate and consume. I expect both models to remain relevant, with competitive advantage increasingly determined by how effectively providers turn their technology and partnerships into a simpler customer experience.

Boston reinforced my view that the future of NaaS is not solely about who can assemble the broadest networking and security stack. It is also about whether the industry can make a network assembled from multiple providers operate with the simplicity and accountability enterprises increasingly expect from a single platform. That is the opportunity Mplify is helping the industry pursue, and it is where much of the next chapter of enterprise WAN innovation remains to be written.