.NET меня лично пугает. Я за JVM решения.

Понял, спасибо за мнение

Норм, на самом деле. Что точно видно - это то, что на русском языке + в программном продукте доступно понимание "единой модели". Это радует, так как можно говорить про "единую модель". Например, "единая" =

1) одна (single)
2) стандартная, и через это объединяющая (unified)
3) общая в смысле "мы разные - но мы знаем, что у нас общее" (shared)

Ну, если быть точным, то единая метамодель - элементы конструктора для построения уникальных моделей предприятий.

Если говорить "формальных каркасов юридических форм и движения внутренних процессов в рамках законов РФ" - то да, это норм история.
Но всё переводить на БП ... эпик с Комундой же есть. И российский опыт BP-based ERP в 2000-е

Net. - конечно устарел. Но логика отработана. Ищем возможности перевода на JVM.

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

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

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

Платформа -монолит?

От масштаба ещё зависит. Если в решении участвует несколько десятков совершенно разных технически систем, то как-то наоборот, всем становится наплевать на то, под каким там конкретно названием между 21-й и 13-й системой передаётся какой-нибудь идентификатор клиента - программисты разберутся

Для монолитных компаний нужны монолитные решения.
Т.е. это норм, сегмент "ВНИИФТРИ-ГК НПЦ им.Хруничева-..." работает в монолитном оргдизайне, и им нужны современные монолитные решения.

На счет современности тут как-то сомнения)

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

Другой вопрос в том, например, что СеверСталь уже лет 10 двигается в другом направлении. Как и сотни компаний.
Магнит, например, в этом году завёл топов из LaModa :)

На счет утверждения что монолитным компаниям нужны монолитные решения,  тоже спорно

ну да, согласен. Вообще мой ответ (как и изначальный вопрос) неполон. Нужно понимать, для чего солюшн разрабатывает ПИТВ (систем внутри решения?), кто отвечает за каждую систему (т.е. кто как бы потребитель ПИТВ) и т.д. В моей практике все ПИТВ в итоге падают на программистов, для которых технические детали обычно либо уже известны (так как ПИТВ в итоге пытается учесть особенности их существующих АПИ), либо ограничиваются выбором "выставить рест/ писать в (читать из) очередь". А чтобы разработать само АПИ ,им как раз нужны поля, данные и структуры

Банки и атомные станции с вами не согласятся :) Кобол в 2020
https://www.cnews.ru/news/top/2020-04-07_ssha_izza_koronavirusa_ponadobilis

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

Зависит от типа "питания": если компания является chain'ом ещё большего дотационного монолита - то гибкое решение развалит всю структуру не по тех.причине или интерфейса - заказ на изменения орг.дизайна обычно связан с эпиком, и этот эпик должен "созреть".
Например, у Сазерленда в "SCRUM. Революционный ..." с похожего эпика FBI начинает книга.