O papel do arquiteto de softwares

Hoje estava lendo um artigo escrito por Martin Fowler entitulado "Who needs an architect?" e gostaria de destacar alguns conceitos que pude retirar do texto.
Estes conceitos nos ajudam a compreender qual é o papel de um arquiteto de softwares em um projeto de desenvolvimento e também nos ajudam a definir melhor o conceito "arquitetura de softwares".

O que é arquitetura de software?

De acordo com o RUP (Rational Unified Process) podemos definir arquitetura de softwares da seguinte maneira:

"O conceito de mais alto nível de um sistema. A arquitetura de um sistema de software  é a sua organização ou a estrutura dos componentes mais importantes interagindo através de interfaces, sendo que esses componentes, por sua vez, são compostos de componentes e interfaces sucessivamente menores."


Ralph Johnson (http://pt.wikipedia.org/wiki/Ralph_Johnson) se mostra contrário a essa definição pois ele acredita que não existe um conceito de nível mais alto em um sistema, pois esse conceito depende do seu ponto de vista.
Clientes possuem um conceito totalmente diferente dos desenvolvedores do sistema, eles não se importam com a estrutura dos componentes em si, e sim com as funcionalidades do sistema. Tendo isso em mente, ele  prefere definir arquitetura da seguinte maneira:

"Na maioria dos projetos de software bem sucedidos os desenvolvedores mais experientes do projeto compartilham um entendimento único do design do sistema. Esse entendimento compartilhado é chamado de 'arquitetura' e inclui a maneira na qual o sistema se divide em componentes interagindo através de interfaces, sendo que esses componentes, por sua vez, são compostos de componentes e interfaces sucessivamente menores.".

Outra boa definição levantada:

"Arquitetura é um grupo de decisões de design que devem ser feitas no início do projeto."  

O problema desta última definição é o fato de que é muito difícil acertar todas essas decisões. Então se é muito difícil tomar essas decisões acertadas no início do projeto, por quê que a maioria dos analistas continuam tentando?

A resposta é bastante óbvia. Essas decisões são tomadas pois vão gerar componentes de software que são difíceis de serem alterados. Por exemplo: Se você optou por persistir os dados no SQL Server, e mapeou as entidades com LINQ to SQL, uma vez que  a aplicação esteja toda escrita baseada nesse mapeamento objeto-relacional , você provavelmente nunca mais vai se livrar dele.

Tendo isso em mente podemos definir arquitetura como:

 "Componentes do software que são muito difíceis de se alterar."

Qual é o papel do arquiteto de softwares?

Uma das tarefas mais importantes de um arquiteto é  encontrar maneiras de eliminar irreversibilidade e reduzir a complexidade de um determinado projeto de software. Ele deve ser muito ciente do que está acontecendo no projeto,olhando para questões importantes e deve abordá-las antes que se tornem um problema sério.

A parte mais visível do trabalho de um arquiteto de softwares é a colaboração intensa com os outros recursos do projeto. Pela manhã,  um arquiteto pode estar programando junto com um desenvolvedor, enquanto na parte da tarde, o arquiteto participa de uma reunião de requisitos junto aos StakeHolders e clients, ajudando a explicar o impacto e consequência técnica das decisões que estão sendo tomadas.


O arquiteto é um dos mais experientes membros da equipe, e deve atuar como um guia. Responsável por ensinar outros recursos a tomar as melhores decisões e adotar boas práticas para evitar problemas futuros além de ajuda-los tecnicamente em tarefas mais complexas.







Fonte: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf