No mês passado durante o ICSA 2019 em Hamburgo, Alemanha Eoin Woods, CTO da Endava realizou uma apresentação sobre como podemos democratizar a arquitetura de software.
Partindo de uma perspectiva histórica, Eoin descreveu como os sistemas de software evoluíram nas últimas três décadas. Nos anos 80, estávamos usando arquiteturas monolíticas, que evoluíram para monolitos distribuídos na década seguinte.
Com o advento da Internet, a conectividade prevaleceu na arquitetura de software nos anos 2000, o que levou à atual arquitetura de software em décadas, onde a Internet é o Sistema. A próxima etapa, com o aumento da adoção de tecnologias como IoT, será a vez das arquiteturas de software conectadas e inteligentes. A característica definidora nas arquiteturas modernas não é apenas definir uma arquitetura ou aderir a propriedades de qualidade, mas o mais importante será responder como a arquitetura pode reagir e evoluir para mudanças rápidas nos requisitos de negócios?
Historicamente, a arquitetura de software é concluída antes que a implementação seja finalizada ou até mesmo iniciada. Ela normalmente é definida por um pequeno grupo central de especialistas, cuja tarefa é de organizar grandes componentes arquiteturais com conexões relativamente estáticas entre eles. Esses especialistas tomam decisões importantes, como escolhas de tecnologia, estrutura e processos de código e gerenciamento das partes interessadas.
Contrastando esses fatos com a paisagem atual, agora temos uma arquitetura mais fluida em evolução. Isso aconteceu devido a ascensão do DevOps, dos microservices, da computação em nuvem e da programação ágil que contribuíram para ciclos de lançamento de produtos mais curtos e uma reação mais rápida às mudanças nos requisitos.
Equipes menores, que pensam e desenvolvem mais independentemente, evoluindo constantemente de maneira ágil, comunicam que nestes casos, há menos certeza e valor na tomada de decisões no início do ciclo de vida.
A arquitetura de software ainda é necessária porque as partes interessadas ainda estão por perto, precisamos decidir sobre compensações de design e temos várias preocupações transversais no software.
Na prática, o que acontece hoje em dia é ter equipes multifuncionais mais capacitadas e usar descrições mais leves para a arquitetura do que no passado. Diagramas de arquitetura difíceis de entender e evoluir agora são substituídos por diagramas leves como o C4 e os Logs de Decisões. As análises de código estático e de tempo de execução combinadas com documentação informal na forma de documentos em Wiki ou PowerPoint podem substituir documentos estáticos complexos. Ferramentas como SonarQube para análise de código estático ou o Jaeger, o Zipkin, a stack ELK, o Prometheus/Grafana e o NewRelic para serviços de monitoramento e rastreamento distribuídos em produção podem fornecer uma visão precisa e em tempo real do código e de sua arquitetura.
Em contraste com o atual status quo, Eoin está propondo uma nova abordagem. Em sua opinião, a arquitetura deve ser vista como mais uma habilidade do que um papel bem definido. Arquitetar "pouco e com frequência" de uma forma contínua de fluxo de decisões, em vez de diagramas arquiteturais "únicos", está no cerne dessa nova abordagem. O trabalho de arquitetura deve ser parte integrante de cada sprint e o mais próximo possível do código real. Um grupo de arquitetura inclusiva deve fornecer as decisões relevantes conforme forem necessárias, juntamente com testes práticos para validá-las.
De forma geral, o Agile e o Devops mudaram a maneira como trabalhamos na indústria de software, enquanto a computação em nuvem e os containeres de software mudaram a forma como implantamos software.
Deste ponto de vista, um arquiteto é um líder e consultor confiável em uma equipe. Essa nova perspectiva pode levar à arquitetura de software adequada para a atual e futura era dos sistemas de software conectados inteligentes.