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

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

Если выяснится (для enterprise приложения - что-то продобное с вероятностью процентов 90), что для Вашей задачи требуется что-то типа RHEL + JBoss + Oracle и абсолютно определенная топология кластера, - Вы практически автоматом получите ответы на все вопросы. ;)

P.S. На sql.ru Вы вряд ли найдете решение Вашей проблемы.

> Вот только из них еще совершенно не вытекает ни выбор технологий,
> ни выбор подрядчика. :)

Да ну? ;))) ОК, давайте начнем с простых вещей.

Какова требуемая доступность каждого из сервисов приложения? Каковы требования к регулярности/продолжительности регламентных работ? Как предполагается хранить данные? Какова их природа, объем и динамика роста?

> типа щас скажут что необходима высокая надёжность

Дружище, надежность "высокой" не бывает. Она имеет конкретные характеристики (необязательно прямые).

> доступность

Та же фигня.

> набегут ораклисты с криками "Оракл! Оракл!"

Приложение - это не только СУБД. Вы по существу что-то хотите сказать?

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

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

Напрасно. ;)

ОК, дайте ответы на эти вопросы не публично, не в форуме, а, скажем, опишите задачу Вашему интегратору. Типичный ответ, который Вы, уверен, получите (речь сейчас об аппаратной части) будет таким: с одной стороны, характеристики кластера и СХД ограничены Вашими требованиями, с другой стороны - бюджетом.

Относительно программной части - абсолютно аналогичная ситуация.

> нужна высокая надежность, доступность и производительность

Да нет такой характеристики: высокая доступность. Сколько девяток? Пять, семь, девять? Вы вообще представляете себе разницу в стоимости реализации? Представляете, сколько будет стоить катастрофоустойчивое решение? ;)

> объемы планируются большие

Сотни гигабайт, терабайт, петабайт? Динамика роста какова?

> даже вообще не на RDBMS

Поэтому я и спросил про природу данных.

> конечно на Оракле (тут и вариантов-то нет)

Варианты всегда есть.

> но что это определяет??

Многое. Например, на выбор СУБД может влиять (не всегда, просто как пример) схема бэкапа, которая в свою очередь связана с топологией кластера, который выбирается исходя из требуемой доступности.

> "Как хранить данные" - это уж точно из области проектирования, а не
> постановки требований.

Нет.

> делать надо на Oracle + EJB на WebLogic

Imho плохое решение.

> то уж поставщика это все равно абсолютно не определяет

Еще как определяет. Очень немногие в России могут реализовать такую задачу.

> если поставщик умеет и любит работать с продуктами IBM

;) Т. е., оказывается, какие-то предпочтения априори существуют?