Flash-based ICQ client
http://www.icq.com/icq2go/
The internet is on my mind a lot lately. A lot of our careers have never known a world without the internet; the convergence of people, machines, and society is the root of what makes software design meaningful to me.
The Flash-based ICQ client is really cool. It makes me ask, "What does it mean to compete on the internet?" I interpret the word "compete" to mean the differentiation of your goods or services compared to others' towards some end goal, usually monetary profit. NetDictionary has the best definition of the internet: "A worldwide network of networks that all use the TCP/IP communications protocol and share a common address space."
So, competition on the internet seems to involve the differentiation of goods or services on a worldwide network based on TCP/IP, within a common address space. The definitions of competition and internet both imply the possibility of vigorous emergent behavior, but that's a relevant topic to be shelved for another time. Anyhow, I find the definition of internet competition satisfying for now, so let's ask a better question:
What is the best way to compete on a worldwide network based on TCP/IP, within a common address space? Let's break down this battle ground...
------------------------
TCP/IP - In order to participate on the internet, you must speak this protocol. (RFC)
------------------------
There is a family of competitive strategies that involve dominating some fundamental utility of an economy, but these strategies do not work with the internet. The internet's intrinsic value is its status as a commons for competition. Attempts to deviate from, subvert, destroy, or hinder the function of TCP/IP either reduce the value of the network as a whole, or cause the network to ex-communicate the origins of such attempts. So, it looks like the cost/benefits of dominating the internet are very low ;-)
--------------------------
Common address space - the same natural phenomemon that protects the integrity of TCP/IP also protects the universal adoption and function of DNS.
--------------------------
However, the human factor of limited memory makes short URL's more valuable than long URL's. Ownership of address space gains value towards the roots of the address space. For example, "geocities.com/arts/website2304" is less valuable than "about.com", which is less valuable than ".com". Ok, noted: the value of address spaces is proportional to their ease of memorization by humans... or at least ease of storage and retrieval at some level of human-computer interaction.
The value of tcp/ip, DNS is that everyone must observe their rules in order to use them. Given this battle ground, let's talk about differentiation of goods and services... all goods and all services must be transferrable via tcp/ip and either delivered to/from/via some address space.
Well, this raises more questions that I have time for tonight :)
Some side thoughts... HTTP is also another universal protocol but its longevity has less protection than TCP/IP. I guess the same comparison could be made between higher and lower levels in any architecture. Attempts to build protocols on top of HTTP have even less odds for longevity, like all the new SOAP and ws-* stuff, any complicated xml schema, etc.
More side-notes:
Rob Fielding's dissertation takes care to distinguish between static and dynamic approaches to architectural design. I haven't gotten to the juicy stuff yet, but his definition of the semantics of architecture are a great intro. Anyhow, I think he makes a point that software should take into account the connector elements of architecture (how data is transferred), and not only focus on the component elements (how data is transformed).
Another side note: at the Emily Carr school of design in the Granville neighborhood of Vancouver, there was a museum displaying some work by some architects that continues to evolve after 17 years. The quote on the wall was awesome, and went something like "Buildings change over time... we realized that change is a latent part of architecture".
Last side note: In chapter 1, the most valuable insight I gained as a non-computer-science person was that architectural styles and design patterns are not prescriptive structures or snippets of code you should re-use. Styles and patterns are recognition that some natural event occurs frequently or is valuable, and that the design of some structure should resolve or flow with the re-occurring natural event. So, I think it's very important to ask "what is this for?" or "what natural need or event am I trying to deal with in my project?". Second most valuable insight is that styles and patterns are not about re-using structures, but more about recognizing re-occurring events and adopting previous decisions in designing for these events... in other words, study what the trade-offs were, and why the decisions were made.
Posted by samuel at April 17, 2005 10:59 PM