At Light Reading’s Big Telecom Event, Cisco SVP of Global Service Provider Delivery Cedrik Neike said that telcos have to transform themselves into platform providers. Well, telcos would agree at least that they have to transform themselves into something other than what they are now—connection and transport providers. Maybe platform providers would be better, but the question is just what a platform provider is and does…and perhaps most important what one would buy in the way of equipment.
If Cisco wanted converts to their view they could have picked a more flattering term. The term “platform” is usually taken to mean “that on which something is built” and that meaning would create a few scowls in operator circles I’m familiar with. It sounds like the operator is being asked to get out of commodity bit-pushing and into some other commodity business. The OTTs have milked your bandwidth long enough so give them something else to milk!
A rose by any other name, though. The truth is that some operator executives yearn for the role of platform provider, because it would get them out of the business of merchandizing new stuff to consumers, which network operators have not proved to be particularly facile at doing. It’s also true that for many operators, regulatory requirements would put them in the platform business whether they wanted it or not; retail OTT-like services would either have to be pure OTT plays or exploit something about the underlying network. In the latter case they’d likely have to be offered at reasonable rates to OTTs too. That begs the question of whether it’s worth being a direct retail player.
It doesn’t answer the question of what a platform provider is or does, though, and it doesn’t suggest just what platform-building would look like either. Cisco seems to see the cloud as the platform, and I would agree that the cloud, meaning cloud computing on a large scale, seems the inevitable destination of operator infrastructure evolution. However, that’s about as insightful as saying that the sun rises. Some specific detail would be helpful.
Operators have three paths they could take toward platformization. First, they could build cloud infrastructure as they’ve built networks in the past and let buyers purchase capacity at utility rates. Second, they could build some other kind of infrastructure that requires significant utility-like levels of investment, like IoT, and make a wholesale service of it. Third, they could build a series of “platform services” by exposing elements of current networks and information gathered from the network.
In all of these cases, it would seem likely the operators would have to devise some special sauce to coat their offering with to boost margins and drive rapid acceptance. The logical thing to do would be to build “PaaS-like” platforms of APIs upward from whatever low-level infrastructure and information the operator exposes. If these would facilitate development of services they could provide an easy path to revenue for startups and gain at least some revenue for the telcos too.
It’s not that the cloud isn’t valuable, or that SDN doesn’t do connections. We have architectures that can probably do what the future calls for. The challenge is making those architectures pay off quickly. Middleware in the traditional sense may be obsolete as a solution, because we need to empower people with less skill and less delay/cost tolerance quicker if we want our platform to be successful. Hence, I think we need to have upperware.
Upperware is what I’m (jokingly) calling a set of problem-directed tools that get a developer or service architect quickly to value. I blogged about two possible upperware examples recently; Alcatel-Lucent’s Rapport and HP’s IoT Platform. These are not general-purpose service platforms, but rather are something that gets you part-way there—close enough to be functional quickly and earn some revenue. If the network operators had platform tools of that type, I think they could attract a following.
One of the challenges of upperware is that it has to be problem-specific. General-purpose tools are like general-purpose programming languages. You can do anything in them, but the price you pay for all that adaptability is difficulty in using the tool, which means it’s more expensive. We’ve had “database programming languages” for ages, designed to do database access simply. We have web development tools, and tools for most other specialized tasks. The thing is that even these kinds of “horizontal” tools may be too specific.
That doesn’t mean that we don’t need lower-level stuff (dare we say “underware?”) that would provide a kind of tool-for-tool-builder repertoire, and an architecture to define the ways that all the layers relate. Think of upperware as building on foundation capabilities, one of which would be to call for dynamic deployment (NFV) and another to call for dynamic NaaS (SDN). We could also define information interfaces to allow various contextual, behavioral, and social/collaborative information to be presented to upperware applications.
The upperware concept exposes one of the issues that NFV and cloud computing both need to face more squarely. It’s clear that utility in either of these technologies depends on the ability to quickly assemble functional atoms into useful services or applications. Well, there’s more to that than just stuffing something into a VM or container, or doing a service chain. You need to think of “class libraries” of “foundation classes” that build upward to create our problem-specific upperware tools.
You can probably see that there are a lot of ways of creating upperware, meaning a lot of different places you could start. For example, you could focus your upperware on information exposure, the presentation of data to services/applications to help refine an experience and make it more contextual and valuable. That might be HP’s approach. You could also focus it on relationships, on the collaborative exchanges between people. That may be what Alcatel-Lucent intends.
It would be nice to be able to present some upperware plans for a variety of players, because it would be nice to think that vendors were projecting their customers’ needs for new revenue into vendor product plans in a realistic way. Beyond my two examples here, though, I can’t see much going on. That is almost certain to create problems down the line, and you can see a likely problem spot when you look at the notion of the “service catalog”.
Most NFV supporters envision an architect grabbing stuff from a service catalog and stringing it into a service. Functionally that’s a good approach, but how exactly do the pieces end up fitting? We could connect a router to a server or a switch in a dozen different ways, most of which would do nothing useful. If we expand our functionality to that of a software component, knowledge of traffic status or the temperature in the basement, you can see how the chances of random pairing producing utility fall to near-zero levels. Call it what you will, we need upperware to create function communities that can then build upward to something interesting.
And here again we have the question “Where does upperware come from, mommy?” This sort of thing is clearly out of scope for the NFV ISG, for ONF, for the TMF, even if we assumed the bodies could make a respectable contribution if they tried to go there. Do we need (perish the thought!) another forum? Or do we just need vendors making their own contributions?
The broader a problem is, the less likely it is that we can sit down a bunch of interested parties and hammer out the details. Groups aren’t doing what they’re currently tasked with doing in a complete and timely way, so they’re unlikely to be the answer to a call for additional structure in our service thinking. I’m hoping both Alcatel-Lucent and HP frame their stories out fully, and I’m hoping other vendors develop their own upperware responses, whatever they decide to call them.