Я тут вместе с ChatGPT немного подумал про разделение ролей и протечку абстракций, и вот что у нас получилось, полюбопытствуйте:

Абстракции есть не только в архитектуре. Роли на уровне организации распределены тоже по слоям абстракций, с обещанием "вам на этом уровне не нужно об этом думать". Это [само]обман — абстракции всегда дырявы. С этим не нужно бороться, это нужно учитывать.

Частая ошибка — проводить границы ролей по артефактам ("кто описывает процессы, кто требования, а кто API"). Артефакт — след деятельности, а не её смысл. А граница проходит по языку, точнее — по модальностям. Сергей Нужненко любит упоминать логику, ну вот всё проектирование — это набор модальных логик, своих для каждой роли. По сути, описание разных миров с операторами достижимости: □ "во всех достижимых мирах" / ◊ "в некотором достижимом мире".

По ролям эти логики раскладываются так:

Продакт (владелец ценности). Модальность пользы: "желательно/целесообразно/вероятно окупится | во всех мирах/в отдельном мире". Это логика предпочтений и неопределённости. "В большинстве релевантных сценариев это даёт пользу [и это лучше, чем другой вариант], мы твердо уверены в этом".

BA (владелец политик). Деонтическая модальность, логика норм и обязательств: обязательно/разрешено/запрещено. "Во всех допустимых (нормативно корректных) вариантах поведения бизнеса это должно быть так".

SA (владелец модели). Динамическая и темпоральная модальность: "после события X", "всегда", "в состоянии системы S1 | допустимо/обязательно". Сюда же модальность последовательности ("после выполнения действия A допустимо/обязательно B"). В общем, это про целостность, "во всех достижимых состояниях модели инварианты сохраняются".

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

Разработчик, владелец реализации. В теории, должен действовать в логике формальных методов (TLA+, лямбда-исчисление, конечные автоматы и т.п.), но в реальности всё это слишком сложно, поэтому никакой логике действия разработчика не поддаются.

Абстракции дырявы, поэтому области интереса пересекаются и оказывают влияние друг на друга: на уровень ценности всплывают юридические ограничения и стоимость качества; на уровень инвариантов — ограничения согласованности в распределенных системах; на уровень качества — дырки в наблюдаемости и эмерджентность слабосвязанных событий. Поэтому всем нужно регулярно со всеми разговаривать и договариваться.

ИИ предлагает регулярные ритуалы для выявления взаимовлияний — по-моему, он их просто на ходу придумал, цитирую без правки:
Feature framing (PM ведёт): гипотеза ценности + ограничения + метрика + допустимые компромиссы по качеству.
Policy workshop (BA ведёт): правила + исключения + спорные кейсы + "кто имеет право решать исключения в рантайме".
Model review (SA ведёт): сущности/состояния/события + инварианты + контракты интеграций + миграции.
Quality attribute workshop (архитектор ведёт): сценарии качества (нагрузка, отказ, атака) + бюджеты (latency/cost) + деградации.
Design/operability review (dev ведёт): стратегия тестирования + наблюдаемость + откаты + SLO-реальность.

А роли, в конечном итоге — это предохранители необратимых потерь. Вот смотрите, что можно необратимо потерять:
— данные, если не собирали, то уже и не соберем; если необратимо испортили — обратно не восстановим (SA)
— деньги — из-за атак или сбоев (архитектор, ИБ) или неверного расчета экономики (продакт)
— доверие рынка / право на деятельность (продакт, BA)
— возможности развития (архитектор, разработчик)

Вот такая раскладка, что думаете?

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