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 falharem. Observe, 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. Esta postagem é patrocinada por nossos parceiros
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.
