хорошо когда есть какие то компоненты

А что мешает сесть, на основе предметной области их самому выделить и уточнять в процессе бесед?

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

А потом влипаешь в транзакционный подпроцесс и фините ля комедия, рисуешь большую компенсанаторную процедуру и собеседники начинают плакать крокодильими слезами.

Шучу конечно. Но все это сильно вендор специфично

Твоя польза - гэп-анализ выделенных тобой компонентов, польза собеседника - он начинает структуровать свои хотелки. Заодно, на блок-схемах явно указываешь границы сценария и промежуточное ПО (MQ, kafka, etc) для того, чтобы явно отделить синхронные операции от асинхронных

Я все это делаю в Draw.io. Никакого вендора. Правда приходится потом изменения сквозняком по схемам руками переносить

Собеседнику от бизнеса или бизнес-аналитику эта процедура ничего не даст. Можно нарисовать упрощённо и написать примечание. Потом, с технической командой, это все разобрать "до гаек и болтов", и вот там уже подумать о всей поднаготной реализации

Тут же спрашивают о методологии / технологии. Как смоделировать и запустить. Понятно что можно рисовать и карандашами на бумажке. Но это к технологии / методологии мало относится. Я говорю о системах где аналитик/технолог рисует РАБОЧИЙ алгоритм. Который реально проигрывается системой. Таких не мало. В тиньке например камунда, где то аксапта с динамиксом, кто то на сапе.

Мдя... любой bpm берете, почти во всех есть движение токена, да только они для уровня полей на странице. А заказчику если от бизнеса, а не юзер, ну вот нафиг это не сдалось, нет есть конечно директора которые и в эту фигню лезут, ну дело их, и боль ваша. Напроектируете, страницы, поля, карточки, токены погоняете, на месяца три, и все в мусорку. Так как оказывается нам другое было нужно. При запуске в прод 90% токенов будут бегать с постоянными нарушениями, по сути, вашей low code системы.

Или тут не про проектирвоание, а про имплементацию регламента со слов юзера, какие поля нужны? Я что то путаюсь уже.

А потом по этому хозяйству директора ещё и kpi считают пользователей этих самых бпм))))))

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

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

Уважаемые архитекторы, накидайте, пожалуйста, типовые конфликты между всякими ility.
Например. Безопасность vs производительность. Для обеспечения безопасности требуется шифрование, которое замедляет работу. Итп

Ну вот вам и ответ. Если вам "визивиг-систему", то берите платформу и рисуйте тем. Сначала на костылях, потом под костыли код подкладывайте. Имхо, это "прототипирование на бою". Если бизнес готов платить - пустить платит. Только на круг это выйдет дороже, чем если архитектор и аналитики сначала проработают ФТ и НФТ, а потом уже реализация.

Зачем bpmn, битрикса хватит собрать шишки. Все равно потом переделывать...

Кадры на пыху и битру стоят дешевле...

Есть такое, только в битре, нет анализатора токенов. Видел такое в бизаге, видел в сапе, в камунде что то есть (в камунде правда тепловой, на перегрев мест).

Конечно данные по GAP везде, все равно ручками в заносят, по опросу. Зато сразу видно, при прогоне, после внесения, где полный швах и разрывы, в паре мест или вообще везде.

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