When my kids were young they would have a special day at school that they called "backwards day". Kids would wear pajamas to school, call their teachers by their first names, and other wacky, slapstick fun.

I fear it may be backwards day on the software-defined networking (SDN) playground. Let's look at our priorities as an industry.

Imagine if the application development ecosystem were built with the following resource allocation:

1. Tens of thousands of people working on defining and implementing new instruction sets and assembly languages for super-specialists to program in.
2. Thousands of people working on defining programming languages for software engineers on top of this.
3. Only dozens of people working on business applications software built with the high-level languages (spreadsheets, CRM, MRP, browsers, web servers, etc.)

Clearly, that pyramid would be completely inverted. Of course, today's software application ecosystems is structured exactly opposite. The big investment is focused on the area closest to touching the large numbers of paying consumers.

Now lets look at emergent SDN:

1. Tens of thousands of people working on wire protocols for controllers to talk to switches. (Assembly language — OpenFlow, OpFlex, I2RS, etc. — should have only dozens of super-specialists writing compilers/device-drivers)
2. Thousands of people working on controller-based APIs that will be used by professional software engineers at big network equipment manufacturers (Brocade, Cisco, Ericsson, HP, Juniper, etc.) to build "controller services." I think of this foundation as the "controller SDK" (in the analogy to the app development universe, these would be programming languages).
3. Dozens of people working on generalized abstractions that would make the fancy features of modern networks accessible to cloud tenants and smart, distributed software applications. (In the analogy, these would be the applications — things end users can consume directly without being software engineers or network architects).

Here we have actually built the inverted pyramid. Sure, it's early, and there is necessarily and obviously disproportionate investment in building the foundation from the bottom up. But ignoring the top of this stack is a huge blunder. It's the far north where it's most critical to nail the abstractions. If the wire protocol is adequately abstracted by the northbound interfaces, we can change it at will without annoying consumers at the top of the stack.

If we don't agree on common standards for the wire-protocol between controllers and switches, this will be moderately inconvenient and inefficient for some super-specialized engineers. The world will go on.

If we don't agree on a common "controller SDK" API, it will be similarly inefficient and costly for the NEMs. They will have to port to multiple platforms. Having both Linux and Windows has proven non-fatal for the software industry, as have IOS and Android in the mobile world.

But if we don't allow folks building the next generation of "cloud-first" applications (on massive distributed infrastructure) to easily control the behavior of the network features we need to expose, the gazillion-dollar cloud migration that our favorite pundits have bet the house on may not happen, or at a minimum will be delayed.

The most important work taking place in SDN right now is happening in the ONF Northbound Interfaces (NBI) Working Group and in the Open Daylight Project (ODL) and OpenStack communities, where folks are trying to build an SDN system and interface to orchestration systems that will allow mere mortals to get needed network behaviors and features without becoming Cisco Certified I-something E-something or similar. If we can get the abstractions right and do some clever innovation this will seriously move the needle in terms of taking SDN from the favorite architecture of network nerds to the enabler of mass cloud adoption with "on-premises" quality-of-experience via à-la-carte network services. That's cloud utopia.

OK, now the simple math for the slow kids in the boardroom. Multiple choice:

A) Invest in common system interfaces to reduce development costs on the sell side (bottom-of-abstraction-stack, OpenFlow)

B) Invest in common software standards to reduce development costs on the sell side (middle-of-stack, ODL vs. FloodLight)

C) Invest in common NBIs to enable pent up demand to consume services on the buy side. (Top-of-the-stack, tenant-network-intent NBIs)

I'll give you three tries.

Disclosures: I am directly involved in the work and organizations I discuss above and think it is really important work (you may have deduced this). I can't shut up about this stuff. My opinions are nobody's fault and do not necessarily reflect those of my employer or anybody else. They just come out.