Thomas,
These are all good points (and distinctions).
One thing that many of these failed projects have in common is that they are SYSTEMS, and for all that we title ourselves system architects the reality is that systems are hard because complex systems are interdependent. Reductionism will take you only so far, and then feedback begins to change the nature of the system, and this holds as true (perhaps even more true) for developing systems as it does for maintaining them.
In so much as the term has become pretty meaningless, any architect is, has to be, a systemic thinker. To the extent that these projects fail, most do not do so due to a single component failure. They fail because they are systemically poorly designed - integration can't happen without a lot impedance, there's a lack of consistency with regard to data models, there are no ways of routing around a failure point. I think a point in favor of agile is that it encourages systemic understanding of the problem domain and how any solution much integrate, but even that's not a panacea when there's a failure of architecture.
In many respects the political aspects of a project should be seen as a side-show. Pointy-haired managers will always be clueless, because for the most part, they lack the technical expertise to understand the systemic nature of the process. The procurement process will always seem byzantine and inherently unfair because money is involved, and everyone will want to water their fields first before letting the river move on to the next farmer. Yet at a technology level, you need to have a person (or people) who both understands the technical challenges and can nonetheless keep a systemic view of the problem in sight. I'm not sure this is leadership - an architect is not in general a leader or even a manager. It's something different, and I don't think we are, collectively, very good at it yet.
