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

Посмотрите стримы Дениса Котова, где он разбирает ошибки при рисовании BPMN процессов. Потом промойте глаза и возвращайтесь.

Вот эти? https://www.youtube.com/playlist?list=PLJHWAyPXCgb-3hL2LhC_7inFGr_V-2iny

видимот вот это https://www.youtube.com/watch?v=_Cx_4b5otrY

видимот вот это https://www.youtube.com/watch?v=_Cx_4b5otrY

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

Коллеги, подскажите пожалуйста, как лучше всего будет визуализировать архитектуру существующей шины? Возможно у кого-то будут под рукой примеры или ссылки, где можно посмотреть, с чего начинать.
Требуется для того, чтобы сделать систему прозрачной, т.к. компоненты не описаны, сидят в головах людей. Сложно онбордить новых сотрудников. Со стороны непонятно, какой компонент что делает, как через них происходят процессы. Сложнее становится ими управлять и дорабатывать. Сейчас сервисы не выйдет назвать микросервисами, т.к. они представляют собой сервисы, содержащие в себе логику для выполнения манипуляций над монолитом.
Пока у меня был план создать описание карту компонентов с описанием (основные функции, на чём сделаны, у кого экспертиза, ссылки на техрешения), а также прописать процессы, через них проходящие (но вот с последним сложнее). Архимейт наверное не выйдет использовать, т.к. есть AE, но он доступен крайне малому кругу людей, а схемы нужны разработчикам, аналитикам, топам, а порой даже специалистам прикладных областей.
Выходить за рамки шины и описывать всю систему сейчас смысла нет, т.к. нужно начинать с малого. Может как только опишу шину, пойду дальше. Там видно будет. =)
Буду рад любому ответу. =)

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

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

Пока не покажешь людям на примере, как это работает и что даёт, никто не будет делать что-то новое

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