The notion that things are changing, perhaps a bit too fast for comfort, is hardly a modern phenomenon nor one confined to tech. One of my favorite poems (Arthur Guieterman’s On the Vanity of Earthly Greatness) starts with the provocative line “The tusks that clashed in mighty brawls of mastodons…are billiard balls.” Change, and not change for the better (from the mastodon perspective, anyway). Our tech giants should give it a read, perhaps.
IBM was once the unchallenged leader in terms of strategic influence, with a score so high that their vision alone could drive purchase decisions. Today they’ve fallen into a tie for third place among IT vendors and their influence and a couple bucks will get you a Starbucks. Cisco’s score has also fallen, and so has that of Microsoft, who just generated a record loss. In fact, all of the tech leaders are suffering, which makes you wonder just what kind of market we’re going to have in even a few years. It also makes you wonder how we got to this point.
The root cause is likely simple. Business technology has gotten subducted under mass market technology. Selling expensive computers to the Fortune 500 is a decent business but nothing compared to selling smartphones to the masses of the earth. If you look at any technology forum these days, even those supposedly focused on business IT, you find it dominated by consumer stories, consumer comments, and even consumer ads. Absent any means of engaging the market, business IT is bound to languish.
A related issue is the death of productivity-enhancing innovations. We’ve seen regular cycles of IT growth in the past, driven by new compute paradigms. We ended the last cycle in about 2002 and nothing has started up since. From that point, buyers became increasingly focused on sustaining the productivity gains they’d achieved, and the only “benefit” that a seller could offer is lower cost to achieve those goals.
You might look at this trend and see it as the dawn of the Age of IT Populism, where masses of startups rise (waving white boxes, presumably) and shake the councils of the mighty. Well, not so fast. While the major IT vendors are losing strategic influence and often missing revenue targets as well, they’re still sustaining market share, particularly if you take them as a group. We might not consult IBM’s crystal ball before making decisions, but we still sign their sales orders.
It’s this contradiction that sets the tone for networking for the balance of this decade, I think. Buyers are unhappy with their vendors, they espouse open products and open source and standards, and they fear “lock-in” and influence. Yet they still do pretty much the same stuff as before when the PO comes out. Perhaps the reason is an old saw; “Nobody ever lost their job by buying IBM!” You can substitute your big vendor of choice for “IBM” here and the sense is the same. Changing from a traditional supplier, abandoning an industry leader is a risky decision. We’re not being paid to take risks here, says the buyer.
Which gets us back to benefits. Suppose that private airplanes cost a thousand bucks. Would that create an explosion in air travel? No, but it would darn sure drive up the salaries of pilots. What’s happening as cost of equipment and software buckle under competitive pressure is a shifting of cost focus from the cheapening capital elements of tech to skilled tech labor—professional services and integration. We’re making something different into the limiting factor, not eliminating the limits.
In my pilot/plane example, you can see that mass-market airplanes by themselves don’t create a mass market because you can’t train people to fly them safely. What you need to have is a product focus shift, one that takes the functional aspects of IT or network equipment for granted (computers compute, routers push bits) and concentrates on making the stuff bulletproof in terms of installation, operation, and support.
Thirty years ago, network management was said to be 18% of network spending. In 2014 when I asked enterprises for their number, I got almost 38%. Gear got cheaper, more gear is bought, more gear is more operationally complex…you get the picture.
Put this way, the revolutions like SDN and NFV are shooting at the wrong duck and only the cloud has a captured a glimmer of reality. Not with IaaS, which probably consumes more tech humans than the alternative, but with SaaS. If people want an application, sell them the application in the form they’ll use it in, not a heap of technology they can (hopefully) assemble into something that (hopefully) will do what they want.
It’s not that SDN and NFV can’t simplify things, but that we’re not seeing them as what the cloud says they’ll have to be to succeed. This is all about network-as-a-service, not network as technology choices. We’re back to the populist airplane thing; just making something cheaper doesn’t make it more consumable, more populist.
Almost two years ago I had a meeting with a half-dozen EU operators on the goals of NFV, and the point that was raised loud and clear was that if you wanted to do something significant with NFV, you had to address the service lifecycle. And that’s what they say now. One operator says “If you want ‘service agility’ then you want a complete opportunity-to-revenue lifecycle measured in days and not in years.” Well, for all the discussions about agility, we’ve not addressed that complete lifecycle.
Part of the solution is to frame our new technology revolutions in a service management model. The goal of all this iron is to sell services, so you need to understand how the new pieces will address that broad goal. Making a five-hour difference in provisioning a service that’s taken you two years to frame into market terms is hardly noticeable, much less revolutionary.
NaaS is programming more than it’s anything else. Software development principles have to guide service development if we’re going to make a massive difference in agility. We’ve had years of good science built around agile software and now we’re trying to build agile services in activities that have nothing to do with software and have little or no participation from software people. A software architect would never do SDN or NFV as it’s been done.
This is an easy problem to fix, too. The software industry spent nearly two decades evolving to the modern state of modular development and as-a-service or microservice or whatever. We have the results of all of that, and with “software” as the core of nearly every change we believe is coming in networking, it should be easy to conceptualize future services as the facile assembly of useful pre-designed components. SDN and NFV both play a role in componentized services—connecting the components and deploying them, respectively. What we’re missing is how the components are built, the “upperware” platforms needed to facilitate their development, and the management systems that can do drag-and-drop service creation as easily as we can do drag-and-drop development.
This is where vendors could really help. At least three of the big NFV names (Alcatel-Lucent, HP, and Oracle) have software frameworks and skill sets. All three have the tools needed to create an agile framework. Let’s get to it, gang.