Evolvable
systems – those systems that proceed
by themselves – i.e. not under the sole direction of one centralized design
authority – by being adapted and extended in a thousand small ways in a thousand
places at once… have three main characteristics that are germane to their
eventual victories over strong, centrally designed
systems:
1.
Only
solutions that produce partial results when partially implemented can
succeed. The
network is littered with ideas that would have worked had everybody adopted
them. Evolvable systems begin partially working right away and
then grow, rather than needing to be perfected and frozen before being tried.
Think Token Ring vs. Ethernet (big winner); VMS vs. Unix (bigger winner),
cc:Mail vs. RFC-822 (HUGE winner); XML vs. EDI ???
2.
What is,
is wrong.
Because evolvable systems have always been adapted to earlier conditions and are
always being further adapted to present conditions, they are always behind the
times. No evolving protocol is ever perfectly in sync with the challenges it
faces.
3.
Finally,
Orgel's Rule, named for the evolutionary biologist Leslie Orgel -- "Evolution is
and always will be cleverer than you are". As
with the list of the Web's obvious deficiencies, it is easy to point out what is
wrong with any evolvable system at any point in its life. No one seeing Lotus
Notes and the NCSA server side-by-side in 1994 could doubt that Lotus had the
superior technology; ditto ActiveX vs. Java or Marimba vs. HTTP. However, the ability to understand what
is missing at any given moment does not mean that one person or a small central
group can design a better system over the long haul since the target is always
moving.
Centrally designed protocols
start out strong and only improve logarithmically. Evolvable protocols start out
weak and improve exponentially. It's dinosaurs vs. mammals, and the mammals win
every time. The Web is not the perfect hypertext protocol, just the best one
that's also currently practical.
Bottom line: Infrastructure built on evolvable protocols will always be partially incomplete, partially wrong and ultimately better designed than any of its competition.
From: Anthony Beecher [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 11, 2000 2:08 PM
To: [EMAIL PROTECTED]
Subject: XML: No Magic Problem Solver
For XML Bashing fans:
I was tickled to see, in print, some support of the ideas I have held about XML for several years now.
In the September 26th issue of Business 2.0 there is an article by Clay Shirky entitled, "XML: No Magic Problem Solver".
In short the article points out that XML is simply the over hyped buzzword du jour and that, as a technology, XML is not addressing the real issues of business integration which are: "business issues"!
Take a peek, I enjoyed it.
Anthony Beecher