Quanto de esforço se deve dedicar à arquitetura de software? Apenas o suficiente.

Raphael Castilho

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.

Compartilhe este insight:

Comentários

Participe deixando seu comentário sobre este artigo a seguir:

Subscribe
Notify of
guest
0 Comentários
Inline Feedbacks
View all comments

AUTOR

Raphael Castilho
Desenvolvedor especialista em .NET com experiência em aplicações corporativas de larga escala

SOLUÇÕES EXIMIACO

Arquitetura de Software

Evolução e modernização de aplicações para suportar mudanças de escala.

NOVOS HORIZONTES PARA O SEU NEGÓCIO

Nosso time está preparado para superar junto com você grandes desafios tecnológicos.

Entre em contato e vamos juntos utilizar a tecnologia do jeito certo para gerar mais resultados.

Insights EximiaCo

Confira os conteúdos de negócios e tecnologia desenvolvidos pelos nossos consultores:

Arquitetura de Software

Lições sobre autorização que o Open Banking ensina para qualquer arquitetura

Arquiteto de Software com experiência executiva em Tecnologia
Arquitetura de Dados

LGPD: Protegendo as informações no Banco de Dados

Especialista em performance de Bancos de Dados de larga escala
Arquitetura de Dados

SQL Injection: Por que se preocupar?

Especialista em performance de Bancos de Dados de larga escala

Acesse nossos canais

Simplificamos, potencializamos e aceleramos resultados usando a tecnologia do jeito certo

EximiaCo 2022 – Todos os direitos reservados

0
Queremos saber a sua opinião, deixe seu comentáriox
()
x

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

O seu insight foi excluído com sucesso!

O seu insight foi excluído e não está mais disponível.

O seu insight foi salvo com sucesso!

Ele está na fila de espera, aguardando ser revisado para ter sua publicação programada.

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse nessa solução

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse neste serviço

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

× Precisa de ajuda?