Vamos falar sobre arquitetura ágil

Afinal é possível criar arquiteturas de negócio e sistemas robustos com agilidade? É possível entregar o dobro na metade do tempo também em arquitetura?

planejamento

Bom, primeiro vamos lembrar que agilidade é a conjunção entre eficiência, eficácia e qualidade. Então sendo assim, ser ágil não é ser rápido, afinal da pra entregar bugs em velocidades recordes, ou ainda entregar rápido e não entregar o que foi pedido, ou não menos importante, entregar o que a área pediu, sem bug, mas devagar.

É importante lembrar que não importa se você segue Kanban, Scrum, XP ou Lean, o que importa no fim é o bom e velho PDCA, e que um indicador de performance sozinho não tem valor algum.

Agora voltando sobre arquitetura de solução/tecnologia ágil:

Existem diversos frameworks de arquitetura, e há um grande esforço de empresas sérias tentando tornar algo que por natureza não é ágil, visto que é a área que tem um dos maiores potenciais de botar tudo a ganhar ou a perder na empresa, apenas com algumas decisões.

Mas fugindo um pouco do By The Book, não pretendo discorrer sobre metodologias, e sim sobre boas práticas, sobre tudo, de como decisões são valiosas nessa posição, e por serem valiosas não devem ser tomadas por critérios exclusivamente técnicos.

Primeiro vamos relembrar do livro Arquitetura Limpa , quando se trata de decisão de arquitetura:

“Resumindo, estabelecer limites nos ajudou a adiar decisões e, em última análise, nos fez economizar uma enorme quantidade de tempo e um monte de dores de cabeça. É isso que uma boa arquitetura deve fazer.” Martin, Robert C.. Arquitetura Limpa (Robert C. Martin).

Para mim é talvez a maior contribuição do Uncle Bob nesse livro sobre arquitetura ágil, quando ele sugere adiar decisões a partir do capitulo 17, onde fala sobre limites. Pois tomar decisões despende muito tempo de análise em geral, além disso, tomar decisões com muitas incertezas é antes de mais nada desperdício de tempo, além de gerar um custo muito alto no futuro, pois depois de tomada, voltar atrás pode até inviabilizar um projeto como um todo.

Digo isso pois vi grandes projetos fracassarem (nem irem pra produção) ou não pararem de pé, exigindo um alto custo de operação (correções e melhorias) justamente por que em algum momento tomaram uma decisão prematura.

E como diz o ditado: Cada decisão, uma renúncia.

Decisões sobre tecnologia, topologia, framework, banco de dados, nível de abstração, regra de negócio, etc., devem ser tomadas com base em dados, se falta dado falta maturidade e se falta maturidade até uma simples modelagem de banco de dados pode ser equivocada como decisão técnica.

Então voltando um pouco sobre arquitetura ágil. Arquitetura ágil é sobre saber quando tomar uma decisão, e sobre como essas decisões são tomadas.

Não adianta montar uma grande estrutura de CQRS, com uma nível alto de sofisticação com Kafka, é uma infra robusta, se estamos nas fase de validação ou reconhecimento do negócio ou conceito.

Quando se toma uma decisão de arquitetura leve em conta 3 grandes princípios orientadores:

• Nível de maturidade do processo de negócio a ser resolvido
• Nível de maturidade técnica da empresa e área
• Custo da solução

Nível de maturidade do processo de negócio a ser resolvido
O primeiro princípio é sobre o quanto você sabe e a área solicitante sabe sobre o negócio ou problema a ser resolvido.

Lembre-se sempre que nesse momento não basta experiência, é preciso ter clara a visão de passado, presente e futuro, pois as vezes o que você sabe sobre, pode não se aplicar nos próximos anos dada uma visão estratégica, ou ainda, pode ser uma experiência de inovação dentro de uma área conhecida, então nem tudo que você sabia, será crucial para esse novo projeto.

Nível de maturidade técnica da empresa e área
O segundo princípio é sobre conhecer sua engenharia, pois não adianta sair do monólito (nada contra e em breve devo escrever um artigo sobre) pro CQRS em uma empresa ou equipe que sempre deram manutenção a um monólito, essa mesma analogia serve para linguagem de programação ou tecnologia .

Pense em estratégias de evolução contínua, um bom exemplo é o trabalho que realizamos no time que trabalho, onde saímos de um monólito para diversos micro serviços que no fim otimizaram processos e reduziram custo, e tudo isso em 4 meses.

mas para isso ser possível levou um ano, onde no monólito quebramos os repositórios de dados, depois entendemos as unidades de negócio e domínio, e por fim comandos e executores, e por último pub/sub. (Quem ficou curioso fiz um relato sobre: https://www.linkedin.com/pulse/porqu%C3%AA-maxmilhas-utiliza-grpc-gustavo-da-silva-rodrigues/)

Nesse período focamos em entregar valor e nos preparar tecnicamente. Eu sabia que essa revolução não se daria do dia pra noite, e que se começasse com uma visão fechada sobre alguns pontos, tomaria decisões equivocadas e nunca chegaríamos lá.

Custo da solução
O último princípio orientador é sobre o custo da solução, e nessa hora, não é só projeção de custo de cloud vs tráfego. É também saber projetar o custo de manutenção dessa solução, seja pelo nível técnico exigido, como também da complexidade, e não menos óbvio o custo de tomar uma decisão ou adiá-la, e esse indicador é possível validando o Rói das entregas anteriores para justificar ou não a evolução dessa solução.

Agora para finalizar vamos refletir um pouco sobre sua visão de entrega ágil!

Você faz pequenas entregas e de forma recorrente?

Conseguir entregar valor de forma recorrente e com melhoria contínua, ou seja de forma faseada, e quando digo faseada não é sobre POC -> parte 1 -> parte 2 -> correção de bugs e produção, pois isso é uma cascata ainda que seja feito em forma de sprint.

Quando digo faseado é sobre PDCA, onde temos ciclos contínuos de entrega de valor, como por exemplo fazer uma experiência de processo de ponta a ponta primeiro, talvez até um monólito se for algo onde o grau de incerteza é muito grande. Depois coletar dados, sejam eles indicadores de receita, sistêmicos ou ainda de satisfação, e aí sim siga para próxima fase, talvez na próxima rodada você opte por um banco de dados X, que seja mais performático e mais barato, ou ainda, pense em quebrar a sua solução em mais uma aplicação especializada em um dos problemas que você resolveu, pois tem requisitos de performance e disponibilidade diferenciados, ou ainda encontre uma necessidade dê assincronismo entre esses sistemas, para reduzir o acoplamento e também o tempo médio de resolução de um dos problemas de negócio. É possível também que o projeto não gere receita, ou não seja exatamente o que pensaram na concepção da ideia inicial.

A principal contribuição que quero deixar é para você refletir se está ou não tomando boas decisões, afinal, como arquiteto sou responsável pelo que decido e também pelo que não decido, bem como sou responsável pelo sucesso ou fracasso da solução, portanto acho importante não apenas desenhar e especificar, mas também acompanhar os indicadores do projeto e também colaborar com o desenvolvimento do time envolvido no projeto, para tomar as decisões em conjunto no momento mais adequado.

Referências

• https://www.amazon.com.br/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164
• https://www.devmedia.com.br/como-conciliar-agilidade-e-arquitetura-de-software/33281
• http://www.metodoagil.com/metricas-ageis/#:~:text=M%C3%A9tricas%20%C3%81geis%20existem%20para%20gerar,mesmo%20que%20j%C3%A1%20esteja%20bom.
• https://www.linkedin.com/pulse/porqu%C3%AA-maxmilhas-utiliza-grpc-gustavo-da-silva-rodrigues/