Six years ago, Joel Spolsky wrote a piece on Architecture Astronauts, people who get so obsessed with the big picture that they miss the important little details that actually make things work. More recently, Dare Obasanjo pointed to Spolsky’s piece in his posting XML Has Too Many Architecture Astronauts.
I’d like to start by agreeing with Dare: XML does have too many architecture astronauts, and almost everything that’s bad, ugly, or simply scary about the huge number of standards built around XML (WS-* springs immediately to mind, but it’s not alone) comes from gross overgeneralization. That said, architecture astronauts do have their place, and we ignore them at our peril.
Case 1: Napster
Let’s start by turning Spolsky’s main example (which Dare cites) on its head. Here are two different perspectives on Napster circa 2001:
Architecture pedestrian: Napster lets people find and download songs.
Architecture astronaut: Peer-to-peer networks let people find and download songs. Napster is (was) a peer-to-peer network.
Spolsky writes about how architecture astronaut perspective helped to fuel a mini-P2P bubble at the time, with investors pouring wasted money into P2P-everything, when Napster’s success was due not to the fact that it was P2P but to the fact that it let people get songs easily. However, consider what was happening at the same time in the music industry. Rightly or wrongly, they wanted to stop people from sharing songs. The architecture pedestrian perspective (my term, not Spolsky’s) told them that Napster lets people find and download songs, so the industry spent millions of dollars in legal fees, PR, etc. shutting down Napster. The result? People downloaded even more music. After all, as the astronauts said, it was P2P networks that let people share music, not Napster in particular. Since then, the music industry has been fighting the equivalent of an insurgency, putting down one uprising after another with no end in sight.
Case #2: The Netscape IPO
My second example took place over 11 years ago, kicking of the much larger dot.com bubble (the P2P mini-bubble was just a tiny part of its tail). It was around 1995 that most non-techies noticed the web, mostly through the lens of the Netscape browser. Again, the architecture pedestrian and the architecture astronaut looked at this differently:
Architecture pedestrian: Netscape lets people see text and pictures online.
Architecture astronaut: The web allows people to put text and pictures online. Netscape is a web browser.
This time, the investors listened to the architecture pedestrian rather than the architecture astronaut: Netscape was set to open at $14/share, doubled to $28/share, and climbed to $75/share on the first day, and eventually reached a peak market cap of $8 billion. The astronauts knew all along, however, that while people (at the time) thought of the web in terms of the Netscape browser, the web wasn’t Netscape. If Internet Explorer hadn’t knocked Netscape off its perch (resulting in layoffs as early as January 1998), some other browser soon would have.
Case #3: XML
So how does this all apply to XML? I think that there are two ways that architecture astronauts can approach XML, one good and one bad. The bad one is in line with Spolsky’s original piece, where people miss what made XML popular (relative simplicity, no need to create DTDS, etc.) and believe that if a bit of standardization is good, a lot must be even better. The good one is to step back and point out that most of the advantages that appear to come from XML actually come from generic tree markup, and that holy wars between XML, JSON, YAML, etc. are really beside the point. In various situations, one syntax may have an advantage due to software support — for example, web browsers have built-in support for parsing XML or styling it using CSS, and they can convert JSON directly to JavaScript data structures using the eval() function — but when you look at the whole world of generic markup, those are small blips on a very large screen, and all of the markup languages more-or-less look the same.
Quoderat 
Bravo, Solomon. In my opinion you landed a knock-out blow to put this one to sleep. I thought Dare’s post was terribly overstated. For one thing JSON folks are also always trying to compare their *format* to XML, and so by Dare’s reasoning they are also missing the point and JSON too has too many architecture astronauts. In the end, every technology choice builds on warfare between architecture astronauts and pedestrians, because sometimes the As have it (e.g. Web and P2P as you illustrate), and sometimes the Ps (e.g. Wiki vs CMS to pick a random example). And most of us are As in one case and Ps in another. Seems commonsense to me, but nevertheless thanks for
arguing the point so graciously.
I will second Uche’s comments: I think you’ve stated it exactly right: it’s about generic trees, not syntax.
“generic tree markup”
yep — that there is the goodness. i like your conclusion!
Pingback: UpToEleven.ca » Architecture Fighter Pilots
I think you’ve made a false dichotomy between the extremes of “Astronauts” and “Pedestrians” and then concluded that since we need at least *some* abstraction to make anything useful, Astronauts are the way to go. Fortunately, there’s a whole range of options between the the two.
There aren’t “two ways for an Astronaut to approach XML”: by the definition of an Astronaut, they’ll approach it the bad way. It’s the people that occupy that middle ground between the Astronauts and the Pedestrians that will approach it in a “good” way and produce something useful.