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.

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:

2 respostas

  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 um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

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:

Comunidades técnicas são sistemas complexos! Assim, não podem ser transformadas de maneira prescritiva. Não é razoável esperar que os comportamentos...
Mais cedo, uma de minhas parceiras de negócio entrou em contato comigo pedindo uma “ajudinha rápida”. Respondi para ela que...
Neste post, vamos escrever um Storage Provider para ASP.NET Core Identity, do zero, utilizando RavenDB como mecanismo de persistência. O...
Há anos eu conheço e aceito a ideia de que devemos buscar melhoria contínua. Sei que é natural e aceitável...
A publicação original desse post ocorreu em meu blog, em 2011, e gerou uma bela discussão. Infelizmente, essa publicação não...
Este exemplo é inspirado no livro do Ayende Se você deseja aprender RavenDB, recomendo que se inscreva no RavenDB bootcamp...
× Precisa de ajuda?