Интересуют мнения имевших опыт консервативной модернизации относительно больших систем.
Описание обобщенной ситуации по ссылке .

ValPot, Опыт всегда интересен. Им надо обмениваться ;) Если не хотите флейма здесь, может быть напишете пару абзацев в комментариях к исходной ссылке (регистрация не требуется)?

АнатоЛой, Petro123, спасибо, ваши комментарии касаются более детального уровеня реализации, но он также становится нужным позднее, когда завершены планы по эволюции архитектуры. Разумеется, БДЕ не годится по многим критериям. Использование веб-служб существенно упрощает работу в глобальной сети, для сохранения DataSet-подхода потребуется реализация своих на основе ClientDataSet, например. Вынос отчетов на сервер также решает многие проблемы резвертывания. ООП в базе данных необходимо в разумных пределах, минимально - сокрытие доступа к таблицам на уровне ХП и проекций, CRUD-часть генерируется по метаданным (если они есть), рееестр обьектов, ядро безопасности. Тонкий веб-сервис в данном варианте только вызывает нужную ХП и возврашает результат, по сути обертка протокола работы с сервером приложений (реализованном в виде слоя ХП). Ну ладно, это детали.

АнатоЛойСобственно, а что Вы хотя бы приблизительно ожидали? :)
Я прошу никого не обижаться ;)
Вначале хотелось бы послушать начальника транспортного цеха, например, что " было принято решение по выносы логики в модули данных, затем их вынесли на сервер и стали использовать удаленно (midas, еще что-то в т.ч. свое). Это дало преимущества в том-то, решило следующие проблемы, но еще остались такие-то проблемы и появились новые "

WJВ качестве информации к размышлению предлагаю еще одно лекарство от "переписывания нахрен" - это интеграцию при помощи BPM-систем. Про сами системы говорить сейчас не стану, поскольку большинство о них уже "все знает", а те, кто не знают, могут и погуглить или просто спросить (тогда будет смысл отвечать :) ). А вот про то, что с этим можно сделать, скажу пару слов.
Итак, имеем одно (а скорее всего два, три) легаси-приложения, несколько любимых экселевых таблиц (в которых просто удобно), электронную почту и icq в качестве средств коммуникации... ну и еще может быть что-то свое, родное. Переписывать все просто невозможно. Сломать что-то страшно, поскольку так хоть как-то живет, а там кто его знает.
Думаю, что какое-то представление о том, как это должно между собой взаимодействовать у вас есть. Т.е. предполагаемую архитектуру вы можете описать (можно просто на бумаге). Если предположить, что взаимодействие строится на уровне сервисов, то назовем ее просто - сервис-ориентированная архитектура (то бишь SOA ;-) ). Не нравится - зовите по-другому, не принципиально.
Для обмена сервисами можно использовать специальные транспорт - т.н. Enterprise Service Bus (ESB), хотя это не обязательное условие.
В BPM-системе описываете процессы, в рамках которых взаимодействуют ваши приложения. На определенных шагах процесса выполняете интеграцию (кстати, интеграция возможна не только на уровне сервисов, но и, при желании, на уровне данных, на уровне функций).
Т.к. задания приходят пользователям из BPM-системы, то необходимость пересылки по электронной почте отпадает (данные процесса доступны пользователям в необходимом для них объеме).
Примерно так. Пунктиром.
Почему мне нравится этот вариант? Да хотя бы потому, что когда у вас есть проблемы с устаревающим ПО (да и вообще с чем-то устаревающим), то решать их устаревающими методами можно, конечно, но тупиково, имхо. Особенно если есть современные.

Обожаю адптов полумертвой СОА .
Вам трудно поддерживать унаследованный софт?
Окружите его веб-сервисами, и тогда вы сможете поддерживать не только унаследованный софт, но и сервисы впридачу.

Извините, не удержался, по сути же.
Речь не идет о "легаси", речь о промышленных системах в эксплуатации с долгсрочными планами дальнейшего развития и эксплуатации. Чтобы использовать по назначению СОА/ОСА нужно вначале корректно декомпозировать монолит.

iscrafmTemplar,
"полумертвая" не СОА, "полумертвыми" выглядят попытки сообщества привести СОА к единому стандарту реализации . Слишком много видений того, "как нужно делать". Сама архитектура живет и здравствует.
Без стандартизации она остается внутренней технологией фреймворков и средством интеграции.

WJ2 Templar
архитектура и реализация архитектурных решений - это несколько разные вещи. Если архитектура предусматривает взаимодействие между ее элементами посредством сервисов - это будет сервис-ориентированная архитектура.
Ок, т.е. два сиквел-сервера с репликацией - это СОА.

WJПоэтому, если Вы внимательно читали мой пост, я предлагаю в качестве средства интеграции BPM-систему(ы).
Если вы внимательно читали постановку вопроса, то интеграция в нее не входит. Посему просьба не засорять ветку.