Arquitetos Arquitetando Arquiteturas

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. 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.

Compartilhe este insight:

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

In the first post of this series, I explained how to produce an inverted index using C#. In the second...
Em tempos onde tanta gente parece saber muito sobre tanta coisa, é interessante resgatar o pensamento da polêmica professora Marilena...
Mais uma vez, tive a honra de participar de um excelente bate-papo sobre microsserviços com o pessoal da Lambda 3....
In this post, I would like to share my first attempt to create a (still) elementary search library. The source...
Investimos consideravelmente no planejamento estratégico de nossas organizações. Entretanto, a execução não tem sido tarefa fácil. Em minha interpretação, boa...
Estamos, a maioria, em casa. Nossas rotinas não são as mesmas. Boa parte das atividades econômicas estão paradas. Aqueles que...
Masterclass

O Poder do Metamodelo para Profissionais Técnicos Avançarem

Nesta masterclass aberta ao público, vamos explorar como o Metamodelo para a Criação, desenvolvido por Elemar Júnior, pode ser uma ferramenta poderosa para alavancar sua carreira técnica em TI.

Crie sua conta

Preencha os dados para iniciar o seu cadastro no plano anual do Clube de Estudos:

Crie sua conta

Preencha os dados para iniciar o seu cadastro no plano mensal do Clube de Estudos:

× Precisa de ajuda?