The Philosophy of Web 2.0
It is what it is
I was pondering the definition of Web 2.0 again this morning when I suddenly realized just how futile the attempt really is. Like SOA, we can certainly provide a list of characteristics that together prove any given application is (and conversely is not) Web 2.0, but that's a description of a set of behaviors, not really a good description of a technology.
Web 2.0 is not a toolkit, it's not a product. It is existential by its very nature, the application of a programmatic concept that declares itself a Web 2.0 application through its own behavior, and which changes over time based on the dynamic nature of emerging technology. Sartre would love this technology, as surely as Thomists would likely decry it. After all, there's no "Web 2.0 form" by which all Web 2.0 applications can be judged. No RFC means no form, right?
If we extend the argument logically that Web 2.0 is merely an existential web of emerging technology, then we come to the inevitable conclusion that until Web 2.0 stops evolving it will continue to have no absolute definition. Just as early networking technology changed at an astounding rate, so too will Web 2.0 continue to morph based on its behavior. Whatever the set of all of Web 2.0 application does is Web 2.0. Whatever it doesn't do, isn't.
It's really the only reasonable 'definition' for a technology that includes such a diverse set of technologies and protocols.
RSS. ATOM. AJAX. JSON. HTML. DHTML. JavaScript. XML. SIP. RTSP.
The complex mix of protocols, technologies, and data formats possible is mind boggling.
That's why it's amusing when someone claims that experience with a limited set of Web 2.0 applications translates to expertise across the set of all applications based on that technology. That's like claiming that expertise with Siebel CRM makes you an expert in SAP's CRM solution. There are certainly similarities that provide a firm foundation, but that's about it. It's no different for Web 2.0. There's a common set of behaviors for a subset of the protocols underpinning a Web 2.0 application, but the application comprised of interactive, real-time updating data is going to behave quite differently than the one comprised mainly of RSS feeds. The behavior is very different, and the traffic patterns that emerge from each application are vastly different in terms of throughput, connections, and predictability. Understanding the differences in how the individual technologies that make up Web 2.0 applications impact the network is the first step to understanding the overall impact of an application composed of those technologies.
This makes it more important than ever that the network architects, enterprise architects, and developers work together when developing and deploying Web 2.0 applications. The network architects need to understand the behavior of the application in order to deliver that application efficiently and reliably. Developers and architects need to understand the impact of these applications on the network to enable them to make the best design decisions possible given the constraints placed on them by location, link speed, and user base.
No application is an island, philosophically speaking, so it should never be deployed - or developed - as though it was.
Imbibing: Mountain Dew