A quantidade adequada de documentação arquitetural para um software depende de análises de risco e de custo.
Veja também
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.
Veja também
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. 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.
Veja também
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.
Veja também
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.
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.
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.