I have a couple of questions.

1.  Why would someone choose to be an architect rather than a coder?  My intuition would be that they want to have control over the code, rather than be in the position of being told what to do in code.  The cynical part of me suggests that some people choose to be an architect because they find coding difficult, or don't understand enough of it.  I know one architect, and he's in that category.  Sorry, Matt, if you're reading this.

2.  I noticed the word 'topology'.  Is it always appropriate to architect top-down?  Bottomology sounds a bit lewd, but I'm quite convinced that really good coding is done both top-down and bottom-up.  A top-down architect might not realise that 3 of the systems he's asked to be implemented are actually identical, just with different terms.  The implementor will (hopefully) realise that, and get rid of the duplication.  Maybe it would be more useful if the architect was the implementor, or part of the implementing team.  That way the architect can learn, directly, about the difficulties or inefficiencies that he's embedded in the architecture.

3.  Is the role of an architect mainly needed because, traditionally, developers are awful at communicating with customers?  I used to work for a company who, when the going was tough, would sack developers (no, I wasn't sacked!), then hire salespeople.  When the going was good, they'd sack salespeople and hire more developers.  I always thought this was wasteful; a lot of developers would make good salespeople, given a chance.  Personally I thought any developers without a project should be put on sales.  Perhaps my faith in people's flexibility is misled; what's your view?