A quantidade adequada de documentação arquitetural para um software depende de análises de risco e de custo.
Veja também
- Quais as diferenças entre Arquitetura e Design de Software?
- Por que utilizar bons modelos (diagramas) é importante para arquitetura de software?
- BLIKI: Arquitetura de Software
Entendemos que boa documentação arquitetural reduz os custos totais de um software. Ou seja, é mais barato adicionar features ou fazer ajustes quando há boa documentação arquitetural disponível. De forma análoga, entendemos que, com boa documentação, os riscos envolvidos são menores ou mitigados.
[tweet]A diferença entre as somas dos custos de criação e manutenção de um software com e sem documentação, deve superar os custos de elaboração e manutenção dessa documentação. Exceto, quando ela for fundamental para mitigar riscos.[/tweet] Em termos simples, toda documentação arquitetural que aumente os custos, sem ao menos mitigar riscos que o negócio reconhece, não se justifica e não deveria ser produzida ou mantida.
Não é incomum encontrarmos software, principalmente em empresas menores, sem qualquer tipo de documentação. Muitas vezes, as “dores” que geram a necessidade de consultoria são provenientes da falta de alinhamento do time sob aspectos básicos da arquitetura. Quase sempre, os problemas “se resolvem sozinhos” assim que se inicia o esforço para gerar documentação básica – ainda em nível alto.
Também não é incomum, principalmente em empresas grandes, encontrarmos documentação tão “abstrata” que não resolve dúvida alguma. Há tanta burocracia envolvida que toda informação relevante, quando há, fica escondida atrás de formatos e normas.
Embora muitos discordem, gerentes e patrocinadores de projetos são pessoas “racionais”. Por isso, dificilmente negariam investimentos em atividades que gerem benefícios percebidos. Cabe aos arquitetos a responsabilidade de demonstrar para o negócio a utilidade de produzir a documentação de qualidade.
É importante, antes da elaboração ou atualização de um documento, que seja estimado o esforço e, também, que sejam determinadas que atividades que vão ficar “mais baratas” em decorrência. Se isso não for possível, faremos melhor alocando recursos em outras frentes.
[tweet]Se você não consegue enumerar benefícios percebíveis de uma “boa prática” é porque, provavelmente, não tem condições de produzir algum.[/tweet]
Olá Elemar, tudo bem? Excelente ponto. Recentemente tenho estudado essa questão do papel do arquiteto e da arquitetura no contexto de times ágeis. Talvez por excessos do passado, a prática de design do sistema tenha sido rotulado de burocracia. Mas ao meu ver, um mínimo de planejamento e arquitetura é necessária para se evitar problemas futuros. Isso não significa que a documentação é mais importante que o software funcionando. Em times grandes com relativo turnover a ausência de uma documentação mínima pode levar ao caos.