Mantendo os diagramas de arquitetura lógica e física atualizados

Em qualquer projeto de desenvolvimento de software que envolva sistemas distribuídos com vários desenvolvedores, ter diagramas de arquitetura lógica e física é uma prática recomendada, mas, na minha experiência, esses diagramas sempre começam a ser bem mantidos no início de um projeto, mas não são atualizados à medida que o projeto é lançado. e as fases de manutenção entram em ação.

Para projetos complexos com muitos processos distribuídos, os diagramas tendem a ficar desatualizados ou imprecisos muito rapidamente, mesmo antes do lançamento inicial, pois ninguém tem todo o conhecimento.

Dado esse histórico, quero fazer as seguintes perguntas à comunidade:

1. Qual a importância de ter diagramas de arquitetura lógica e física precisos e atualizados?
2. Existem ferramentas e processos que podem ajudar a mantê-los atualizados?
3. Quem deve ser responsável por mantê-los atualizados? Como os administradores de sistemas, desenvolvedores e equipes de controle de qualidade podem contribuir?

Como vivo no mundo real com restrições de tempo e problemas de recursos, entendo por que a maioria da documentação de software é ignorada ou desatualizada, mas mesmo sob essas condições, insisto absolutamente em que os diagramas de banco de dados sejam criados e mantidos atualizados. Se não for um modelo relacional usual e consistir em entidades com documentos, pares de valores-chave ou estruturas JSON / XML, um modelo de objeto desses itens também deverá ser criado e mantido. Se tudo mais falhar nos esforços de documentação de um projeto, pelo menos um diagrama de banco de dados e / ou modelo (s) de objeto permitirá que você trabalhe de volta ao front-end para descobrir o que está acontecendo.

Existem inúmeras opções para criar e manter documentos de software, mas um dos meus favoritos é o Enterprise Architect. É abrangente e vincula casos de uso, diagramas de seqüência, diagramas de classe e outros.

Quanto a quem é responsável por isso, considero um esforço de equipe. Poucas pessoas gostam muito de fazê-lo, mas isso deve ser feito. O arquiteto ou líder técnico de um projeto deve, em última instância, ser responsável por ele, delegando tarefas de forma adequada.