Vejo muita gente falando sobre o papel de um arquiteto de software. E vejo a função do arquiteto sendo deixada de lado em muitas empresas que desenvolvem software.
De fato um arquiteto é uma pessoa experiente, que conhece de tecnologia, linguagens de programação, o processo de análise e a metodologia de desenvolvimento. Um arquiteto tem que conhecer mais ainda, tem que saber quais os recursos disponíveis, qual o nível de conhecimento dessas pessoas, qual o papel de cada um. Tem que saber o que é importante para a empresa, saber o foco, saber onde pode e onde não pode gastar. Tem que estar em sintonia com as espectativas gerênciais. Não adianta criar a arquitetura perfeita se ela não serve para a empresa.
Normalmente a pessoa responsável pela arquitetura é um dos desenvolvedores. Se escolhe o que tem mais experiência. Essa pessoa vai ser a encarregada de criar e manter uma arquitetura. Vai ser responsável pela arquitetura de desenvolvimento (as ferramentas). Agora imaginamos quanto tempo essa pessoa vai legar pra realizar essas tarefas, e esse tempo pode fazer falta na construção do sistema.
Esse cenário é bem comum e costuma funcionar muito bem. Mas os prejuizos para o projeto são evidentes, sendo que o melhor desenvolvedor acaba perdendo bastante tempo com suporte aos demais desenvolvedores e a arquitetura do sistema. Quando qualquer coisa der errada, é ele que terá de responder. Nesse caso o responsável pelo framework que também implementa os requisitos do sistema tem que parar seu trabalho para dar suporte. Ai envolve tempo, concentração e disposição. E um ótimo desenvolvedor acaba não sendo utilizado como poderia.
Mas caso o sistema deva receber chamadas remotas por exemplo. Logo vem a cabeça a utilização de EJB, que seria uma boa escolha. Mas e se caso apenas 2% das chamadas do sistema forem remotas. Seria inteligente sofrer o aumento de processamento dos EJB para o sistema inteiro só por causa de 2%. Quem pode nos dizer qual a melhor saida para esse problema se ninguém da equipe tem uma experiência do tipo?
Quando um sistema possui várias premissas, e principalmente quando essas premissas envolvem o ambiente de desenvolvimento, um arquiteto deve ser o responsável por, não apenas responder as perguntas, mas em implementar e suprir as necessidades. O arquiteto não implementa as regras de negócio do sistema. Ele implementa a infra-estrutura que o desenvolvedor vai usar para implementar a regra de negócio.
Algumas questões normalmente são deixadas de lado como, qual o nível técnico dos desenvolvedores? Muitos artigos dizem coisas como "equipe altamente qualificada é fundamental". Ok, mas no mundo real ter uma equipe altamente qualificada pode ser extremamente dificil, e o mais comum é ter uma equipe de programadores jr a pleno. O Arquiteto deve levar em consideração esse fator que pode ser fundamental para o sucesso do projeto.
Durante o desenvolvimento, o arquiteto também deve acompanhar e garantir que o sistema esta sendo contruido como planejado e se a qualidade é a esperada. Esse procedimento serve para, alem de tentar garantir a qualidade, fazer uma validação constante da arquitetura. Caso um arquitetura esteja causando mais problemas do que vantagens pode ser o caso de mudar a arquitetura. Vale lembrar que a arquitetura deve ajudar o desenvolvimento, e não gerar mais problemas.
O arquiteto também deve ser uma pessoa chave na definição de um projeto de tecnologia. Na fase de planejamento do projeto ele deve definir, mesmo que preliminarmente, quais tecnologias irão ser utilizadas e um esboço inicial da arquitetura, para que essas variáveis entrem para o projeto.
A questão de ter ou não um arquiteto é o mesmo de ter ou não uma arquitetura oficial, mantida e suportada, o que pode garantir a qualidade ao sistema. Um sistema desenvolvido com qualidade irá ter um custo menor de manutenção, e a manutenção pode ser muito mais cara que a construção do sistema.
segunda-feira, 3 de abril de 2006
Assinar:
Postagens (Atom)