Another Kind of Platform: Telcos as Development Environments
Another common use of the word "platform" that sometimes confuses people is the way it's used to describe the technology that goes around individual applications in a computer system. Like Microsoft Windows, Linux, Adobe Flash in the browser, Symbian S60 in a mobile phone, or what have you. IT people spend a lot of time arguing about them, which is probably less stupid than it sounds, because the history of IT has been the history of development platforms.
This is down to the very nature of computing. Alan Turing's great insight was that a very simple processing function could be generalised to simulate essentially any conceivable task, and hence to do any job that consists of processing information. John von Neumann operationalised this with the notion of a computer as a collection of inputs and outputs feeding a storage device and a processor. This is, at bottom, why we want any of this stuff; computers (in the broadest sense) are general-purpose tools, rather like the famous quick-reconfigurable machine tools that made Toyota what it is.
So, this leads us to two conclusions; the first is that without applications, the computer is worthless. The second is, obviously enough, that the worth resides in the applications. And that implies that the guys with the best apps win. This pattern has repeated itself with every generation of computers; LEO Computers Ltd. in the 1950s, IBM System-360 in the 60s, UNIX in the 70s, Digital and Apple in the 80s, Microsoft in the 90s, and Google, Salesforce and your favourite open-source project right now. At each step, the people who attracted the most developers to work on their platform came out on top. (The geekosystem has always worked on the principle that brains move towards noise, so the best developers end up there as well.)
These are platform businesses just as much as container ports, stock exchanges, online gambling sites, Internet peering points, or dating sites are, and the same economics applies. Two factors attract developers; interesting projects, and customers. Customers, for their part, are attracted by the availability of new applications, which is governed by the size of the developer community. It's not hard to see an increasing returns to scale process here - more interesting collaborators means still more developers, which means more projects, which means more customers, and so on and so forth.
So when Apple decided, back in the 1980s, to bill all its developers $10,000 to take part - well, the rest is history. Even if it didn't scare off that many to begin with, it shifted enough of them towards Microsoft that the system rapidly flipped. This is another feature of platform businesses we're familiar with from our past research; increasing returns to scale mean that competition tends to be non-linear. Apple never got back in the enterprise market and struggled for years to recover; the port of London moved to Felixstowe and the ships never came back.
When we think about the future of telcos, we think about not trying to divine what services the public wants but instead providing the enabling APIs for people who think they know to experiment with. We think about providing services that all kinds of businesses can use as part of their internal processes. Thomas Howe made the point at the Telco 2.0 event last week that these communications-enabled business processes aren't even specifically "voice"; voice is a condiment, not the meat. The meat is the very specific information the people involved want to exchange; Howe makes his money creating small tailored applications to match very specific needs, and you can't write an average of less than 100 lines of code per application without the support of an advanced developer environment.
Basically, Telco 2.0 is going to look much more like a development environment than a telco as we currently know it; James Aitken of telecom Web services specialist Aepona described it as the "programmable telco" at last week's Telco 2.0 event. Interestingly, Aepona's product will already permit a third-party developer to pass a complex query for processing on the telco side, rather than simply requesting a URL for (say) the location of telephone number X, a development which brings us closer to the software-agent model we've advocated before.
This can tell us a few things about where we should be going; we need to provide open standards for the APIs, we need to provide ways for the platform and the developers to share in the revenue, we need to nurture developer communities, and we need to build scale through partnerships among telcos. All of these are methods of creating an effective platform that have been proven over time to work.
However, there are many subtleties in turning these theoretical principles into commercial practicalities. That's the focus of the next phase of our research...