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

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

Я где-то читал про компанию, которая при найме больше ценила PMов, которыеимели в портфеле не только успешные, но и провальные пректы. За одного битого...

Возможно с арихитекторами так же)

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

где-то на просторах FB спорили из кого должен вырасти системный архитектор - из BA или разраба. В какой-то момент решили, что если бы не было SA (на прошлой работе так и было), то проектированием архитектуры решения занимались бы бизнес-системный аналитик и разраб (на прошлой работе так и было). Потому что аналитик понимает контекст и потребность, разраб знает как реализовать потребность. Я в основном бизнес-системный аналитик с небольшим опытом разработки (БД) и системного администрирования и сейчас, участвуя в проектировании решения, сейчас  понимаю, что очень не хватает хорошего бэкграунда разработки.

А не понятно, что такое "провальная" архитектура.

Фредерик Брукс в своей книге "Мифический человеко-месяц" прямо говорит "планируйте выбросить первую версию - вам все равно придется это сделать" https://econ.wikireading.ru/78632.

Стив Макконнелл в совей книге "Совершенный код" называет проетирование ПО "грязной проблемой", понимая под этим, что "проблему нужно «решить» один раз, чтобы получить ее ясное определение, а затем еще раз для создания работоспособного решения" https://medium.com/@a8h333/%D0%B3%D1%80%D1%8F%D0%B7%D0%BD%D1%8B%D0%B5-%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B-d5264a9893a8.

Мартин Фаулер опубликовал статью "Сперва монолит": https://martinfowler.com/bliki/MonolithFirst.html .

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

Ну, архитектура - это не артефакт, а процесс.

Вот да)

Я немного шутила про Главного. Конечно, я понимаю, что ошибка - это возможность увидеть еще одно, возможно верное решение. За  ссылки и выдержки спасибо )

А потом идёт "эффект второй версии"

Это как?

День добрый! Чтобы описать RPC для системы из нескольких узлов лучше Modelio или Papyrus?

А не Swagger?
Т.е. что значит "описать"?

Нарисовать, чтобы был артефакт, который можно предметно обсуждать с коллегами

Важно показать состояние полей в RPC, какое поле как меняется при форварде запроса, что к чему относится, какое состояние приходится хранить узлам

И конечно же, как узлы между собой связаны (логически)

Хотя видимо всё же lucidcharts. Думал десктопное что-то попробовать, но papyrus не запустился (привет, eclipse), а в modelio какой-то мрак :)

Тогда это похоже на sequence diagram с комментариями. Это draw.io