Он документириует основные бизнес-решения и т.п. Архитектор - архитектрные. Аналитик - по своей роли. Разработчики - тэважные технические моменты реализации.

Можно в одном документе разделами. Можно подстраницами/ветвями документов.

И не всегда все должны что-то документировать, если никаких особенностей решения с их стороны нет.

можно документировование в стадию анализа вставлять

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

Чтобы документировать - все участники документирования должны внутренне этот факт принять. Облегчить это им помогут установленные стандарты документирования. Шаблоны, примеры, помощь коллег.

Пару мастерклассов дать. Инструкцию коротенькую забацать. Парочку. Чтобы это казалось легким и приятным делом)

А не слишком много подробностей?

Design Review как практика?

в смысле слишком детальное описание?

Ага. И сильно пересекающееся с кодом, многое проще автоматически подтягивать, по идее.
Структуру БД - точно можно автоматом
Связь API с БД - тоже автоматом через диаграмму классов (если все нормально написано)

Но вообще эти данные не очень нужны в отрыве от кода.

Автоматом вытягивается существующая где-то структура. На каком-то конкретном стенде. А значит, ее изменение не контролируется ни постановщиком, ни тестировщиками (они по чему тестировать будут?).  В данном случае эти описания используются в том числе и как постановки. То бишь требования.
UI пишется параллельно API, база со скриптами тоже пишется параллельно. а если вытягивать из базы, то сначала нужно бд реализовать, потом апи, и только потом это может использовать прогер фронта.

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

А, если у вас логика в базе и это все делают разные люди, то может и имеет смысл.
Ну и у вас, похоже, системные аналитики (т.е. разработчики без кода)...

мне бы больше понравится вариант не генерировать описание по бд и апи, а генерировать апи и бд по описанию.

я помню, помню, что это признак проблем в проекте, ага, ага))))

Ну, вообще описание БД никому, кроме программистов не должно быть интересно. Причем программистов конкретного сервиса.
Если не так - то это часто что-то не так в архитектуре (или легаси...)

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

Design Review проверит правильность реализации только в текущий момент, но не даст информации почему год-два-три назад так было сделано, так как документальных следов не зафиксировано.
Документация она про предметную область, писать документацию “про код” вообще нет смысла.

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

Описание архитектуры система AS IS - это описание про код или про предметную область?