Rms это на аналитиков бизнес, с интеграцией в фитчи таск трекера и к тестерам в итоге. Тогда будет поддерживаться в естественном порядке.

Но с этим быстрым переключением контекста между задачами и выдачей решений я себя чувствую вот так:
https://youtu.be/4SDN8TYaCIY

Работает, если можно в терминах Archimate выражать условные "квадратики" и "стрелочки" с диаграмм в Визио)

Если архимейт понятен только посвященным, то вам пора менять подход. Делать частичные представления, упрощать нотацию.
Для меня сейчас важнее стало качество “понятно” чем “правильно”.

Популярная отмазка современности на любую работу которую не хочется делать: “у нас MVP”

Возможно надо менять понимание MVP? У Instagram MVP был сделан за пару дней. Прототип оптической мышки сделали за послеобеденное время и потратили пару баксов на зап. части.

Интересные примеры успешных MVP:
https://softwarebrothers.co/blog/15-examples-of-successful-mvps/

Хотя, конечно, это не значит, что скопировав, будет такой же успех.
Но просто для примера и вдохновения, мне кажется, полезно.

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

Т.е. сложность растёт, а мы стараемся её упростить - схемами, структурами хранения требований, общим осознанием архитектуры и решаемых проблем.

С определённого момента (обычно хорошо видно в банках), сложность возрастает сильно из-за ограничений сервисов (скорость выполнения запросов, качество данных, отказоустойчивость, прочая нефункциональщина). И сам сервис становится тяжеловесным с кучей юз-кейсов и сложной логикой. Вот тут появляется НЕОБХОДИМОСТЬ нового уровня абстракции над документацией в виде Archimate, который ужесточает правила ведения документации, дополняет и объединяет её.

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

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

Кстати, у меня давно в голове сидит вопрос - как определить степень формализованности (жесткости правил ведения документации) для конкретного проекта. В том числе при различиях продуктового и проектного подхода. На что ориентироваться? На текущий уровень зрелости? И как определить, если текущий уровень явно "слабоват"

Документ не самоцель. По моему тут ошибка в уровне. Документ это подтверждение проведения работ. Исследование? Документ исследования, изменеия в процессе? Документ фиксации изменений. Я склоняюсь к этому. Если не было проведено обследование но "выплевывается" документ ТЗ потому что так надо, то грошь цена этому документу.

Провели планирование - вот вам план проведения работ на месяц вперед. А условное качество зависит от и рисков и ресурсов.

Не везде, иногда mvp это грамотное решение, которое обладает минимальным набором для удовлетворения. Тут вопрос ожиданий. А то у вас mvp как демо выходит.

Документ и связанные с ним инструменты и процессы документирования - это инструмент для снятия рисков и уменьшения трудозатрат. Вопрос в методике определения инструментов, требуемых в конкретном проекте.
Тот же самый план проведения работ можно сделать очень по-разному. Требования можно писать в тексте задачи в джира или в чатике с разрабом, "все все поймут" и "сделаем в лучшем виде". В каких-то ситуциях это прокатывает, в каких-то - приводит к возвратам, к недовольству заказчика, срыву сроков и прочему.
Где-то есть методики, как снимать риски и снижать трудозатраты с помощью документирования?

Может, у кого опыт есть.

В чатике это не документ, это процесс. Пока нет ссылки постояной и версионности документа нет, а значит три часа в чате были потеряны. Да обеспечили процесс но не провели работы. Это как в стройке, здание может стоять, но пока акт не подписан, наряды не выданы, для проекта здания, конечного продукта илм работ не существует. Есть что то, на что потрачены ресурсы и запущены процессы.

А матрица Коуберна не поможет?