As Danny highlights in the latest instalment of This Week’s Semantic Web, Marc Andreessen has once more demonstrated that he’s not content with co-authoring Mosaic, sneaking around in the 24 Hour Laundry and driving social networking Ning-style. Far from it, as he continues his recent practice of blogging thoughtfully on issues facing the industry of which we – and he – are part. Yesterday’s post, The three kinds of platforms you meet on the Internet, touched on a number of issues that we’ve addressed here on Nodalities before, and it is well worth both reading and thinking about.
As Marc suggests in his introduction;
“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.
However, the concept of ‘platform’ is also the focus of a swirling vortex of confusion — lots of platform-related concepts, many of them highly technical, bleeding together; lots of people harboring various incompatible mental images of what’s about to happen in our industry as a consequence of various platforms. I think this confusion is due in part to the term ‘platform’ being overloaded and being used to mean many different things, and in part because there truly are a lot of moving parts at play that intersect in fascinating but complex ways.”
How true. The Platform space is a great one to be in and it’s brimming over with opportunity and potential; so much so that we’re one company staking an awful lot upon the detail of our Platform vision.
Traditionally sloppy use of language, however, has led to a situation in which unnecessary confusion is now associated with a superficially straightforward term. Some of this confusion is introduced by innocent drift in the evolving usage of a word, but far more is down to the unfortunate fashion for everyone jumping on the bandwaggon and unleashing a ‘platform’ of their own. At least we’ve been using the Platform label for our own endeavours in this area for a number of years.
In his attempt to introduce some clarity, Marc’s post reiterates his basic definition of an internet platform;
“A ‘platform’ is a system that can be programmed and therefore customized by outside developers — users — and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate.
We have a long and proud history of this concept and this definition in the computer industry stretching all the way back to the 1950′s and the original mainframe operating systems, continuing through the personal computer age and now into the Internet era. In the computer industry, this concept of platform is completely settled and widely embraced, and still holds going forward.
The key term in the definition of platform is ‘programmed’. If you can program it, then it’s a platform. If you can’t, then it’s not.”
Check.
He then offers three ‘kinds’ or ‘levels’ of Internet platform, being careful to stress that one is not necessarily better than those it supersedes;
“I call these Internet platform models ‘levels‘, because as you go from Level 1 to Level 2 to Level 3, as I will explain, each kind of platform is harder to build, but much better for the developer. Further, as I will also explain, each level typically supersets the levels below.
As I describe these three levels of Internet platform, I will walk through the pros and cons of each level as I see them. But let me say up front — they’re all good. In no way to I intend to cast aspersions on what anyone I discuss is doing. Having a platform is always better than not having a platform, period. Platforms are good, period.”
Marc’s three levels are;
Access API
“Architecturally, the key thing to understand about this kind of platform is that the developer’s application code lives outside the platform — the code executes somewhere else, on a server elsewhere on the Internet that is provided by the developer. The application calls the web services API over the Internet to access data and services provided by the platform — by the core system — and then the application does its thing, on its own.”
Plug-in API
Superficially very similar to the ‘Access API’, but the host application (such as Facebook) into which a developer’s application connects does the vast majority of the work around marketing;
“Facebook provides a whole series of mechanisms by which Facebook users are exposed to third-party apps automatically, just by using Facebook.”
Runtime Environment
“In a Level 3 platform [such as Salesforce], the huge difference is that the third-party application code actually runs inside the platform — developer code is uploaded and runs online, inside the core system. For this reason, in casual conversation I refer to Level 3 platforms as ‘online platforms‘.”
“Put in plain English? A Level 3 platform’s developers upload their code into the platform itself, which is where that code runs. As a developer on a Level 3 platform, you don’t need your own servers, your own storage, your own database, your own bandwidth, nothing… in fact, often, all you will really need is a browser. The platform itself handles everything required to run your application on your behalf.”
And there’s more, and it’s interesting stuff that Marc has clearly thought about long and hard.
Reading – and rereading – Marc’s post, though, I kept coming back to ideas touched upon in two posts of mine about the relative openness of different Platform solutions;
“Facebook and Talis might very well be offering ‘Platforms’, but they’re quite different in intention. Facebook’s platform seems to be all about making the Facebook site as rich, compelling and sticky as possible; everything is sucked to one point. The Talis Platform, on the other hand, is about providing developers – wherever they are – with the tools and capabilities to easily link and manipulate data across and through the web. The former sits heavily ‘on’ the web, and feeds upon it to suck ever more into its maw. The latter is truly ‘of’ the web, giving a distributed community of developers and users powerful new capabilities to enmesh their applications, and to deliver capabilities at the point of need.”
Regardless of its position in Marc’s levels, I truly hope and believe that the Internet platforms of long-term viability will be those that embrace the Network rather than feeding rapaciously upon it; those that are of the web as we are trying so hard to be.
A Platform should give the developer a helping hand. It should lift them up and provide them with a set of tools that make it easier to concentrate upon and deliver their core value whilst the Platform worries about the day-to-day mundanity that is mere context [to paraphrase Geoffrey Moore]. A Platform should enable the developer to realise the benefit of those tools and capabilities in places and manners of their own choosing, rather than expecting or requiring the developer merely to expose their assets within the bounds of whatever site(s) the Platform chooses to offer. Platform providers who realise and embrace that will be the ones to succeed.
Technorati Tags: Danny Ayers, Marc Andreessen, Platforms, Talis, Talis Platform
