Evitando os extremos
Mensurar o esforço que deve ser dedicado à arquitetura de um sistema é uma questão difícil de responder até mesmo para profissionais experientes. Uma série de fatores podem causar divergência na visão dos arquitetos.
Tomando pelos extremos podemos ter duas visões divergentes sobre esse tema. De um lado a ideia de não dedicar qualquer esforço específico na elaboração da arquitetura, nesta perspectiva partem de um modelo de referência e acreditam que ele será suficiente para o desenvolvimento do sistema. Do outro lado a ideia de dedicar um alto esforço, logo no início, na arquitetura de um projeto, levantando minuciosamente cada detalhe antes mesmo de iniciar o desenvolvimento de código. A crença é que esses detalhes serão difíceis e caros de mudar posteriormente, portanto vale o investimento em tentar antecipá-los.
Na nossa experiência, nenhum dos extremos é a resposta para essa questão, e cada projeto deve ser tratado de acordo com suas particularidades. Não dedicar nenhum esforço para a arquitetura e esperar que ela evolua naturalmente durante o desenvolvimento é um otimismo irresponsável! A chance de se entregar um sistema que possua uma estrutura simplória ou desnecessariamente complexa para a necessidade real do negócio é altíssima. Por outro lado, despender um alto esforço para a arquitetura tentando suportar todos os cenários possíveis é um processo caro, especulativo e que tem grandes chances de se traduzir em desperdício de recursos.
Portanto, como compreender se estamos dedicando esforço adequado para as questões arquiteturais?
Todo sistema possui uma arquitetura
Antes de mais nada, é necessário entender que todo sistema possui uma arquitetura, seja ela planejada ou não, e alguns critérios são bastante úteis para identificar se o esforço está mal balanceado.
Esforço insatisfatório
- Os objetivos do negócio, as restrições e os atributos de qualidade não são explícitos
- Não há entendimento da big picture e consequentemente, percepção das fronteiras do domínio e integração com outros sistemas
- É difícil comunicar a visão geral do sistema para outras pessoas
- Não é claro para os membros do time o que precisa ser feito
- Não há clareza sobre os riscos das decisões técnicas tomadas
Esforço excessivo
- Longa documentação com excesso de informações (
que ninguém lê) - Design detalhado demais com muitos níveis de abstração
- Exemplos de código ou pseudo código na documentação
- Momentos de paralisia por análise com indefinições que levam semanas para serem resolvidas
- Lentidão para iniciar o desenvolvimento do projeto
Quanto esforço é suficiente?
A avaliação do esforço adequado para dedicar à arquitetura varia de projeto para projeto e é necessário levar em consideração ao menos a complexidade do sistema, risco envolvido, tamanho da solução e expectativa de escala. Entretanto, para a grande parte dos sistemas, seguir algumas práticas auxiliam no atingimento dos objetivos arquiteturais, demandando assim, apenas o suficiente de esforço na elaboração da arquitetura.
No intuito de ter uma abordagem enxuta vale destacar que as tarefas mais relevantes e que na maioria das vezes são ignoradas, são o levantamento e a comunicação dos objetivos de negócio, restrições e atributos de qualidade. Este deve ser o exercício número 1, no qual será o guia para as decisões de design.
Documentação de objetivos arquiteturais
Após o levantamento dos objetivos arquiteturais, é importante pensar em como comunicar e documentar essas informações. Uma técnica que recomendamos, por demandar pouco esforço, é o Architecture Haiku, proposta por George Fairbanks. A ideia é fazer uma descrição concisa da arquitetura em uma página.
Fairbanks recomenda a elaboração do documento da seguinte forma:
- Breve resumo da solução geral
- Uma lista de restrições técnicas importantes
- Resumo de alto nível dos principais requisitos funcionais
- Lista priorizada de atributos de qualidade
- Breve explicação das decisões de design, incluindo justificativa e compensações
- Lista de estilos e padrões arquitetônicos usados
- Apenas diagramas que adicionem significado além das informações que já estão na página
Elaboração e documentação de diagramas
Em relação ao design de diagramas, adotamos a visão do Simon Brown:
- Entenda o contexto, escopo e as principais decisões de design (tecnologia, modularidade, etc.) do que está sendo construído. Identifique os elementos estruturais importantes e como eles se relacionam, baseados nos motivadores que demandam o design. Isto pode ser alcançado ao elaborar o design e a decomposição através do desenho de diagramas C4 no nível de container para arquitetura de serviços ou no nível de componentes para sistemas monolíticos
- Crie uma visão e comunique para o time responsável pelo projeto e seus stakeholders
- Identifique e mitigue os riscos que possuem maior criticidade. Esteja confortável com os riscos associados à construção do software
Suportando a evolução da arquitetura
É natural que os objetivos arquiteturais mudem ao longo do tempo, e que em alguns cenários a atual arquitetura não suporte mais a demanda corrente. Neste cenário, é possível que surja a necessidade de alteração do design, e para que fique claro para os stakeholders o porquê da alteração e suas consequências, é importante validar a alteração proposta, comunicar e documentar.
Em uma arquitetura que demanda evoluções incrementais, é essencial validar se as restrições e os atributos de qualidade estão sendo respeitados à medida que ocorrem mudanças. A utilização de fitness functions auxilia na verificação se os objetivos estão sendo alcançados, através de avaliações que podem ser feitas com testes automatizados ou de forma manual. Recomendamos a leitura do livro Building Evolutionary Architecture que aprofunda nesse assunto.
Registro das decisões arquiteturais relevantes
Em relação às várias decisões tomadas durante o projeto, recomendamos documentá-las como ADRs (Architectural Decision Records). Esta prática consiste em descrever a alteração da arquitetura em um texto curto e mantido no próprio repositório do projeto. Michael Nygard (autor do livro Release It!) sugere que o documento seja composto por um título, contexto, decisão, status e consequência. Este texto escrito pelo próprio Nygard contém mais detalhes sobre essa prática.
Não existe receita de bolo
Demandar o esforço adequado para o desenvolvimento da arquitetura não é tarefa simples e requer o envolvimento de profissionais experientes. Faz parte do papel do arquiteto encontrar um ponto de equilíbrio ao buscar o sucesso de um sistema. Lembrando que podemos considerar que um projeto alcançou o sucesso se conseguirmos atingir os objetivos de negócio, respeitando as restrições e atributos de qualidade, com o menor custo.
Em relação à documentação, recomendamos o segundo capítulo do manual do arquiteto de software , onde esse tema foi discutido com profundidade, apresentando as vantagens e algumas das desmistificações relacionadas à essa prática.