в мтс буду в октябре очень кратко рассказывать про это

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

Спасибо

в линкеде есть заанглоязыченные слайды

А, вы OPA используете просто как DSL и считалку, не как runtime component?

Интересно.

именно так

накостылили свой ui

но как я говорил я считаю это типовой случай

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

К чему это я. Если наложить на триаду enterprise - solution - software, то какая для каждого система будет? Точнее, что является основными частями системы.

У меня получается так:
software - это пакеты, классы
solution - модули (контейнеры), подсистемы
enterprise - подразделения бизнеса

Интересны альтернативные точки зрения.

Я бы сказал (про целевую систему) так:
Software (aka Application) - одно приложение/сервис
Solution - решение (см. определение Gartner), часто на основе распределенной системы множества сервисов/приложений/готовых продуктов.
Enterprise - разные трактовки, или (чаще) все IT-службы предприятия/бизнес-подразделения, или целиком все-таки предприятие/бизнес-подразделение.

Чем крупнее, тем меньше четкости, просто потому что менее унифицировано отраслью.

Тогда части это:
Software (aka Application) - компоненты времени исполнения (которые в ЯП практически никак не выражены, увы), и модули времени разработки (пакеты, библиотеки, сборки)
Solution - отдельные приложения/сервисы/инсталляции продуктов.
Enterprise - очень много всего, и подразделения ИТ-служб, и ЦОды, и блоки инфраструктуры, и блоки прикладного ПО, и т.п.

Игорь, спасибо!

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

Суть же "Легаси" здесь это размытые границы и области ответственности?

Речь про адресные регистры и кучу источников данных? Согласен, но тут проблема именно в том, что опять же размыта ответственность.
Если взять новый ландшафт, где пока определены границы между системами, нужен ли MDM?

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

Потому что нужно делать сервис поставщиков и он будет мастер-системой