Engineering-led vs. Design-led Telecom Services in an SDN/NFV World

I've recently been spending a fair amount of time covering service-provider network virtualisation in terms of general NFV/SDN direction, and how that might impact the shape of future services, as well as the infrastructure itself.

Some of that relates to evolution of routers and switches with SDN, virtualised network cores and aspects of the access/radio network like Cloud RAN. Here, thinking is being led by the "usual" major vendors like Cisco, Ericsson & Huawei, as well as plethora of startups.

Also, quite a lot my Future of Voice and WebRTC research has pointed towards virtualisation of application-layer elements like media-processing, SBCs, IMS elements and so forth. Dialogic, Metaswitch, Oracle, HP, Broadsoft and others regularly crop up here, often pointing to the blurred boundaries of telcos' future NFV service infrastructure with that of third-party "cloud communications" platforms.

[Disclosure: many of the companies mentioned here are Disruptive Analysis clients - but coverage here is for illustration, not endorsement]

One recent discussion with Cisco execs triggered a chain of thoughts about whether SDN/NFV actually helps operators with new service creation and deployment. The example given as a demo during a recent analyst event was the ability for a telco to add a new VPN service to its small-business networking portfolio. This was achieved by reprogramming the network nodes without human intervention or extra boxes, and automatically adding the new offering to the catalogue. In theory, it should make it easy for SME customers to just add the remotely-created and -provisioned VPN service to their existing broadband, or obtain it as part of a bundle along with other cloud application propositions, like Office 365 or Salesforce.

The assertion was that this enabled "easy service creation" and this model could be extended to all areas of telecoms applications and capabilities, adding extra network APIs such as QoS/SLAs as well.

I disagreed, and after a more-detailed discussion with a few people, I came to an interesting conclusion:

• For standard or "normal" services with a heavy "network" component and limited UI requirements, it will probably help to have SDN
• For truly innovative design-led / web-centric telecom services, SDN will be mostly irrelevant, although NFV and other cloud platforms might help

This fits with a model I've been talking through in many of my recent client engagements and public presentations - the difference between a services curator and a services designer. A curator takes pre-existing services (from internal groups, vendors or partners) and packages/distributes/delivers them to end-users. A designer actually conceives completely new ideas and then has to work out how to create and develop them. In the scenario above, a VPN is not really a new service idea - it's a fairly standard and well-understood product, although obviously pricing, control features and configuration may have some "special sauce" involved.

An operator might also want to reconfigure its SDN-powered network to implement services like cloud-based "virtual set-top boxes", or distributed CDNs, across the different nodes. They may have various clever mechanisms for load-balancing, resource management, geographic dispersal and so forth. But again, those are "engineering-led services", solving operational business problems, rather than human ones.

Moreover, a curator-type telco is primarily looking to sell "on net" services to existing access customers, either on fixed or mobile networks. Often, the original designer or vendor behind a given service will have plenty of other distribution channels elsewhere - a telco is probably not going to sell many VPN instances outside of its access-customer footprint. As such, it may well become possible to integrate curated apps and services with extra in-network capabilities such as QoS, analytics, enhanced security and so on.

Conversely, the designer-type telco services team is probably more distant from the access network. They may have invented a concept for a new type of conferencing, or perhaps collaborated on a new reality-TV interaction model, or worked with government on a telemedicine solution. These type of innovations will likely be delivered outside the operator's footprint, to the web at large, or via mobile apps connected on 3rd-party cellular or WiFi networks. It will be a priority to gain access to as large a potential user-base as possible, and that will implicitly mean that unmanaged, variable-quality network will be encountered. (This fits with the earlier term "Telco-OTT", which I have now abandoned).

Design-led service creation might also be based on a network platform where one end is on-net but parts of the interaction are off-net. For example, I recently challenged the world (via Twitter) to find a way for me to charge people using "withheld numbers" for calling me anonymously. In response, my friends at voice-oriented development consultancy Voxygen quickly created a new "telecom app" for me on their cloud-based virtual platform integrated with carriers' voice systems. This allows easy "mini-app" creation, either purely in-network or with a well-designed mobile app as a front-end. It's not full-blown NFV, but is an example of having "a design idea" (ie coming from the perspective of a real human problem) and then finding the best/fastest way to make it real, via a cloud infrastructure.

What is currently unclear is whether telcos might benefit more from "engineered services" or "designed services" - or indeed various hybrids. Which domain has more revenue potential, for the lowest extra cost/risk? A lot of this comes back to the oft-debated question of "does the network really matter, or is it a commodity?"

I don't think anyone has done a comparative study of these two worldviews yet. Yet it is perhaps the single most pivotal question about the telecom industry filling the "revenue gap" that faces it - and by extension, how much emphasis and investment should be focused on network-centric platforms vs. application-centric ones, and also what the relative value of SDN and NFV are, in terms of revenue-generating opportunity.