Codenamed<...>для одного заказчика, скажем, на MS SQL + .Net. <...> второй заказчик и говорит: мы хотим то же самое (с некоторыми изменениями, конечно), но на Oracle + Java. <...> мы хотим на MS SQL, но чтобы клиент на Delphi был. Все хотят дать много денег :)Заинтересованное лицо, которое выдвигает требования относительно средств реализации, обладает нездоровым техническим бэкграундом. Какая ему разница, из чего скомпиллирован исполняемый файл - из .Net или Delphi? У него где-то остались рабочие станции на Windows 95? Или он серьёзно рассчитывает, что ему дадут исходники и он будет самостоятельно копаться в чужом коде?
Поговорите с заинтересованным лицом позицией повыше. Оно, скорее всего, скажет, что средства реализации ему почти безразличны, и максимум, что ему важно - это ОС.

CodenamedСоответственно, возникает вопрос: в каком виде следует реализовать бизнес-логику исходного решения, чтобы ее можно было без изменений перенести на другую платформу?
<...>IMHO в каком-нибудь одном, но качественно. Всё равно на всех не угодите.
Чем эффективнее решение - тем сильнее оно привязано к платформе.
Самым "кросс-платформенным" из перечисленных выглядит Oracle + Java. Но кривая обучения, цена разработки, приобретения и владения...

softwarerВ большинстве случаев можно показать клиенту цифры и убедить его, что поставить нужную СУБД гораздо дешевле, нежели заказывать подобную доработку.+1

softwarerПри определенном масштабе деятельности станет целесообразным создать группу гуру, дабы они спроектировали и реализовали метаязык и несколько адаптеров для него к различным СУБД. В этом случае основа пишется на метаязыке и не меняется, отдельные места - прежде всего ради оптимальной производительности - таки реализуются отдельно для каждой СУБД.Сдаётся мне, что этот масштаб - SAP.

softwarerНаконец, существует квазирешение выделения аппсервера. При этом заказчик вместо "не хочу MSSQL, хочу Oracle" начнет говорить "не хочу IIS, хочу WepSphaera", разницы никакой.Независимый от вендора Apache Tomcat?

chpЯ работал в банке. Была куплена банковская АБС. Работала она на Oracle и до сих пор работает. Причем огромным плюсом ее было то что исходники ее были открыты. Мы постоянно в ней что-то доделывали или как минимум смотрели как и что работает. Можно сказать что это было неправильно и надо было делать заказы у разработчика. Только разработчик просто не в силах был удовлетворить все запросы клиентов.
Наверняка до этой АБС была какая-то другая, пусть даже "лоскутная". Для неё была инфраструктура, и у кадров тех. поддержки также были по ней какие-то знания. И тоже некоторое время банк был в подвешенном состоянии. Но это никого не остановило, т.к. новая АБС давала большие преимущества и/или кто-то получил за неё хороший откат.

chp
И для нас было принитцпиально то что она работала на Oracle, потому что все кадры тех поддержки были заточены под Oracle и под эту АБС.
Так был ли Oracle в банке до этой АБС?

chp
Людям позицией выше было все равно на чем она будет написана, они считают деньги: если есть готовая платформа за лицензию которой уплачено, если есть техника под эту базу/операционку, и самое главное люди, умеющие работать с такими программами/системами, то в реальности переход на другую платформу был бы сродни закрытию банка на неопределнный срок, это не считая прямых затрат. Так что не все так просто с выбором операционки и базы.
Согласен, здесь, как и везде, нужно считать. Впрочем, переписывание и перетестирование АБС специально под ваш банк - по цене сродни созданию АБС с нуля. Наверное, для банков первой десятки, у которых тысячи сотрудников поддержки АБС и сотни серверов, это имеет смысл, для остальных - вряд ли.

chp
Насчет Win95 - к примеру у нас есть организации (ФСБ, ЦБ ) ради которых приходится до сих пор использовать дискеты - и это в 21 веке.
Мы всё-таки обсуждаем коммерческие организации, основной целью которых является получение прибыли. Разработка ПО для гос. организаций, большинство из которых в силу различных причин очень неравномерно распределяют деньги на IT - отдельный вопрос.