Обновление диаграмм логической и физической архитектуры

В любом проекте по разработке программного обеспечения, в котором участвуют распределенные системы с несколькими разработчиками, лучше всего иметь диаграммы логической и физической архитектуры, но, по моему опыту, эти диаграммы всегда начинают хорошо поддерживаться в начале проекта, но не обновляются по мере выпуска проекта и фазы обслуживания начинают.

Для сложных проектов с большим количеством распределенных процессов диаграммы, как правило, очень быстро устаревают или становятся неточными даже до первоначального выпуска, поскольку никто не обладает всеми знаниями.

Исходя из этого, я хочу задать сообществу следующие вопросы:

1. Насколько важно иметь точные и современные диаграммы логической и физической архитектуры?
2. Существуют ли какие-либо инструменты и процессы, которые могут помочь поддерживать их в актуальном состоянии?
3. Кто должен отвечать за их актуальность? Какой вклад могут внести системные администраторы, разработчики и команды QA?

Я живу в реальном мире с нехваткой времени и проблемами с ресурсами, поэтому я понимаю, почему большая часть документации по программному обеспечению либо игнорируется, либо устарела, но даже в этих условиях я абсолютно настаиваю на том, чтобы диаграммы баз данных создавались и поддерживали актуальность. Если это не обычная реляционная модель и состоит из сущностей с документами, парами ключ-значение или структурами JSON / XML, то следует также создать и поддерживать объектную модель этих элементов. Если все остальное терпит неудачу в усилиях по документированию проекта, по крайней мере, схема базы данных и / или объектная модель (ы) позволят работать обратно к внешнему интерфейсу, чтобы выяснить, что происходит.

Существует множество вариантов создания и поддержки программных документов, но одним из моих любимых является Enterprise Architect. Он всеобъемлющий и связывает воедино случаи, диаграммы последовательностей, диаграммы классов и другие.

Что касается того, кто несет ответственность за это, я считаю это командным усилием. Мало кому это нравится, но это нужно делать. Архитектор или технический руководитель проекта должны в конечном итоге отвечать за него, надлежащим образом делегируя задачи.