Откуда они появляются? В нарисованной схеме нет новых данных.

Можно сократить издержки Легаси через переход на иннер сурс решения

Если интеграции делать через этот подход то все будет описано на уровне модели

И ее можно будет применить на любую инфраструктуру

Нет, так как модели преобразования данных критически зависят от инфраструктуры.
Как и код преобразования.

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

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

Сбер вот не справился )

Проблема в том что многие источники данных не стандартизованы. Это телеком с мультивендорной структурой источников и потребителей. Как ни крути нужна медиация

Ну так надо написать базовые шлюзы и базовую инфраструктуру для преобразования.
Дальше уже любые трансформации просто пишутся в коде.
Задача на сеньор-девелопера с мозгами.

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

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

И даже вот это упражнение занимает у меня довольно много ресурсов. И хочется моделированием снизить стоимость сопровождения такого решения

А кто этот "кто хочет подключится"? Какая роль, какие функции? И что значит "подключится"? И что значит "сам настроить"? И что делать с этими данными? Там очень много разных сценариев же.
Если нужно делать data lake или DWH - то это же совсем отдельные задачи (и, похоже, тут задачи именно про это).

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

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

Ну так тут решения будут ровно с теми же рисками - ошибка при рисовании моделей как минимум.
Я уж не говорю про ошибки в кодогенерации (которая обычно сложная и противная штука)

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

Предметная область медиация в операторе связи и ее развитие до экосистемного сервиса и продукта

Ну, я примерно помню структуры в телекоме...