Definitivamente, não acreditamos em abordagens onde a arquitetura de um software deve ser completamente pensada no início do projeto (big design up front). No início, é o momento que temos menos conhecimento sobre o domínio do problema e mais incertezas sobre os aspectos de negócio envolvidos. Portanto, tentar antecipar todas as decisões neste momento pode ser um exercício de mera especulação. Por essa razão, entendemos que a arquitetura deve emergir ao longo do projeto.

Todavia, arquitetura emergente não pode ser justificativa para uma arquitetura Frankstein, onde suas partes evoluem de maneira incoerente e desorganizada, com pouco ou nenhum planejamento. Pelo contrário, apesar da arquitetura ser formada de maneira evolutiva, ela não deve ser construída ao acaso, mas sim como exercício intencional dos desenvolvedores e arquitetos. Não podemos usar a ideia de arquitetura evolutiva para a não-prática de arquitetura.

Há método para a elaboração da arquitetura evolutiva e ele se afasta bastante de tentativa-e-erro implementada de forma ingênua. Há, por exemplo, as fitness functions que implicam em tentar explicitar, no início do projeto, o que é importante e implementar técnicas e mecanismos para se certificar que esses aspectos estão sendo respeitados.

Uma arquitetura intencional implica em um “just enough” up front design. Onde o “just enough” pode ser difícil de quantificar e variar de projeto para projeto. Porém, de maneira mínima, deve comunicar uma visão da big picture do projeto, suas fronteiras, os próximos passos do time e alinhamento entre equipes, além de uma boa ideia sobre as tecnologias que se planeja utilizar. Quanto maior o risco do projeto, maior a necessidade de “antecipar verdades”. [tweet]Arquitetura evolutiva não é arquitetura que evolui de forma desorganizada.[/tweet]

Entendemos que a arquitetura deve traduzir, de maneira consistente, os requisitos funcionais, não-funcionais, inversos, restrições e princípios da aplicação. [tweet]Apesar de não termos no início do projeto todas informações que gostaríamos para tomada de decisão, é fundamental a reflexão sobre esses aspectos para evitar redesenhos excessivos de coisas que poderiam ser antecipadas.[/tweet]

Embora concordemos que devemos postergar as decisões para o último momento responsável, entendemos que precisamos, sempre, ter condições de tomar uma decisão se ela for necessária.

Portanto, embora valorizemos a capacidade de adaptar a mudanças mais que seguir a um plano definido, não acreditamos que o caminho seja não ter plano nenhum. Consideramos responsável equilibrar planejamento e execução de maneira constante e defendemos a elaboração intencional da arquitetura do software. E embora ratifiquemos que interações entre pessoas são mais importantes que processos e ferramentas, não nos furtamos de utilizar diagramas e modelos para representar e comunicar abstrações para garantir alinhamento e coesão nos integrantes do time.

[tweet]Não devemos confundir arquitetura evolutiva com arquitetura irresponsável.[/tweet]