Если система для вас - чёрный ящик и вас не просят описать архитектуру и логику работы компонентов, то можно ограничиться  bpmn + требования к системе в целом, описывая, что хотите в неё отправить и что получить. В таком случае, как она работает, описывать не нужно.

Иначе, если от вас хотят документации про начинку этих 10 модулей, базы данных и api, тогда:

Надо определиться с данными, где они лежат, какие у них связи, если они есть. Для  этого можно создать uml entity digram. Если есть сильное изменение данных, то стоит описать ERDg AS IS &TO BE.

Далее надо создать components diagram для системы на высоком уровне абстракции, указав кто к кому через что обращается (где rest, где sql, apex etc).

Далее заняться описанием в формате sequence diagram или описывать алгоритм в виде текста.

При увеличении сложности переводить алгоритмы в сабпроцессы и описывать под собственными отдельными пунктами.

Существует практика гибридного BPMN, где SW - это системы. Но у него бывают проблемы с масштабированием, в него сложно и долго вносить изменения.
Со временем от гибридов я полностью отказался, т.к. почти всё в работе систем можно доходчиво описать за счёт uml.

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

Отдельное слово за ветвящиеся алгоритмы. Если такие есть, то их проще выделять в отдельный пункт и описывать в bpmn, т.к. uml sequence diagram для этого подходит слабо.

Похоже я умею общаться только стенами  текста =\

По моему в вас два типа architect  и tw живет.😂🤣, конечно сделать это все круто... но обычно за это не платят аналитику на проекте.

Моя практика показала что гибрид bpmn, лютая гадость, которую сдавали в прод, вскрывалась гадость на dev/test, ресурсов менять не было, но может у вас было с этим получше.

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

Схемы пишутся в первую очередь для аналитика-проектировщика, чтобы понять, как все это сейчас работает

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

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

С опытом схема компонентов - это лист и 5-10 минут.
Erd - 2 часа.

Антипаттерн. Вы собираете встречу на 12 технических специалистов без схемы, рассказываете им про свою реализацию и они не зададут ни одного вопроса.

точно архитектор живет

вам за это платят?

Если есть ерд, то вас завалят вопросами данных их оунеры. А если есть компонентная, то уже вопросы будут у разработки и девопс.

в целом да, с другой стороны, данные должны быть уже у других специалистов...

Вопрос в том, что от человека требуют и какие у него должностные.

Для этого в сообщении есть условие 'если'

Каких? Архитекторы - единичны. Никто не будет ради юзкейса подключать арха.
Кто еще? Тимлиды? Они часто не парятся за схемы вообще.
Разрабы тем более.
Девопсы - да, но уже постфактум.

Вы как такую встречу будете фасилитировать?

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