The concept of "Web 2.0" began with a conference brainstorming session between O'Reilly and MediaLive International. Dale Dougherty, web pioneer and O'Reilly VP, noted that far from having "crashed", the web was more important than ever, with exciting new applications and sites popping up with surprising regularity. What's more, the companies that had survived the collapse seemed to have some things in common. Could it be that the dot-com collapse marked some kind of turning point for the web, such that a call to action such as "Web 2.0" might make sense? We agreed that it did, and so the Web 2.0 Conference was born.
Web 2.0 As A Platform:
Web 2.0 doesn't have a hard boundary, but rather, a gravitational core. You can visualize Web 2.0 as a set of principles and practices that tie together a veritable solar system of sites that demonstrate some or all of those principles, at a varying distance from that core.
Example:
Web 2.0 conference, in October 2004, John Battelle and I listed a preliminary set of principles in our opening talk. The first of those principles was "The web as platform." Yet that was also a rallying cry of Web 1.0 darling Netscape, which went down in flames after a heated battle with Microsoft. What's more, two of our initial Web 1.0 exemplars, DoubleClick and Akamai, were both pioneers in treating the web as a platform. People don't often think of it as "web services", but in fact, ad serving was the first widely deployed web service, and the first widely deployed "mashup" (to use another term that has gained currency of late). Every banner ad is served as a seamless cooperation between two websites, delivering an integrated page to a reader on yet another computer. Akamai also treats the network as the platform, and at a deeper level of the stack, building a transparent caching and content delivery network that eases bandwidth congestion.
The need for agility in Web 2.0
Consider the application of Web 2.0 on a project. Your marketing team comes to you asking for a community platform to promote a new product. The team members want some commentary and buzz created, maybe a few videos, and perhaps a survey. They really are trying to come up with a strategy to generate enthusiasm around a new product and want to use the Internet as a means to promote and sell it. A novel idea in today's world just isn't enough on its own.
You're the information technology (IT) person who's going to help them with all of this. You have an initial meeting with the marketing director and hear his or her ideas. You immediately think, Web 2.0 content-management system (CMS), such as Joomla. Do you have the luxury to ask very detailed questions on how the site should function? Do you have the luxury of creating a traditional requirements document, use cases, and so on? Will you create a Unified Modeling Language (UML) design of the system? The answer should be, “Obviously not!”
You need to be agile. You'll do some basic fact finding as to the functionality required, and then you'll download and install Joomla. You'll find the appropriate plug-ins and get the functions working. A majority of your time—probably more than 75 percent—will be spent on the custom style sheet that you need in order to brand the site for the new product you're promoting.
Depending on the details and scope, from idea to deployment, the marketing site for the new product should take less than one month to create. Remember, this site will probably have a short shelf life. In a majority of cases, it's not going to be a site that someone uses for five years—or even one year.
This rapid software development process can be defined more formally in terms of a software life cycle model. You've probably read about extreme programming, Scrum, and other agile development processes. To me, those are also probably too rigid for what you need. You must define which aspects of these agile processes you can adopt to best suit your needs. User stories, iterative development and releases, and a simple planning game are the key elements of your new process. It's also a good idea to include a quality assurance and testing cycle, as well as user-acceptance testing.
Web 2.0 doesn't have a hard boundary, but rather, a gravitational core. You can visualize Web 2.0 as a set of principles and practices that tie together a veritable solar system of sites that demonstrate some or all of those principles, at a varying distance from that core.
Example:
Web 2.0 conference, in October 2004, John Battelle and I listed a preliminary set of principles in our opening talk. The first of those principles was "The web as platform." Yet that was also a rallying cry of Web 1.0 darling Netscape, which went down in flames after a heated battle with Microsoft. What's more, two of our initial Web 1.0 exemplars, DoubleClick and Akamai, were both pioneers in treating the web as a platform. People don't often think of it as "web services", but in fact, ad serving was the first widely deployed web service, and the first widely deployed "mashup" (to use another term that has gained currency of late). Every banner ad is served as a seamless cooperation between two websites, delivering an integrated page to a reader on yet another computer. Akamai also treats the network as the platform, and at a deeper level of the stack, building a transparent caching and content delivery network that eases bandwidth congestion.
The need for agility in Web 2.0
Consider the application of Web 2.0 on a project. Your marketing team comes to you asking for a community platform to promote a new product. The team members want some commentary and buzz created, maybe a few videos, and perhaps a survey. They really are trying to come up with a strategy to generate enthusiasm around a new product and want to use the Internet as a means to promote and sell it. A novel idea in today's world just isn't enough on its own.
You're the information technology (IT) person who's going to help them with all of this. You have an initial meeting with the marketing director and hear his or her ideas. You immediately think, Web 2.0 content-management system (CMS), such as Joomla. Do you have the luxury to ask very detailed questions on how the site should function? Do you have the luxury of creating a traditional requirements document, use cases, and so on? Will you create a Unified Modeling Language (UML) design of the system? The answer should be, “Obviously not!”
You need to be agile. You'll do some basic fact finding as to the functionality required, and then you'll download and install Joomla. You'll find the appropriate plug-ins and get the functions working. A majority of your time—probably more than 75 percent—will be spent on the custom style sheet that you need in order to brand the site for the new product you're promoting.
Depending on the details and scope, from idea to deployment, the marketing site for the new product should take less than one month to create. Remember, this site will probably have a short shelf life. In a majority of cases, it's not going to be a site that someone uses for five years—or even one year.
This rapid software development process can be defined more formally in terms of a software life cycle model. You've probably read about extreme programming, Scrum, and other agile development processes. To me, those are also probably too rigid for what you need. You must define which aspects of these agile processes you can adopt to best suit your needs. User stories, iterative development and releases, and a simple planning game are the key elements of your new process. It's also a good idea to include a quality assurance and testing cycle, as well as user-acceptance testing.
