It seems to me that the biggest problem is not software architecture <i>per se</i>, it's when you have a software architect who thinks they are automatically senior to other members of the team. Software architects are (or at least, IMHO, should be) co-ordinators, not directors/dictators.<p>Of course architects need to be technically strong, because they need to be working with the team leads responsible for each part of the software project. That means they need to be able to communicate effectively with those leads and understand the technical implications of what is being said.<p>But it's a two-way street, and both the team leads and the architects have their own role to play. The team lead needs to be more aware of the finer details going on in their area of the project. The architect doesn't need to know those things, but does need to be aware of how everything fits together. That includes knowing enough about what each individual team is doing to identify areas where something new would be useful, or where multiple teams are doing the same thing and there is redundancy that could be eliminated.<p>Ultimately, it's all about collaboration. A software architect who only draws diagrams and produces hundred-page design documents probably isn't very useful. A software architect who talks to business leaders to clarify the requirements, liaises between the various development teams to make sure that they collectively meet those requirements, keeps an eye on testing and on bug reports coming in from the field, and so on, is pretty much essential to building large software systems successfully IME.<p>(Edit: I realise that my final description there was rather broad, and has some overlap with management responsibilities. Realistically, I think a software architect is going to have an element of that as part of their role, just as team leads do within their particular areas. But both are primarily technical roles.)