Arquitetura de software e o papel do arquiteto

Quando falamos em grupos a respeito engenharia de software, acabamos nos deparando com experiências bem diversificadas, tanto de sucesso quanto de grandes falhas. Dentre esse indivíduos, há várias posturas sobre o assunto arquitetura e o papel do arquiteto, os quais podemos citar aqueles que:
  • desconhecem e/ou ignoram o papel do arquiteto ou as práticas arquiteturais
  • conhecem, mas não percebem valor em ter um arquiteto no time
  • conseguem ver valor, mas não compreendam plenamente o seu escopo de atuação
  • adotam as práticas de arquitetura e valorizam o papel do arquiteto na medida certa
Para fugir um pouco dos conceitos acadêmicos, vou falar como entendo a arquitetura: 

Trata-se de um conjunto de atividades e práticas, com o objetivo de descrever o domínio da solução, com base numa visão geral do domínio do problema e uma boa compreensão dos requisitos, de modo a viabilizar a entrega do software com qualidade, atendendo à expectativa do cliente.

O arquiteto de software, por sua vez, é o profissional que responsável por essas atividades, algumas vezes como executor, outras delegando tarefas e as acompanhando.

Embora eu recomende que todo o time de desenvolvimento tenha um arquiteto, em alguns cenários específicos, como em equipes que têm um grau de senioridade mais elevado, o arquiteto não existir numa pessoa, mas teria suas atividades diluídas no grupo de profissionais. Trata-se de um ponto relevante, porque as práticas arquiteturais continuam existindo, mas com outros executores.

A primeira vantagem de ter um arquiteto responsável é justamente dar um dono à etapa de solução técnica. Sem dono, as responsabilidades se perdem, ninguém é cobrado e vira uma bagunça. 

O arquiteto deve se envolver já nas primeiras atividades do projeto, ajudando a levantar requisitos. Arquitetos são especialmente úteis nas definições não funcionais, normalmente negligenciadas pelos projetos de software. Aqui, serão formalizados requisitos como desempenho/tempo de resposta do software, escalabilidade, segurança, nível de disponibilidade, precisão, noção inicial da infraestrutura, entre outras características.

Uma coisa que gosto de ressaltar sobre o arquiteto: ele deve saber falar o linguajar do cliente, mais próximo ao negócio que o software apoiará, como ter proficiência na fala técnica. É um verdadeiro tradutor de necessidades do cliente (vide post anterior) para o tecniquês do desenvolvimento. Isso faz com que a arquitetura contribua para a rastreabilidade dos requisitos. Sim, porque o arquiteto entende o problema junto à(s) pessoa(s) responsável(is) por requisitos, o divide e objetivos a serem atacados, e sugere a solução técnica, que vai nortear a fase de codificação, fazendo que essa última honre o que foi definido e acordado com o cliente.

É excelente quando o arquiteto também coloca suas mãos em código, ficando mais próximo do time de desenvolvimento. Dessa forma, fica mais fácil propor soluções viáveis. E se o time não estiver conseguindo seguir suas orientações, ele programa e capacita. Outra coisa: nada de arquiteto estrelinha, que se acha melhor que programador. Isso é uma tremenda bobagem. São todos do mesmo time e vestem a mesma camisa na hora de jogar.

Minha experiência me diz que ter um arquiteto no time diminui riscos e custos. Aqui, argumento na mesma linha daquela usada a respeito dos testes automatizados: não tenho estatísticas, números precisos, mas é bem fácil perceber que não ter práticas arquiteturais (ou testes), o software sai com pior qualidade e essa economia (porca) vem cobrar o seu preço no futuro. Pode apostar. Não é tão fácil formar um arquiteto, nem tão rápido. Em função disso, o seu custo acaba sendo um pouco mais alto, mas, como já afirmei, vale muito a pena - o profissional vai se pagar, com certeza.

Mais um ponto super relevante: arquiteto não só desenha a solução, mas acompanha o seu desenvolvimento. Se o arquiteto usar aquele anti-pattern, conhecido por "Mestre dos magos", em que fala o plano por alto e depois desaparece, bem, vamos ter problemas. Mantenha o arquiteto por perto.

Provocações finais

Qual a proporção ideal de arquitetos para desenvolvedores em um time? 
É possível trabalhar a questão da arquitetural incremental, à medida que o software vai sendo desenvolvido ou evoluído? Ou eu tenho que prever tudo, do ponto de vista arquitetural, antes de codificar?
Arquiteto de software substitui especialista em infraestrutura? E DBA? E Scrum Master? Arquiteto precisa fazer algum nível de gestão? Se envolve no controle de riscos e impedimentos?

Comentários

Postagens mais visitadas deste blog

Brilho nos olhos

Um breve olhar do que já foi escrito

Requisitos conflitantes e dilemas no projeto de software