The great Web 2.0 application (s)mash-up

In the Web 2.0 economy, platforms that set the rules for service publishing and aggregation will wield the power and the wealth.

There are two opposing views of the direction enterprise applications are moving in. One view says that enterprises want "one throat to choke, one stack to manage," and thus the trend is for ever greater consolidation on a dwindling number of giant vendors. The opposite view was presented at a conference last week by Mohan Sawhney, professor at Northwestern's Kellogg School of Management, as quoted in Joe McKendrick's blog: "Five years from now, the concept of an application will be obsolete," Sawhney said. "They will all be services, combined, mixed, matched and reused as needed."

I tend to agree with the professor (except for his timescale, which is hopelessly over-ambitious). The command-economy development programs of individual software vendors, however extensive and well-funded they may be, cannot possibly prevail against the sheer innovative diversity and economic efficiency of the Web 2.0 ecosystem. But even Web 2.0 has to be able to offer its own version of "one throat to choke, one stack to manage" before it can win through. There have to be platforms and marketplaces that impose rules and standards of behavior against which customers can hold participants in the ecosystem to account.

Imagine the power those ecosystem platforms will hold. These are the vendors whose influence will dominate the Web 2.0 landscape. That's why, before the great Web 2.0 application mash-up can begin, there will be an almighty smash-up between the competing contenders. Several are already in the fray, but with markedly different approaches, while others have yet to make their moves. Here's an overview of the current state of play: 

  • launched its AppExchange 'marketplace' last week. As I explained yesterday, it's emphasizing a consistent user experience and ease of getting started. Those elements remove a lot of the potential pain for customers, but service contracts are still with individual providers, leaving the customer dealing with a plethora of throats.
  • The StrikeIron Web Services Marketplace also launched last week, in its v2.0 iteration. It's a mirror-image of, in that it assumes service contract responsibilities and thus presents a single throat, but the only platform consistency it provides is in its adherence to web services standards (unless you count its Excel add-in, which allows users to link SOAP web services directly into Excel spreadsheets). Compared to AppExchange, this is definitely a DIY approach.
  • The Rearden Commerce Platform hasn't yet opened up to third-party developers, but will do early next year, as my colleague Keith Rodgers reports in a Loosely Coupled article this week. According to BusinessWeek, Rearden is announcing a new $25 million funding round today, bringing the total it's raised so far to an impressive $67 million. Rearden is focused on delivering packaged composite business services, which means it expects more sophistication from its ecosystem partners than the others. But it scores well on the single throat dimension.
  • Then there's Amazon Web Services, which among its various offerings last year launched betas of Alexa Web Information Service and Amazon Simple Queue Service, accompanied by the promise that it would announce pricing for each of them once they officially launched. It also filed a patent for a web services marketplace. But there is still no outward sign that Amazon has so far managed to design or build any of the infrastructure it would need to put these commercial ideas into practice. 
  • Google, of course, has also been in the developer ecosystem game for a while, and according to one author, "it has created a supercomputer ready to deliver a host of applications to anyone with a Web browser." Well, we'll see how that might work when Google actually delivers it. Rather than dwell on that here, I'll write more in a separate post on Google later on.
  • You'd think Ebay would be in this game, too, but its style is more to establish a framework for establishing trust and reputation and let its community of buyers and sellers figure out for themselves how the ecosystem will work. That may be leaving too much to chance to allow a software-based services marketplace to evolve. 
  • The also-rans currently include Yahoo! and Microsoft, who are both late arrivals in the services ecosystem game with recently published developer APIs, but can't be written off yet. Then there are the established software giants themselves. SAP and Oracle are probably too dependent on licence and maintenance revenues to enable an effective services marketplace (Microsoft may also fall into this category). But IBM still has room to manoeuvre and has built up a lot of software-as-services expertise over the years. It has the opportunity, if it wishes, to act as a platform-neutral marketplace operator — but as yet shows no signs of any interest in the idea.
  • Finally, there are the left-field players, many of them as yet unknown or not considered as potential platforms. As Richard MacManus recently wrote, "Publisher Services has a lot of potential and it may well be the category which delivers the next Google." He was writing specifically about RSS, but the notion applies equally well to all on-demand services, not merely RSS. In the Web 2.0 economy, service publishing and aggregation of all forms is where the greatest opportunity lies.

So what's the prognosis? At present, the dream of composing an enterprise application stack from mix-and-match services is really only possible within a tightly controlled architecture built entirely by a single organisation, which kind of defeats one of the principal objects of building it that way in the first place. As Jeff Schneider, another service-oriented blogger, noted last week, "Services will be built, bought, leased and borrowed. Recombining services, from anywhere, for value-add solutions is at the heart of a Service Oriented Enterprise." Marketplaces will come into being to fulfil that demand.

But this brief survey of the first generation of ecosystem platforms shows how much ground still needs to be covered. The basic coupling mechanisms are there in the form of web services APIs, but the only way to achieve aggregated business services and applications delivered on demand is to turn to highly integrated stacks like those from and Rearden. That looks to me like much more of a 'walled garden' model than most Web 2.0 supporters would really want to see.