But is perhaps missing the biggest nail of all.
I’ve been enjoying Marc Andreessen’s blogging since he started. Always well written, often insightful, and tapping a wealth of Internet and entrepreneurial experience, his posts are at the top of my reading list.
One of his latest maps out the power of platforms, especially as they apply to the Internet.
A few quotes:
Let’s start with a basic definition. From a previous post:
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.
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.
Nice and clear. Marc then goes on to talk about three different levels of platforms [edits for brevity]:
Level 1 is what I call an “Access API”.
This is the kind of Internet platform that is most common today. This is typically a platform provided in the form of a web services API — which will typically be accessed using an access protocol such as REST or SOAP.
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. That’s why I call this an “Access API” — the key point is that the API is accessed from outside the core system.
Level 2 is what I call a “Plug-In API”.
This is the kind of platform approach that historically has been used in end-user applications to let developers build new functions that can be injected, or “plug in”, to the core system and its user interface.
Level 3 is what I call a “Runtime Environment”.
In a Level 3 platform, 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”. Let me explain.
- A Level 1 platform’s apps run elsewhere, and call into the platform via a web services API to draw on data and services — this is how Flickr does it.
- A Level 2 platform’s apps run elsewhere, but inject functionality into the platform via a plug-in API — this is how Facebook does it. Most likely, a Level 2 platform’s apps also call into the platform via a web services API to draw on data and services.
- A Level 3 platform’s apps run inside the platform itself — the platform provides the “runtime environment” within which the app’s code runs.
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.
This is a nice breakdown. Marc has lots of great examples to clarify what he’s talking about, and it is cool to see that what we are trying to do at SwitchBook is a create a Level 3 platform for search built around the idea of a Search Document as the means of managing user input and tracking partial results for complex searches.
Yet, I also think Marc is missing out on the most powerful platform of all: platforms that are completed distributed and designed to run on other peoples platforms. This “Level 4” Platform is something Marc is intimately familiar with. After all, the Mosaic browser he wrote and browser vendor Netscape were at the core of taking the World Wide Web to mainstream success. Clearly, the web is programmable by users. It is a platform. But what makes it so absolutely amazing is that as a platform, it handles none of your application for you, but defines services and protocols so that any number of vendors can provide a specific hosting solution that is 100% interoperable with the rest of the platform. Level 4 platforms spawn other platforms and assimilate existing applications. They are incredibly powerful and even harder to build than the others Marc spoke about.
Vendor Relationship Managment (VRM) is working to create a Level 4 platform that turns CRM upside down, providing tools for individuals to manage their relationships with vendors. As such, we aren’t attempting to build one particular application, we are building a framework for which any number of service providers could offer applications and hosting platforms. It’s not a small challenge, but we think its the right way to do it.
I’m curious how Marc would look at the idea of Level 4 platforms.