Qual o real papel de um Arquiteto de Software

A questão apareceu em uma discussão da Tectura.

Comecei a escreve uma resposta, mas a coisa ficou tão longa que resolvi postar aqui =\

Versão para apressados:

0 - IMHO, acho que estamos respondendo na discussão como o arquiteto de agir, mas não o o quê (papel) ele deve fazer...
1 - Simplificando absurdamente um arquiteto de software cuida da arquitetura de sofware (duh, momento Homer)
2 - Infelizmente, Arquitetura de software NÃO é um conceito aceito universalmente, nem é um conceito bem definido, muito pelo contrário. Cada um fala o que quer sobre o assunto e ninguém está errado :)
3 - Um dos melhores trabalhos sobre o tema é de Bass et al.
4 - Segundo ele, uma das principais funções do arquiteto é cuidar das "ilities" do software e documentá-lo.
5 - Pessoalmente, acho que documentação de software é só uma tática para atingir "modificabilidade".
6 - Conclusão: se o raciocínio desses caras estiver correto e se a minha opinião estiver correta, o papel do arquiteto é garantir as "ilities" de software, e para isso, precisamos nos meter em tudo qto é buraco do desenvolvimento de software, da negociação ao código.
7 - Mas todos nós podemos estar errados ;)

Versão para pacientes:

Acho q estamos confundindo a resposta, ou talvez eu não tenha entendido bem a pergunta. IMHO, boa parte das nossas respostas estão indo no caminho "como um arquiteto de software deve se comportar" e não "o que um arquiteto de software deve fazer".

Digo, se ele é um ditador, um comunicador, um líder nato, se é up front, "ágil" ou whatever, isso é COMO ele faz, e não O QUÊ ele faz. (tá correto isso?).

Tentando colocar a questão de outra maneira: "O que (papel) um Arquiteto de Software faz?"

Resposta óbvia: "Cuida da arquitetura" (duh)

E aí caímos na questão do Guilherme Silveira: "Uma questão anterior ao papel do arquiteto é o que é arquitetura"

Consultando a wikipedia (http://en.wikipedia.org/wiki/Software_architecture e http://en.wikipedia.org/wiki/Software_architect) e mais algumas fontes (http://goo.gl/ucNC, http://www.sei.cmu.edu/architecture/start/community.cfm, por exemplo, mas vc pode procurar por mais) dá pra perceber rapidamente que não existe um conceito uniformizado sobre o que é a bagaça. Ou seja, cada um de nós tem uma concepção diferente do que é arquitetura, e nenhum de nós está errado, simplesmente pq não existe resposta certa aceita por todos.

Um trabalho sobre o assunto que é sempre citado é o de Bass et al, mesmo assim, se vc lê-lo atentamente, vai perceber alguns conceitos que vêm "from thin air" (ou seja, sem referência a outros trabalhos), embora sejam caras experientes com vários projetos de sucesso na bagagem.

Segundo esse trabalho, uma das preocupações do arquiteto é garantir as "ilities" de um software (http://en.wikipedia.org/wiki/Software_quality) e documentar a coisa toda.

Opinião pessoal, eu concordo com a parte de garantir as "ilities", mas acho que a documentação é só uma outra tática para se atingir "modificability" ou "manutenability".

E se isso está certo, desde "Time to Market" até "Performance" e "Usabilidade" são responsabilidade do arquiteto. Para poder garantir isso, então, o arquiteto deveria se meter desde a negociação do software até programação e interações com o usuário.

Por outro lado, podemos estar todos redondamente errados. Por quê? Bom, "arquitetura" de software e "arquiteto" de software são papéis que foram criados por similaridade metafórica com construção civil. Se você já trabalhou desenvolvendo software, sabe que essa metáfora é muito frágil. Ou seja, podemos estar tentando criar um papel que não faz sentido existir. Por outro lado, existe algo realmente de alto nível que precisa ser cuidado, e que está muito mais alto nível do que estamos acostumados a pensar.