Em todos esses anos tenho recebido relatos de desenvolvedores projetando sistemas com belas arquiteturas. Muitos deles tem levantado um bocado de questões sobre a necessidade de um “arquiteto”.

Nunca é demais lembrar – quando me refiro a arquitetura, falo dos componentes de uma aplicação, das responsabilidades de cada componente, e seus relacionamentos.

ARQUITETURA = COMPONENTES + SUAS RESPONSABILIDADES + SEUS RELACIONAMENTOS

Muita da resistência ao papel do arquiteto de software ocorre por causa da abordagem burocrática, pomposa e desconectada, cheia de diagramas e pouco código adotada por alguns. Felizmente, isso tem pouco haver com a arquitetura que defendo.

Papéis no time, processos de trabalho e artefatos podem ser analisados separadamente. Vejamos:

  • Papel/cargo: Arquiteto – Muitas organizações possuem um papel (ou mesmo um cargo) dedicado ao arquiteto de software. Nos descritivos, encontramos tanto gente desconectada do desenvolvimento quanto gente que coloca a mão na massa – acredite, tenho visto os dois modelos funcionarem e falharemObserve, entretanto, que quaisquer destes perfis não tem relação com o processo que será seguido.
  • Processo: Elaborar Arquiteturas – Considere que não há código quando começamos um projeto de software e há um software rodando no seu final – o que existe entre o primeiro momento e o segundo é um time executando diversas atividades. Algumas pessoas gostam de pensar o sistema todo (BDUF) antes de escrever qualquer código. Outros, eu inclusive, preferem deixar a arquitetura emergir durante o desenvolvimento. De qualquer forma,  perceba que com o software concluído é impossível determinar qual modelo foi seguido.
  • Artefato: Arquitetura – Ao observar um software, você consegue inferir um bocado de características da arquitetura (camadas, modelo de colaboração, persistência) – todo software possui uma arquitetura, mesmo que ela tenha emergido de forma não coordenada.

Vamos então responder algumas questões fundamentais.

Precisamos de alguém com o papel de arquiteto em nosso time?

Depende! Qual é o tamanho do projeto? Qual é a complexidade envolvida? Mais importante, quais são os riscos? Quanto maior o projeto, complexidade ou riscos, mais necessária será a figura do arquiteto. Alguém que tenha experiência nesse tipo de projetos e que já colecione algumas cicatrizes seria uma boa escolha.

Como deveria ser a atuação do arquiteto?

Pessoalmente, eu entendo que o arquiteto deve se portar como um orquestrador. Alguém que consiga ouvir todas as partes envolvidas com o projeto (especialistas de domínio, desenvolvedores, pessoal do negócio) e consolidar decisões. Cabe ao arquiteto a responsabilidade de definir claramente a estratégia do projeto e assegurar que ela estará sendo respeitada.

ESTRATÉGIA = PADRÃO COERENTE PARA TOMADA DE DECISÕES.

E os tais diagramas? Eles são mesmo necessários?

Sim! Eles são. Os diagramas servem para comunicar as decisões de arquitetura para todas as partes envolvidas.

O código não seria o suficiente?

Não. Eu penso que não são suficientes porque nem todas as pessoas envolvidas no projeto sabem ler o código. A arquitetura não serve apenas para o time técnico. Ela é uma ferramenta de comunicação. Além disso, alguns diagramas surgem antes de que qualquer código tenha sido produzido. Diagramas permitem expressar a arquitetura em diferentes níveis de detalhe.

Não temos ninguém com o cargo de arquiteto. Como proceder?

Nesses casos, para cada projeto, é bom determinar alguém – com alguma experiência – para fazer a tal “orquestração”. Há quem defenda arquitetura como uma responsabilidade compartilhada. Eu, entretanto, penso que aquilo que é responsabilidade de todos, não é de ninguém.

Se você tem mais perguntas, deixe-as aqui nos comentários. Se não concorda com algum ponto, deixe-me saber sua opinião.

Este post tem 2 comentários

  1. Olá, Elemar!

    Em se tratando do ponto “o arquiteto deve se portar como um orquestrador”, como ficaria a interação dele com um Product Owner (ou algo similar) em um projeto? Já teve experiência do tipo? Conte-nos aí!

    Abs!

  2. Olá Elemar,
    Show de bola o post, eu só tenho uma dúvida: No caso de todos os software ter uma arquitetura mesmo que seja de forma não coordenada, você acha que ainda assim o software pode ter sucesso pleno(ex: Ser um software escalável e ter uma manutenção eficaz)? Ou isso é relativo? Me corrija se eu estiver me confundindo ou falando besteira :D…
    Abraços!

Deixe uma resposta