Mantenere aggiornati i diagrammi di architettura logica e fisica

In qualsiasi progetto di sviluppo software che coinvolge sistemi distribuiti con più sviluppatori, avere diagrammi di architettura logica e fisica è la migliore pratica, ma nella mia esperienza questi diagrammi iniziano sempre ad essere ben mantenuti all'inizio di un progetto ma non vengono aggiornati quando il progetto viene rilasciato e iniziano le fasi di manutenzione.

Per progetti complessi con molti processi distribuiti, i diagrammi tendono a diventare obsoleti o inaccurati molto rapidamente anche prima del rilascio iniziale poiché nessuno ha tutte le conoscenze.

Alla luce di ciò, desidero porre le seguenti domande alla comunità:

1. Quanto sono importanti avere diagrammi di architettura logica e fisica accurati e aggiornati?
2. Ci sono strumenti e processi che possono aiutarti a tenerli aggiornati?
3. Chi dovrebbe essere responsabile di tenerli aggiornati? In che modo possono contribuire gli amministratori di sistema, gli sviluppatori e i team di controllo qualità?

Vivo nel mondo reale con vincoli temporali e problemi di risorse, quindi capisco perché la maggior parte della documentazione software sia ignorata o non aggiornata, ma anche in quelle condizioni insisto assolutamente sul fatto che i diagrammi del database vengano creati e mantenuti aggiornati. Se non è un normale modello relazionale ed è costituito da entità con documenti, coppie chiave-valore o strutture JSON / XML, è necessario creare e mantenere anche un modello a oggetti di tali elementi. Se tutto il resto fallisce negli sforzi di documentazione di un progetto, almeno uno schema di database e / o modelli di oggetti consentiranno di lavorare all'indietro verso il front-end per capire cosa sta succedendo.

Esistono numerose opzioni per la creazione e la gestione di documenti software, ma uno dei miei preferiti è Enterprise Architect. È completo e i legami insieme usano casi, diagrammi di sequenza, diagrammi di classe e altri.

Per quanto riguarda chi è responsabile di questo, lo considero uno sforzo di squadra. Poche persone si divertono a fondo, ma deve essere fatto. L'architetto o il responsabile tecnico di un progetto dovrebbe in definitiva essere responsabile di esso, delegando i compiti in modo appropriato.