What a great comment, Paul!
We need to ensure the "architectural requirements" are met in the same way Toyota must ensure their cars are roadworthy, profitable and marketable. How we achieve this is a matter for debate but I'd certainly hope that we'll continue to evolve new techniques.
Your statement that the "Conway effect" can be made to disappear by (essentially) changing the way the team communicates is paradoxical: the effect you mention mimics the communication structure of the team and will necessarily change. This is why I suggest that you can influence the emergent design by influencing the team.
While I appreciate the utopian situation wherein "everyone considers everything" [about the whole], I can't see it being achievable across domains (eg, knowing everything about equity swaps and JavaEE development). Nonetheless, I hope we're doing our part by trying to make developers more architecturally aware and therefore more appreciative of the existence of the whole, if not all of its intricacies!
You're right that we do talk about architecture as a given. Indeed, all systems have an architecture insofar as they may have portions that are costly to change and requirements of a non-functional nature, regardless of whether someone has taken the time to think about them. How these are dealt with is indeed a choice. It's this choice that we try to shed some light on based on our experiences and opinions.
Nonetheless, if organisational or process change is part of a suitable approach to meeting your needs then I'd recommend it!
E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).