A grande dúvida é: Arquiteturas emergentes, é possível trabalhar com elas?

Primeiramente vamos definir arquitetura emergente. É consenso que uma arquitetura pode emergir de um sistema em desenvolvimento, em especial para os casos em o software é feito em diversas fases ou sprints, e que todos os requisitos não são conhecidos de antemão, mas são definidos ou descobertos ao longo do processo. O termo emergente pode ser tanto atribuído ao fato de que a arquitetura seja moldada em etapas, em função de requisitos que são incorporados por diversos critérios, bem como pelo próprio código que vai sendo construído e vai solidificando as características arquiteturais da aplicação, ainda que o projeto arquitetural nunca tenha sido escrito ou sequer planejado previamente.

Mas a arquitetura emergente é viável? Como tudo na vida, temos prós e contras:

Dentre os pontos positivos está a realização e entrada mais rápida do software, o time-to-market propriamente dito, sem ter que parar e abordar problemas que talvez o software nunca venha a ter. Temos alguns jargões para isso como “over-engineering” e “falácia da arquitetura dourada” como um fenômeno para tentar prever possíveis necessidades do sistema, usando soluções técnicas mais complexas e difíceis de manter, inclusive empregando recursos que estão nos trend-topics ou considerados hype. Logo, pensando em que “entregar é preciso” e que “menos é mais”, a arquitetura emergente parece viável, desde que mantida simples e sem modismos.

Para viabilizar uma arquitetura emergente, é essencial garantir a execução das boas práticas. A máxima antiquíssima de qualidade de software que preza a “alta coesão e o baixo acoplamento” continua valendo e não há previsão para sair de moda - algo que as engenheiras de software chamariam de pretinho básico, que não pode faltar no seu armário, ou na sua caixa de ferramentas.

No entanto, existem pontos de atenção quanto à arquitetura emergente. Se a arquitetura começou de forma significativamente inadequada, o ideal é repensá-la o quanto antes e não deixar a fundação ruir. Também tentar endereçar quaisquer cenários presentes ou futuros é bem arriscado e complica demais a solução técnica. É sabido que o software é ferramenta que apoia os negócios, e que o primeiro não pode ser um entrave ao segundo, mas a construção equivocada de um arquitetura pode gerar um transtorno na hora de evoluir o modelo de negócio. Nesses cenários, é importante dividir muito bem as responsabilidades, explicitar fronteiras, modularizando de forma inteligente. A correta granularidade é conseguida com experiência e não vem pronta de qualquer fórmula mágica ou mesmo de um livro de algum guru renomado - ainda que existam alguns que dão umas dicas muito boas.

Aqui cabe uma dica de ouro para quem cuida da arquitetura produto de software, ou algum outro software de longa duração: Tenha no máximo duas arquitetura vigentes. Faz muito bem para a saúde do software e de toda a equipe. No cenário em que temos a arquitetura “Old” e a arquitura “Current”, ao criarmos a arquitetura “New” temos dois caminhos: Migrar quem ainda está na Arquitetura “Old” para “Current” / “New” ou então migrar todo o “Current” para “New”.

Vale também destacar a questão da propriedade da arquitetura. Esta tem que ter dono, alguém que preze e que seja responsável por fazê-la evoluir. Além disso, um produto de software que precisa ser mantido por mais tempo requer uma atenção maior que outro com tempo de validade curto - é a analogia do “jardineiro de software”, que não só planta, mas mantém tudo em ordem, fazendo podas e incrementando o jardim.

Aplicar revisões arquiteturais mantém o vigor da solução técnica, além de uma ótima prática para ventilar novas ideias. Outro benefício da abordagem é o sentimento de propriedade compartilhado, que aumenta o engajamento do time na perseguição das suas metas. Ainda nessa direção, mas no sentido oposto, percebeu-se que perfis de product owners muito centralizadores fazem com que esse engajamento diminua e a arquitetura passa a acontecer de forma imposta, o que é perigoso para o software, porque pode não endereçar questões técnicas relevantes.

A validação arquitetural e as provas de conceito (PoCs) são muito importantes para confirmar ou refutar hipóteses formuladas ainda na prancheta. É importante saber argumentar com os patrocinadores do projeto sobre o valor de executar tais PoCs, uma vem que as mesmas tendem a mitigar riscos e embasam decisões fundamentais.

No final, a resposta que sempre cabe em discussões de software: “Depende”.

É importante ter disciplina para evoluir e revisar a arquitetura constantemente. E mesmo que o dê para fazer única e exclusivamente o que o cliente, vale a pena deixar o terreno preparado para uma “extra mile” de evolução seguinte, sem grandes planos para o futuro distante. Essa a tal da extra mile separa as crianças dos adultos no desenho arquitetural. Kent Beck não acredita nessa abordagem, mas deixar alguns pontos de extensão, aplicar patterns para reduzir acoplamento, clarear as fronteiras das responsabilidades, não faz mal a ninguém.

Afinal, Todo programador tem um pezinho na futurologia, não tem?