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

т.е. можно декомпозировать модель по продуктам, а потом где-то в одном месте сводить в общего монстрика, например

идентификация объектов идет судя по всему по GUIDам - соответственно переименования и т.п. отрабатываются корректно

Интересно было бы узнать по каким данным этот график строился

занятно - зачем-то только при импорте имя модели приемника меняется по имени источника... странное решение

Это график скорее всего не точный, а просто нарисованный  для объяснения концепции.
Вот, почитайте в оригинале:
https://taxguru.in/finance/cost-quality.html
Там написано из чего могут состоять затраты на качество.

Благодарю!

Тут еще от критичности систем может модель меняться (об этом в статье не написано). Например, на атомной станции, думаю, Failure Costs недопустимы; а в другом месте они могут держаться на приемлемом уровне.

Коллеги, неужели никто не пользуется?

Сегодня третий обещают.

будем посмотреть...
видимо это после карантина поперло - как это не прискорбно

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

я бы предложил концептуальную верхнеуровнекую схему в виде стрелочек и квадратиков, отразить основные технологические блоки
пригладные процессы/сервисы отрисовать как пакет uml диаграмм (actiity, component, sequence)

на страрте тебе нужно показать две разных схемы:
- технологические зависимости, что с чем
- набор контекстов процессов и их границ (домены)

А если через один компонент проходит несколько процессов и взаимодействия происходят в виде оркестрации с большим количеством систем, при этом изобразить всё на 1 схеме невозможно?

Или технические зависимости - это не про обращения компонентов к компонентам?

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

А что, это правда актуальная проблема в жизни архитектора - как изобразить нечто, например шину данных?

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

Я просто не архитектор и не аналитик, я девопс, и я ни разу не сталкивался с проблемой как что-то нарисовать, только с проблемой понимания как устроено то, что я хочу изобразить, и какую информацию хочу получить/донести.