The magical ampersand: Hope is not an integration plan

In a software-defined and virtualised world, who will integrate the complex dynamic systems, and take responsibility for the result? It is unclear if telcos have the skills, but someone else likely does…

The above image caught my eye whilst I was reviewing presentations from last October’s Metro Ethernet Forum gathering in Florida on behalf of a consulting client. At first glance, it’s just a marketing pseudo-Venn diagram peppered with telco tech buzzword bingo. But…

…there’s a tiny detail that would be very easy to overlook. In the middle is an ampersand (&) symbol. It’s part of a brand design, not a typographical or technical statement about the nature of the world. It suggests that a certain big telco is going to be the integrator of three different technologies:

  • Software-defined networks, i.e. putting core and edge transmission resources in the network under dynamic control of algorithms, an inside-outwards service strategy.
  • Software-defined WANs, which (being misleadingly named) are the exact opposite of software-defined networks, being outside-inwards dynamic control by the customer over transmission resources.
  • Virtualised (network) services, which dynamically share the network’s internal physical compute resources, and makes the service (semi)independent of its location.

You don’t have to be a strategic genius to realise that this doesn’t look much like the traditional telecoms skills set of “holes and poles”, buying switches, provisioning circuits, and lobbying regulators for special favours. There’s a whole bunch of dynamism of diverse resources, and at an unfamiliar tempo compared to telecoms history.

[On that theme, one of the most intriguing books I have encountered is Tempo by Venkatesh Rao. The bottom line, for me, is that the nature of any (technical) system is essentially defined by its tempo, and you can only “interface” things whose tempos are aligned.]

There is an established industry that’s more than used to performing dynamic resource management functions of the kind listed above at a very high tempo. This discipline is operating systems, which have to manage inter-process communications resources, allocate memory, schedule competing processes, and assign computations to specific processors or cores. The same OS giants — Google, Microsoft and Oracle (partly via its Sun acquisition) — seem to be doing conspicuously well in cloud, too.

I’ve academically studied operating systems, process algebras, and formal methods of system design. These skills are hardly oozing out of every telco research lab: just ask how many network engineers use the term “invariant” or “semantics” in their work. It’s been an uphill struggle to get telcos to adopt even relatively basic computer science and software engineering to solve today’s far simpler performance integration problems.

So this seemingly innocent chart suggests that telcos and their network equipment vendors are going to master an unfamiliar set of skills, using novel tools, to work on very hard problems, at challenging new timescales. Indeed, it could be seen as their birth right to solve the integration problem, just because the word “network” appears in each functional bubble.

Furthermore, and likely far harder, they are going to create organisational structures that reward the systemic “ampersand” integration requirement, and not to optimise the departmental “circles” independently. For the rare distributed computing performance integration people to get a pay and headcount rise, the radio and transmission folks need to yield some budget, and that won’t be popular.

There’s a well-worn technology adage: “To err is human, but to truly mess up, you need a computer”. Call me an old cynic, but to me that ampersand is presently a triumph of network design hope over software capability reality. The industry hasn’t even got a standard means of specifying performance, so even characterising the intended outcome is problematic, to say the least.

What is a “software-defined” system going to deliver as all these multiple forms of dynamism interact? What’s going to happen as different implementations from different vendors interoperate? How will the user experience change as telcos have to manage new cross-operator dynamism challenges? Who knows! It’s magically answered in the “&”.

It all makes you wonder if they should leave the integration ampersand to the operating systems experts instead. At the end of the day, dynamic resource management is exactly what they OSes do. They have far more experience at security and performance isolation than telcos. They have hardened their scaling processes and distributed systems technology and data centres.

And most of all, the software engineering experts understand how to avoid a misplaced &ampersand causing a nasty !bang and splat*.

 

For the latest fresh thinking on telecommunications, please sign up for the free Geddes newsletter.