Quando analiso a causa raiz de incidentes em produção, tipicamente estão relacionados a uma característica de Arquitetura, como disponibilidade, confiabilidade, segurança, performance ou escalabilidade, para citar os mais comuns.

E quando pergunto aos times se consideram importantes estas características de Arquitetura, todos respondem “Sim, com certeza!”. Ironicamente, quando avalio o backlog destes mesmos times, as histórias de Arquitetura simplesmente não existem.

Essa distância entre o que os times julgam importante e aquilo que de fato praticam é um buraco mais comum do que se imagina. Os times, de modo geral, perderam a capacidade de praticar Arquitetura no dia a dia de forma estruturada.

Há alguns dias durante uma conversa com um novo cliente ele comentou que a frequência e a gravidade dos incidentes em produção chegou a um volume tão grande que eles decidiram interromper o desenvolvimento de novas funcionalidades. Todo o esforço dos times está direcionado para manter a produção de pé.

Não é a primeira vez que tomo conhecimento de medidas como essa. Outra movimentação desesperada comum é estabelecer um processo de gestão de mudanças, e em casos onde esse processo já existe, torná-lo mais “rigoroso” costuma ser o caminho apontado como solução.

Sem atacar a causa do problema, um processo mais rigoroso vai no máximo desacelerar ou diminuir a frequência dos problemas, mas faz muito pouco para evitá-los.

Não por incompetência ou má fé. Um processo como esse simplesmente não é capaz de avaliar a cada implantação como estão suas características de arquitetura que causam incidentes em produção, como disponibilidade, escalabilidade, performance, segurança ou confiabilidade.

Quando uma implementação chega à gestão de mudança já é tarde demais. E acredite, os times rapidamente se tornam especialistas em mapear os critérios da gestão de mudança e adaptar suas solicitações para “passar na prova”.

É preciso compreensão e coragem da liderança para encarar o problema com a relevância que ele merece, de forma estrutural, revisitando práticas, habilidades, incentivos, topologia dos times e o stack tecnológico.

Não tem milagre, mas também não tem segredo. As boas práticas de Engenharia e Arquitetura de software estão à disposição de todos. Mas é preciso adotá-las e praticá-las de forma efetiva. A evolução e a maturidade são consequências inevitáveis.

Existem frameworks que podem estruturar e acelerar esse reposicionamento.

O AARM é um deles. O framework é público e gratuito. Se o Software Engineering Institute conseguiu se beneficiar com o AARM, tenho certeza de que o seu time também pode.

Publicamos templates, guias e apresentações de referência sobre o AARM (pra ajudar você a compartilhar a ideia com os seus colegas). E se precisar de ajuda pra começar a praticar, a Elegant Garden oferece um pacote de 4 semanas chamado AARM Sprint. Assim você começa a praticar o AARM com quem criou o framework e tira todas as eventuais dúvidas durante o processo.

Acesse o novo hub de conteúdo do AARM: https://elegantgarden.software/aarm

Acredite, sem uma mudança fundamental na forma de tratar esse problema, a situação não vai melhorar. Sua carreira agradece.