Web 3.0: The API-driven application

Although some people enjoy futzing about with raw API services from the likes of Google, Amazon et al, most people just want software to help them get their work done faster. That will create an opportunity for vendors to build a new generation of applications that convert bare API services into useful functionality, as I hinted in my introductory post last week on What to expect from Web 3.0.

I hear that SAP executives,What does a Web 3.0/ enterprise 3.0 application look like? meeting with analysts this week in Las Vegas, have started using the term "enterprise 3.0" to describe this next wave of business applicatons. I'll stick with Web 3.0 because it's a shorter fit for my headlines, but I've no doubt we're talking about exactly the same core concept: a new generation of services-based, composite applications that are tailored to fit the work processes that people actually need in their daily routines.

So what does a Web 3.0/enterprise 3.0 application look like? No need to wait for SAP to start delivering on its roadmap, because there are some good prototypes out there already. As I mentioned in my post about WebSideStory the other day, I think the way its web analytics-driven application suite uses APIs is a great illustration of these principles in action. Let me elaborate.

WebSideStory Bid, introduced in August this year, is a perfect example of an API-driven composite application. Targeted at organizations that spend large amounts of money on pay-per-click keyword advertising -- in the $10k to $50k per month range -- it provides a single console for monitoring the performance of keyword ads and managing bid amounts and placements. It is capable of doing this across multiple properties, including Google, LookSmart, FindWhat and Kanoodle, and it uses AJAX technology to deliver the results in real-time. The data from those properties, of course, is coming in via their API feeds, and similarly the adjustments to bids and bookings goes back via the same route.

Here we have, then, an application that is built to work with a specific set of API feeds. It has no functional use without them. Its value comes from the productive functionality it adds on top of them, enabling the user to co-ordinate keyword-targeted advertising in real-time far more effectively than they ever could using the API providers’ own rather rudimentary application interfaces. Indeed, it will always offer more, because it combines API feeds from several different providers, allowing the user to compare how each is performing. To my mind, this exemplifies the use of a composite application to combine and add value to multiple raw feeds.

But there's more. WebSideStory also has an API for its own website traffic analysis application, and has nurtured an ecosystem of partners over the past couple of years whose applications interact with the Stream API, as it's called. This enables its core HBX analytics application to act as a single console for monitoring and evaluating the effects of a whole range of marketing activities that feed into a website, such as email marketing, banner advertising and so on. HBX therefore acts as an aggregation platform to bring together all of this data into a common user environment.

So WebSideStory has done a pretty good job of covering what I've described as the two most lucrative layers of the Web 3.0 cake -- the aggregation layer and the application services layer. It's also involved in the foundational API services layer, both as a consumer of raw API feeds, and as a producer of feeds on behalf of its customers -- one way to think of its core HBX service is that it enables customers to convert their website traffic into a data feed that can then be processed by the HBX application.