Which brings me to the real topic of this post; APIs. Twitter is perhaps the business most frequently associated with the term API. This week, when I think about Twitter, I think about soccer (the World Cup to be precise). And when I think about Twitter and soccer, I think about the fail whale. With the World Cup in full stride, I’ve seen a lot of him the past couple of weeks; you probably have too. The World Cup is wreaking havoc on Twitter’s infrastructure.

But, you know what, it’s OK! The worst thing that will happen is that your urgent tweet about what your dog ate for breakfast will not reach your several hundred loyal follows who are too busy tweeting about their own useless drivel to notice that they have missed this earth-shaking news that Fifi loves coco puffs. (See Tweeting Too Hard for lots of examples.) Twitter has lots of room for downtime, because it is not a mission critical application and there are limited consequences.

The fail whale has become a cute little visitor we cherish seeing every once in a while because it reminds us how frivolous our participation in the twitterverse has become. The risk, however, is that we develop a mental association between downtime and APIs. Lets not confuse the term API with what is behind the API; service delivery infrastructure. They are not one in the same. An API is simply an access point into an infrastructure based service. When it comes to understanding issues of downtime, reliability, etc., the service delivery infrastructure behind the API is what really matters.

Lots of APIs link to mission critical transactional infrastructure. Think payment services (IP Commerce, PayPal X); think about voice services (Ribbit, CloudVox, Twilio); think Internet advertising infrastructure, which is linked together through APIs. Unlike Twitter, the services behind these APIs are truly mission critical. One misstep and few thousand payment transactions don’t get executed, a couple of hundred thousand advertising impressions are lost. Downtime has consequences; they are economic, quantifiable and impactful. The high stakes are what make these services compelling, valuable and difficult to replicate.

In my opinion, the tech community has become way too cavalier about APIs. We can change that by understanding that when it comes to APIs, what is behind the API is what matters. So when you see that fail whale this week and start cursing that “boring, low scoring World Cup soccer thing”, remember that it is the constant vigilance required in soccer that makes soccer the World’s game. There is no downtime allowed in soccer; and we shouldn’t tolerate downtime in APIs that access mission critical services infrastructure. Then remind yourself, that Twitter does not qualify as mission critical and have a good chuckle about the absurdity of your Twitter stream.

UPDATE: Funny timing, but Twitter rate-limited its API several hours after I posted this. Mission critical services don’t get to automatically degrade the quality of service they provide by rate-limiting traffic. Lets not ever confuse Twitter with a mission-critical infrastructure service.

Governance is a critical role for any platform provider. David Evans, who I consider a leading expert on platform strategies, has long said that platforms have three primary roles in their ecosystem, “building, stimulating and governing”. From Chapter 2 of Catalyst Code, a book Evans co-authored:

Catalysts create communities, and communities need governance lest they devolve into anarchy. Catalysts enact rules and impose punishments, and they promulgate standards of behavior.

Evan’s use of the term Catalyst is synonymous to platform. So how do you know if the platform you are working with is going to play fair? As with most governments, it’s all about the rule of law and taxes.

The rule of law

The platform gets to make the rules, codified in the terms of service. Evaluate them carefully and ask these questions:

1. Are the terms of service stable over time or do they change frequently?
2. Do they restrict your freedom to operate or do they enable your fee will?
3. Do they bind you to monetization services offered by the platform, or do they offer you the opportunity to work with monetization schemes provided by third parties?
4. Do they enable the platform to compete with you, or do they make clear that the platform was established to help you become successful?

Taxes and platform monetization

Governments get their revenue from the collection of taxes; and the government gets to set its own tax code. The same goes for platforms, they get to determine how they will monetize their platform. If you are building on a platform, make sure the tax code is well established, stable and predictable. If the tax code is not clear, you are at risk.

Lots of Twitter application developers wrote their applications well before Twitter knew how it would monetize its platform. Said in the context of the government analogy; the Twitter platform emerged before Twitter had a tax code. The increasing tension between Twitter and the application developer community can be traced back to ambiguity in Twitter’s monetization strategy in the early days of the platform’s emergence. As Twitter’s monetization strategy has become more clear, Twitter has been forced to evolve its platform strategy. I’ve argued that we should no longer view Twitter as a platform, but rather as a consumer application. In Twitter’s case, it is clear to me that they have decided that the best way to monetize Twitter is to own and control the consumer experience, enabling them to offer advertising capabilities. Facebook suffers from the same tension as it is both consumer application and platform. If you don’t understand how your platform will monetize itself, your business model may very well be at risk.

To summarize, make sure you understand how your platform partner will govern. The rule of law and the tax code will tell you whether or not the platform is there to help you succeed or if it may compete with you one day.

Its recent decision to lock out third-party ad networks, combined with its clear move in to the edge application space fundamentally alter what Twitter is. It is no longer a platform for application developers to productize around core stream functionality and monetize the edge of the Twitter network. No, if Twitter wanted to be a platform, it would keep its business focused on inspiring innovation on the edge of its network, managing the infrastructure and monetizing the stream.

Truth is, Twitter never was a platform. It has always been a consumer facing application. It is hard (perhaps impossible) to be both a consumer facing application and a platform. A true platform is a true complement with application developers. But a consumer facing application business is a pure competitor with application developers. Because Twitter hasn’t been able to sufficiently monetize the raw stream, it had no choice but to move up stack into the application and monetization layers of its value-chain. I don’t blame Twitter for moving in this direction; it’s totally logical and it was foreseeable.Tacky to quote myself, but in a prior blog post I said:

If you are an application developer on a consumer-facing platform, be sure the platform you build upon has a clear business model for helping you monetize the relationship you develop with the consumer. If not, be wary; what you do may eventually be consumed back into the platform. You may be left with no strategy for monetizing the user base you help to create.

So what is Twitter? Well, lets call it what it is – a consumer application – and a big, but narrow one at that. In the end, that is all it ever was.

I don’t have a dog in this hunt; I have not invested in any Twitter application developers for fear of the very outcome that has transpired – Twitter vertically integrating into apps and monetization with scale. I’m just a student of the platform strategy game. The lesson learned here should be noted by application developers on any consumer-facing “platform”. Be wary unless your platform is a pure complement.

“What about mobile payments?”

My friends at PYMNTS.com asked me to join in the discussion in their Briefing Room on Mobile Payments. My answers are here. As you will see, the format of the briefing room is five questions, with the emphasis on the intersection between payments and mobile application development platforms. I tried to answer the questions as directly as possible, but in the process, a couple of things went unsaid.

So, to add to the Briefing Room post, I should say I’m a big believer in mobile payment. The phone will be your “wallet” some day, although I can’t tell when. My sense is that adoption for online and mobile web/application payment will precede mobile payment at the traditional point of sale. I’m most interested in mobile payment in economies where electronic payment is an emerging alternative like developing economies and in last cash markets where the connectivity enabled by the mobile phone provides an entry point for electronic payment services to displace cash.

Regardless of the sector, I’d argue that mobile payment has to add value to the payment process to fully take hold. It is not sufficient to simply replace an existing electronic payment transaction with a mobile originated payment. That will cost more to the merchant, because it adds layers to the value chain and fundamentally adds no value.

Show me an opportunity to invest in a payment business leveraging mobile with a clear value proposition in a market segment that is accessible in the near term and you are likely to find a very engaged and interested prospective investor.

The bulk of the discussion is over who will dominate in mobile apps. To which platform will developers flock? Who will have the most apps? Who will be most expert at app monetization? To me, this entire discussion is missing the point; because it ignores the most important application on your mobile phone.

The most important application on your phone is the browser!

Hasn’t the web taught us anything? The web obviates the need for many (and eventually most) applications by enabling them to be delivered from “the cloud” through the browser. When we look back in five years, I think we will see clearly that the app. phenomenon was a temporary bridge to a rich, and highly functional mobile experience dominated by the browser. 

You can replicate just about everything mobile apps can do in a browser. In some cases you can do more in the browser. And as Java, Flash and other browser display technologies continue to roll-out, the browser will only become more powerful. And as 4G networks begin to roll out the browser will have the advantage of a fatter pipe. Fatter pipes shift the economics of app development away from edge processing and toward the cloud. The mobile web also has huge advantages for application developers; no carrier approvals, no app store approvals; totally open.

Apple’s issue is not whether Google will surpass them in the mobile app battle, but rather the speed with which usage will shift from apps to the browser where Google has substantial advantages in delivery infrastructure and monetization (search and display).

Just my two cents. What do you think?

Everything is a service

For several years I’ve been spouting off about the notion that “everything is turning into a service”. I outlined some detailed thoughts on this trend in a post titled “The future is in services” last June. As I look several years out, I see several big value chains threatened by this trend, creating opportunities for upstarts. For example, I think there will continue to be pockets of attractive investments in SaaS. But where I see big opportunity is in cloud based services and platforms that enable the cloud to become a true utility to the enterprise, small business and even consumers. Transforming computing from a product into a service is a non-trivial shift that will take many years, but the march is on and the direction of the trend is undeniable. Computing, storage, etc. will all primarily be purchased as a service in the not too distant future.

Platforms

For me, 2010 will be the year of the platform. The notion of open platforms that enable third-party developers to innovate on top of the platform by consuming API is alluring to me. I’ve already put my money where my mouth is on this one as several of my investments have ”platform” as a core component of their product and go-to-market strategy. Communications is an areas that has largely been untouched by the platform trend. It seems to me that the time is ripe for the network to begin opening up. I’ve written about this in the past on my firm’s blog; you can find that post here. The post is a bit dated, but I think you will get the point. Location services is another area where I think there are platform plays emerging.

Payments

I have an inkling that innovation is finally coming to payments. There have been some big exits in recent months, including BillMeLater and Revolution Money. Neither is particularly reflective of the type of innovation I think is coming in payment, but both show the size/scale of businesses that can be built given the massive size of the payments sector. With PayPal opening up its platform to third-party developers, there is going to be a rash of new payment application development in the coming years. As an investor in IP Commerce, I have a special perch from which to watch this trend. I’m staggered by the diversity of payment applications being developed on top of the IP Commerce platform. Several have already caught my eye as potential new investments and I believe more will do the same in 2010. I’m also tracking some big last cash markets, which I think are finally opening up to electronic payment providers.

Mobile

Mobile is an area I have tracked closely for several years now. And while some would argue that the market has disappointed, I would counter that we are still in only the early innings of a very long game. I continue to believe firmly in the mobile web, or the web optimized for the display needs and the unique capabilities/properties of mobile phones. I’m less enthusiastic about applications being developed for the iPhone/Android/RIM and other operating systems; or at least less enthusiastic about investing in companies that create those apps. There is just too much OS fragmentation for application developers to manage effectively and it is difficult to make any particular app stand out in the crowd.. As 4G networks begin to roll out, more bandwidth may obviate the need for a downloadable app. In some ways, apps remind me of PointCast; remember that? I’ll continue to track this trend closely, but as it stands, my money is on the web, not the apps in the long-run. Regardless, I’m more interested in the infrastructure and plumbing in mobile than the consumer-facing application side. The fact is that the mobile use case is fundamentally different from the web and it enables usage paradigms that are not relevant on the tethered web. As a result, the capabilities of the plumbing for mobile need to cater to what is unique about the mobile experience, creating an opportunity for new players to stake out a dominant and differentiated position.

I’m likely to make two new investments in 2010. I am more likely to prioritize my review of investments that synch with the themes outlined in this post. I’m also more likely to make investments in these areas than other areas I’m not tracking as closely. Having said that, I think it is critical to marry a thematic (and therefore planful) approach to identifying great investments with an opportunistic approach. So I don’t rule out making investments in other areas in 2010. I know there will be several entrepreneurs with whom I interact who light a spark causing me to dig deep into areas not outlined in this post. Frankly, I look forward to having that spark lit; it is a great part of the process of discovery that the VC business requires.

This trend is not the exclusive domain of established players. It seems two out of three new investment pitches I hear have a “platform” element to them. This caused me to send the following tweet last week:

Your desire to be a platform does not make you one. Only the ecosystem around you can make you a platform.

Clearly, this topic deserves many more than 140 characters; hence this blog post. So what is a platform? Most people, particularly technologists, default to a technology definition of platform. In layman’s terms, a technology platform is infrastructure (hardware and/or software) upon which other technologies and applications can be built. This is intuitive and easy to understand. An operating system is a technology platform. And in the web-world, all of the services above fit the “technology platform” definition, because they all allow application developers to develop applications on top of something.

 The much more interesting definition from my perspective is a business definition. I favor the definition forwarded by David Evans and his co-author Richard Schmalensee in the Catalyst Code, in which they define an “Economic Catalyst” (a synonym for platform in my world) as:

An entity that has (a) two or more groups of customers; (b) who need each other in some way; but (c) who can’t capture the value from their mutual attraction on their own; and (d) rely on the catalyst to facilitate value-creating reactions between them.

I won’t steal thunder from the book - if you are interested in this trend at all, you should read it and its prequel “Invisible Engines” - but what the business definition drives home is that there is much more to being a platform than building a technology and hoping an application developer builds something on top of it. You can’t just be a technology platform; you have to make an ecosystem around the technology. In addition, the platform must serve both each of your customer groups well and must be a means to an end; that end being “a value-creating interaction” between those two customer groups.

Most of the platform examples I cited above talk about only one customer group, the application developer. That is natural in some ways as the release of these platform technologies is marketed to application developers. But this is only half of the story. We talk way too infrequently about why are these application developers build something on Facebook, Twitter, the iPhone, etc. This is important, because it is notoriously difficult to charge application developers to build on top of a platform. As I’m writing this, I can’t think of any good examples of big businesses built by charging application developers for access to a technology platform; perhaps with a little more thought I could gin a few up. Microsoft doesn’t charge application developers to develop on top of its OS. Microsoft makes its money charging software licenses to businesses and consumers who choose a Microsoft OS because of the large community of applications that are available on it. Facebook, PayPal, etc.; they don’t charge the application developer; at least not in a scalable way. You can’t just aggregate a bunch of application developers and make money.

We need to redefine success for platforms. A successful platform isn’t the platform with most application developers. The money is made by creating a value creating exchange with the customer on the other side. Therefore, a successful platform is one that facilitaties the most value-creating interractions for the two or more customer groups it serves. On that measure, all of the platforms I’ve mentioned (besides Microsoft’s OS business) are nascent. No-one has figured out a truly scalable way to create value exchanging interactions on these platforms; at least not in a way that serves the application developers well. A piece in GigaOm about the long-tail of iPhone application developers is illuminating. Om calls it “extra-long”, which means there are a very small number of applications making all the money and the rest are left fighting over scraps. Most of the examples I’ve cited have a consumer on the other side of the platform. The easiest business model for monetizing application to consumer interactions is advertising, whether on the web or “in-app”. Twitter is heading in that direction now, although they are rapidly bringing back functionality that has historically been the domain of the application developer community as they roll out their monetization strategy. You can be sure that those two trends are linked. We’ll see how the advertising model serves application developers on all of these platforms; my guess is not very well.

When a consumer is on one side of the platform, it is easier to become a platform when you have an installed base of users. Facebook had a massive user base before it opened up its platform. The same goes for Twitter, the iPhone, etc. It is much harder; some might say impossible; to start a consumer facing platform. Consumer facing platform strategies emerge from large installed bases of consumers; it may not be possible to start one explicitely, although Google is trying with Wave.

If you are an application developer on a consumer-facing platform, be sure the platform you build upon has a clear business model for helping you monetize the relationship you develop with the consumer. If not, be wary; what you do may eventually be consumed back into the platform. You may be left with no strategy for monetizing the user base you help to create.

For startups with no installed base on either side of their nascent platform, getting an ecosystem started is a bit trickier. For most, the only way to be successful is if the attraction between the two customer groups is soooo strong that the ecosystem ”makes itself” around your technology platform. Some refer to this as the chicken and egg challenge of platforms. It is not mission impossible to crack the chicken and egg, but it is a challenge. This may be easier in B2B platforms than in B2C or C2C platforms. Perhaps more to come on that in future posts.

For now, on to another type of fowl; TURKEY!