Tag: FOWA2007

Future Of Web Apps, London – review

Future of Web Apps logoAs I mentioned previously I went to the Future of Web Apps conference this week. The conference had the usual mix of interesting, not so interesting and sales pitches – here then is my take on the interesting.

Simon Willison gave a great, very entertaining, presentation on OpenID – which for those that don’t know, is a framework for creating a decentralised service to manage your online identity. OpenID uses a single website URL, instead of a username and password, to identify yourself with a site. There are a number of OpenID providers or you can setup your own, if you’re that way inclined.

Over the last few weeks both AOL and Microsoft have come out in support of OpenID – and I would love the BBC to replace their Single Sign On service with OpenID. Anyway, at FOWA both Digg and Netvibes announced that they too will support OpenID, this is great news; I suggest you should take this as a sign to find out more – 2007 will surely see an increasing number of services adopting OpenID and new business models enabled by it.

Netvibes also announced that they will launch a Universal Widget API (UWA) with the objective of “build your module once, deploy everywhere [Vista, Mac, Google, Yahoo!]”. As part of the UWA Netvibes are releasing:

  • An open source Javascript runtime environment
  • A UI library for widgets
  • Netvibes also want to build a community of APIs

All interesting stuff but I fear that the UWA won’t be compatible with the proposed W3C widget standard which would be a real shame, anyway more information over at Techcrunch.

Other consistent themes included the importance of building an API into your web app from the outset, the use of attention data and being open and honest with your users; of these attention data is, to me, the most interesting.

“When you pay attention to something, or when you skip it, data is created”
(Matthew Ogle, Last.fm).

I suspect that we will start to hear a lot more about attention data in the coming year both in terms of functionality and generating revenue. For example, Flickr uses attention data to calculate which photos are ‘interesting‘: “We looked at how many times was a photo commented on, viewed, blogged about, and saved as a favourite” (Bradley Horowitz); or how Last.fm uses attention data to moderate the importance of user tags (if you listen to a piece of music your tags count more than if you don’t). And of course if someone knows what you pay attention to, and what you don’t, that data is incredibly valuable to advertisers.

Two pizza teams

I’m at the Future of Web Apps Conference, London this week – there are some really interesting presentation, which I will post about over the next little while but to kick things off I wanted to talk a bit about Amazon’s ‘two pizza team‘ philosophy.

Pizza Man

Werner Vogels, Amazon’s CTO presented a paper on “Why and How Its Easier Than Ever Before To Build A Web Business and Compete With Anyone” – in which Werner discussed Amazon’s Web Services S3 (Simple Storage Service) and EC2 (Elastic Compute Cloud) – and how they can be leveraged by third parties (such as Smugmug, Second Life and YouOS.com) to build web apps at significantly reduced costs. The services look fantastic, I’ll write about them in more detail another time, but for now I want to discuss something that Werner mentioned in passing, in response to a question: Do Amazon developers use the Web Services?

It appears that they do. The Amazon development teams use the Web Services (such as S3 and EC2) to provide a framework on which to build products. What is interesting is that these project teams are small: if they can eat more than two pizzas, it’s too large (i.e. no more than 8 or 10 people).

The two pizza rule appears to me (Werner didn’t expand so I’m making the next bit up) to be a great way of making sure that a problem is broken down into small, bite size (sorry), chunks. This is a very good idea because:

  1. it means each multidisciplinary project team tackles a specific, well defined, business problem – they know what they are aiming for;
  2. the team is closer to the business owner or user – in big teams it is easy for team members to hide;
  3. the team can’t get too distracted nor over engineer the problem;
  4. the team should be more efficient because there should be a lower communication overhead – both within the team and between teams;
  5. it reduces complexity and therefore risk because the problem is partitioned;
  6. the team should have greater velocity and be able to iterate more rapidly;
  7. and finally if a project does go belly up it means the company hasn’t invested too much.

This approach to application development enables Amazon to be both relatively nimble in its application development and deploy an entirely new (i.e. non-core) service to a different market segment – helping it to diversify its offering. And there aren’t too many big enterprises that can say that.

Photo: Pizza Man, by Dickuhne. Used under licence.