BT

Qual O Real Papel do Arquiteto de Software?

por Pedro Mariano em 01 Set 2010 |

"Arquiteto de Software" é um dos cargos mais desejados por diversos profissionais da área de TI. Hoje em dia é cada vez mais comum vivênciar situações onde o próprio time define a arquitetura do projeto, frameworks, tecnologias, entre outros. Dado o cenário atual, onde o papel do Arquiteto de software se enquadraria? Ele é o responsável por escolher as tecnologias e estruturas de todos os projetos de uma empresa? O arquiteto deve ser um programador?

Foi com uma indagação desse tipo que se iniciou uma discussão sobre o que o arquiteto faz hoje em dia. Guilherme Silveira, diretor técnico da Caelum e criador do Restfulie disse:

Históricamente, o arquiteto começou sendo aquele que definia quantas máquinas, quais as tecnologias, etc, mas não colocava a mão no código – ou nos diagramas de sequência, na época. A desvantagem dessa abordagem é a pessoa se distanciar cada vez mais dos problemas e das soluções que cada estilo arquitetural e ferramenta implicam no dia a dia da equipe, e começar a considerar somente aspectos facilmente visiveis de suas escolhas.

[...]

Ainda historicamente, o mercado viu a necessidade de ter alguém conectando os projetos de uma empresa, afinal uma pessoa era responsável pela arquitetura de seu projeto, mas ninguém alinhava arquiteturalmente a empresa. Daí surgiu o “enterprise architect”, alguém com uma preocupação maior.

Guilherme complementa defendendo a idéia  sobre a  teoria do Ditador Benevolente, que é aquela pessoa que tem o voto final e que muitos  confudem com o "Arquiteto 2.0".

Com o XStream aprendi sobre o ditador benevolente, que é uma pessoa (ou duas) que tem a decisão final. A arquitetura, o design, o código, o método podem evoluir pelo desejo da própria equipe, mas por fim possuem uma pessoa guia; alguém que, com mais experiência, saiba conectar melhor os planos da empresa, do produto, da equipe, da arquitetura e guiar todos para o mínimo de conflitos técnicos. Esse é o líder da equipe (não arquiteto 2.0).

[...]

Resumindo, na minha visão, os arquitetos somos nós, mas sempre em contato com as outras equipes dentro da empresa. E o líder (ou 2 líderes) é fundamental para manter o caminho em momentos de discórdia.

David Lojudice tem um ponto de vista diferente, onde o papel do arquiteto é manter a coêrencia entre as partes envolvidas em um projeto. Ele defende que a decisão de incluir ou não tal papel depende do tamanho do time e do projeto.

O seu pet project [projeto de fim de semana com 1 pessoa] precisa manter coerência entre as pessoas? Só tem uma pessoa pensando nas classes, suas responsabilidades, acoplamento e comunicação. O arquiteto é o desenvolvedor que mantêm a coerência entre essas classes. E é só olhar o código que é possível encontrar um “estilo arquitetural”, ou seja, um jeitão de implementação. Esse “jeito” é a coerência e mantida pelo desenvolvedor.

No time de 4 pessoas a arquitetura normalmente é colegiada. Precisa de arquiteto? Precisa. Só que nesse caso todo mundo é arquiteto tb. A coerência é mantida pelo time.

Já no sistema coorporativo, envolvendo muitas pessoas, muitos times, a solução do colegiado fica difícil. Precisa de arquiteto? [...] Precisa! :) Manter a coerência de integração e responsabilidades dos sistemas é o que o arquiteto(s) vai tentar fazer. Existem varias maneiras de fazer isso e depende muito do sistema sendo desenvolvido. A abordagem que usamos atualmente é a criação de um ecossistema, com regras simples, onde cada time pode criar um sistema para fazer parte desse ecossistema ao mesmo tempo que tem liberdade para usar a melhor ferramenta e a melhor arquitetura daquele sistema para resolver o problema.

Uma das coisas mais importantes para o arquiteto é que ele deve, sempre que possível, oferecer liberdade para os desenvolvedores escolherem tecnologias, framework,  não engessando totalmente o software, visto que isso faz com que seu time aprenda mais e fique mais motivado. Uma outra atitute interessante é incluir os desenvolvedores em reuniões arquiteturais, pois os mesmos podem agregar com expriências vivênciadas entre outros conhecimentos adquiridos.

E você leitor o que acha? O que o arquiteto de fato faz? Você já passou em algum projeto onde o arquiteto "engessou" o projeto? Como foi a experiência?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Opinião by Renan Oliveira

Na minha opinião, o papel arquiteto é o "cara" que conhece diversas tecnologias e possui uma vasta experiencia em projetos. Terá um grau de responsabilidade em definir qual a melhor solução para um certo problema na empresa. Mas acredito que é super importante a experiencia dos membros da equipe, pois eles podem influenciar na escolha da solução.

experiência no desenvolvimento.. by Paul .

Gostaria de dividir minha experiência em uma equipe de desenvolvimento.
Apesar de ser um cara legal, a maior dificuldade que encontrei, foi a falta de humildade do arquiteto.
Ele, "aposentado", tudo estava bom do jeito que estava, porém a empresa triplicou de tamanho, e continuamos a criar softwares legados (já nasciam legados).
E quando o desenvolvedor dava uma solução que não estava nesta "arquitetura", vinha a parte fácil, dizer "-Não!" ou apontar erros. Isto é fácil, mas quem disse que ele daria outra solução.
A soberba desmotivava a equipe inteira.

Hoje trabalho em um lugar onde damos a solução, explicamos o porque que vamos usar ela (indiferente de tecnologia) e ela é bem vinda. Por que os arquitetos sabem que convivemos com os problemas do dia a dia e que solucionamos eles.
Enfim, espero ter contribuido.
[]'s

experiência no desenvolvimento.. by Paul .

Gostaria de dividir minha experiência em uma equipe de desenvolvimento.
Apesar de ser um cara legal, a maior dificuldade que encontrei, foi a falta de humildade do arquiteto.
Ele, "aposentado", tudo estava bom do jeito que estava, porém a empresa triplicou de tamanho, e continuamos a criar softwares legados (já nasciam legados).
E quando o desenvolvedor dava uma solução que não estava nesta "arquitetura", vinha a parte fácil, dizer "-Não!" ou apontar erros. Isto é fácil, mas quem disse que ele daria outra solução.
A soberba desmotivava a equipe inteira.

Hoje trabalho em um lugar onde damos a solução, explicamos o porque que vamos usar ela (indiferente de tecnologia) e ela é bem vinda. Por que os arquitetos sabem que convivemos com os problemas do dia a dia e que solucionamos eles.
Enfim, espero ter contribuido.
[]'s

Opinião 2 by Paul .

Concordo com a exposição do colega Pedro.
Gostaria de acrescentar a importância do arquiteto
oferecer uma solução técnica alinhada ao negócio da empresa, além de ser um facilitador técnico para a equipe de desenvolvimento.
um abraço.

Opinião 2 by Paul .

Concordo com a exposição do colega Pedro.
Gostaria de acrescentar a importância do arquiteto
oferecer uma solução técnica alinhada ao negócio da empresa, além de ser um facilitador técnico para a equipe de desenvolvimento.
um abraço.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

5 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT