Evolving Internet 'Platforms' - Lessons for Telcos?
"One of the hottest of hot topics these days is the topic of Internet platforms, or platforms on the Internet. Web services APIs (application programming interfaces), web services protocols like REST and SOAP, the new Facebook platform, Amazon's web services efforts including EC2 and S3, lots of new startups talking platform (including my own company, Ning)... well, "platform" is turning into a central theme of our industry and one that a lot of people want to think about and talk about.
Indeed. Andreessen is certainly right to say that there is a lot of confusion about it, too - we mentioned this in our post on jNetX. In an attempt to clarify this, he defines a platform as any system capable of modification by the user; we broadly agree with this. What we find more interesting is his three-way typology of platforms, and the importance he attaches to them.
For Andreessen, there are three types of platform; the most basic consists of an API exposed to third-party developers, which they can use in their own work but cannot use to alter the core functionality of the system. More sophisticated "Level 2" platforms make it possible not just to use elements of the system outside it, but to use them to create a different version of the system. Finally, "Level 3" platforms act as run-time environments, permitting third parties to write code that is executed within the system itself.
Andreessen is keen to assign value judgments to each level; he argues that movement from level 1 up to level 3 represents progress, as it tends to reduce the barriers to entry for third-party developers. Rather than re-creating certain functions, you can use a Level 1 API; rather than building a complete new application, you can add new functions to an existing one with Level 2 capability; rather than providing your own infrastructure and technical support, you can rely on a Level 3 platform's machines and institutional backing.
It's an interesting idea, but there is a serious problem relating this to telecoms; very briefly, operators are very unlikely to let anyone introduce their own code into their core systems. It's just too critical for that. Nobody, after all, suggests that ISPs should let their users inject code into their core routers; the same point applies with redoubled force to softswitches. So there is a natural limit on telco development in this direction.
But this doesn't mean a lot cannot be achieved. Level 2, in many ways, is a nice place to be; you get a significant amount of the resources you require from the users' devices, and you have a high degree of control over how you implement your application that you might not have if it was running in someone else's system. Andreessen argues that Level 2 applications have scaling problems - they are often "killed by success" because it's up to the developer to provide the infrastructure and the organisational backup.
The Telco 2.0 approach would be to address this directly; telcos are in a good position to do just this. If you can't let other people's code into the core network, that doesn't mean you can't provide hosting on a really impressive scale; just ask BT Global Services. And whether you're Level 2 or 3, support is a huge issue - the whole platform strategy implies that other people's businesses depend on you, so you're going to need fanatical support beyond anything so far considered.
Further, it's possible to question whether the distinction between 2 and 3 is all that important. Andreessen cites Akamai's Edge Computing service - which essentially acts as a CDN for applications, permitting the customer to run their app on a network of servers in ISP PoPs - as a possible level 3 platform. But surely the point is that, rather than modifying the service, your code is hosted by the service?
Couldn't a telco that decided to stay at Level 2, in the light of what we said above, offer Level 3-like functionality by hosting the applications that use the Level 2 "plug-in API" itself? Or, for that matter, with Akamai under a wholesaling deal? As so often, the question is which questions to solve using technology, as opposed to organisational or commercial change.
Jeremy "ipdev" Penston takes a sceptical view of all this; he argues that the window of opportunity for telcos-as-platforms may already be shut. We disagree - it's critial to future growth (as our survey is showing) - but Akamai's service is a pointer to how this strategy might fail. Steadily, more and more of the elements of such a platform are becoming available from other people's platforms; there is not much time to lose.
We will launch our draft description of a viable 'telco platform business model' in a forthcoming post, and at the Telco 2.0 Plenary on 17th October.