Arquiteto de Software não é brinquedo!
É incrível como algumas empresas tratam o arquiteto de software
como se fosse o brinquedo da vez. Lembra quando éramos pequenos e
existia aquele brinquedo especial que todos queríamos ter e quem o tinha
era visto como um ídolo diante a criançada. Pois bem, as empresas fazem
o mesmo com o arquiteto de software!
Pense na definição da profissão “Arquiteto de Software”,
uma das muitas definições existentes segue abaixo:
“A arquitetura de um software é a estrutura ou estruturas do
sistema, o que compreende componentes de software, propriedades
desses componentes que são visíveis externamente e o relacionamento
entre eles”, Paul Clements, SEI.
Muitas vezes os profissionais que trabalham nessa profissão
não realizam exatamente o que devem, mas
a empresa se enaltece por ter um arquiteto de software envolvido em um de seus projeto.
O papel de um arquiteto de software é equiparado ao papel de um gerente de projetos,
onde um gerência a tecnologia aplicada e o outro gerência pessoas. Portanto, temos que o
fracasso de um projeto por causa de uma má gestão pessoal é culpa do gerente de projetos e
o fracasso de um projeto por causa de um problema técnico é culpa do arquiteto de software.
Ao desenvolvermos um software para um cliente temos que seguir uma lista de requisitos
que são eles funcionais e não-funcionais. Os requisitos funcionais estão quase sempre relacionados
ao negócio da empresa, como exemplo “Realizar pedido”. Já os requisitos não-funcionais estão
relacionados com performance, disponibilidade, interroperabilidade, escalabilidade,
segurança, performance, usabilidade, etc. São inúmeros os requisitos não-funcionais e
às vezes são desprezados por muitos, principalmente o gerente de projeto. O gerente de projetos
quer ver o pedido sendo realizado e o dinheiro entrando na conta da empresa e na dele,
mas temos um enorme problema nisso! Ao ignorarmos os requisitos não-funcionais, que nunca são poucos,
estamos escondendo o sol com a peneira e esperando para ficar cegos.
O papel do arquiteto de software deve ser de não permitir que os requisitos não-funcionais
sejam ignorados e nem tão pouco deixados para última hora. Muitos requisitos não-funcionais podem
interferir diretamente em um requisito funcional. O Arquiteto deve entender e compreender os
requisitos não-funcionais e propor soluções para resolvê-los. Mas isso não é o que acontece nas
empresas por ai.
Primeiro, para a maioria das empresas é inaceitável o arquiteto de software ter o mesmo
nível que um gerente de projeto. Segundo, nunca um arquiteto de software tem voz ativa
diante uma equipe de desenvolvedores que estão acostumados a fazer telas em linha de produção.
Por isso um arquiteto de software não é um super brinquedo que somente serve para
se exibir e que com o tempo perde a utilidade. Um arquiteto de software é o ícone muito influente
no ciclo de vida de um projeto e é dever dele garantir que o software funcione desde o
início de sua vida em um ambiente de produção.
O link de referência citado abaixo tem uma ótima descrição do papel de um arquiteto, todas
as empresas deveriam ler e seguir este documento, assim teríamos software funcionando!
* http://www.wthreex.com/rup/process/workers/wk_archt.htm
Links relacionados:
* http://pt.wikipedia.org/wiki/Arquitetura_de_software
* http://www.marcomendes.com/ArquivosBlog/IntroducaoArquiteturaSoftware.pdf
Paulo R. A. Sales 
Fala Paulo! Interessante seu artigo.
Mas dizer que “…assim teríamos software funcionando!”, acho que é um pouco de exagero seu. 🙂
Software funcionando está mais relacionado a boas práticas de desenvolvimento, do que a um papel em especial.
Uma boa arquitetura de software é fundamental, sem dúvida alguma. Mas nem sempre o papel do arquiteto é tão fundamental assim.
Há abordagens, por exemplo, em que um grupo de desenvolvedores se reunem com o propósito de pensarem e executarem a arquitetura do software que estão desenvolvendo, e dai em diante, se comprometem mutuamente a mantê-la e evoluí-la colaborativamente. Ou seja, não há o nome de uma pessoa especifica num boné, mas sim, um bocado de bonés “Hora da Arquitetura, Rapaziada!”, para todos os desenvolvedores usarem, quando se reunirem para a discíplina de Arquitetura de Software.
Acho que tudo depende do tamanho do projeto, da abordagem de engenharia adotada, de sua natureza, etc.
Agora, fato é: A arquitetura não pode ser negligenciada de maneira alguma.
(IMHO)
Abraço!
—
Contribuindo com mais um ou dois tostões:
http://leandrosilva.com.br/2008/08/22/erros-primarios-que-um-arquiteto-nao-pode-cometer
Oi Leandro,
Muito obrigado pelo comentário, acabei me equivocando e colocando o papel do arquiteto de software em um patamar alto demais, super-valorizei!! rs
“Não é só de pedras que um castelo é construído!”
Abraços,
Paulo.
Apenas dando o meu pitaco, acho que seríamos mais felizes se nossas equipes focassem primeiramente na necessidade real do cliente, e depois em boas práticas para suprir essa necessidade. Estamos em 2009 e ainda tem gente fazendo as coisas sem saber o que o cliente pensa a respeito….
(IMHO)
Acho que o papel ideal do arquiteto é o do profissional que sabe ouvir. Aquele que se porta como facilitador entre os desenvolvedores.
(IMHO 2)
Belo post, Paulo!
Em cima desse assunto indico mais 2 links:
O tópico do wikipedia que eu traduzi a um tempo atrás:
Arquiteto_de_software
E o pdf da matéria do Martin Fowler:
Who Needs an Architect?
[]!
LeoLuz
Uma certa pessoa me disse que daqui a algum tempo, não teremos mais médicos, mecânicos…..tudo vai ter algo relacionado com software no meio………ou hardware…..ainda bem que eu só trabalho com redes!!!
Abraço paulinho……
Tô te aguardando pra tomar aquela torre de 5lt. aqui em são roque…..
Muito bom post!
Ainda acompanhando a metáfora, o Arquiteto de Software não é um brinquedo q só se ganha no fim da festa, ele na verdade deve estar no planejamento, preparativos, lista de convidados e no fim ajudando e abrir os presentes. Para q ele tenha real envolvimento no sucesso ou fracasso (técnico) é imprescindível que este tenha visão do todo.
Outro ponto que talvez pudesse ter sido citado é a classificação do arquiteto como um super desenvolvedor e que portanto um (recurso) q pode chegar no projeto somente no momento da construção, neste caso, o sem a menor possibilidade de questionar, criticar, apoiar, classificar os requisitos (funcionais e não funcionais) previamente levantados.
Para finalizar, como já conversamos algumas vezes, é de responsabilidade do arquiteto a definição do ciclo de vida do projeto, portanto o promove para um brinquedo com no minimo “Inteligencia Artificial” (agora sim ficou viagem, hein!)
Abraço!