Критерии, которые мы выбираем: поучительные итоги одного небольшого опроса

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

В мае этого года в МГУ состоялся семинар московской секции группы SIGMOD общества ACM по теме "Проблема выбора СУБД для реализации проектов крупных информационных систем" (см. Computerworld Россия, 1998, № 27). В рамках подготовки к этому семинару мной был проведен небольшой опрос, результаты которого впоследствии показались достойными интереса читателей, особенно той их части, которая участвует в процедурах принятия решений.

Мотивировка

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

Первой была посылка о том, что современная computer science состоит из трех неразменных компонентов: науки, технологии и практики. Всякая деятельность, игнорирующая хотя бы один из этих компонентов, сколь бы увлекательна она ни была, обесценена или же несостоятельна для computer science. И наоборот: жизнеспособна только такая деятельность, в которой сбалансированно, без явных перекосов в ту или иную сторону присутствуют все три компонента. В данном случае мне захотелось выяснить, насколько насущна или же, наоборот, надуманна для реально существующей практики проблема выбора СУБД по техническим характеристикам. То есть целью было не "заземлить" предполагавшееся обсуждение, но, скорее, попытаться сопоставить его с потребностями жизни.

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

Объективно, цены, предлагаемые западными фирмами-консультантами, пока остаются неподъемными для 95% отечественных предприятий и персонально для автора этих строк, и все мы в отдельности, таким образом, не в состоянии заказать требуемый анализ или купить результаты проводившихся. (Конечно, цены отечественных консультантов намного доступнее. Однако, если исключить деятельность, сводящуюся к номинациям типа "за наибольшее число продаж", то у нас аналитические фирмы, сочетающие понимание и бизнес-требований, и особенностей применения ИТ, по моему мнению, встречаются редко.)

Субъективно же я всегда ощущал некоторую отчужденность результатов подобных анализов, проведенных известными фирмами-консультантами. Психологически доверие к сведениям, установленным самостоятельно, более основательно, нежели к собранным "кем-то", "неизвестно как" и "за мои деньги". Одно дело — получаю из третьих рук, другое — вижу сам.

Приведенные соображения и подвигли меня на эксперимент в виде опроса по интересующей теме непосредственно в среде разработчиков.

Характеристики опроса

Опрос проводился по электронной почте с использованием списка рассылки Группы пользователей Oracle (ЕАГПО) и по знакомым зарубежным адресам. Таким образом, тема опроса отходит от названия семинара и точнее формулируется как "Взгляд пользователей Oracle на технические аспекты выбора СУБД". Было задано четыре последовательно фокусирующихся вопроса плюс один дополнительный (фактически — приглашение сделать комментарий).

Было получено 16 ответов из отечественных организаций (РФ) и 5 из зарубежных (США и Сингапур). (Слово "западный" далее в тексте должно пониматься фигурально.) Организации оказались представлены достаточно разнообразно, в их числе были и большие, и средние, и малые (все три категории — как по нашим, так и по западным меркам) государственные и коммерческие учреждения, учебные заведения. Отвечали люди, непосредственно работающие с СУБД, то есть разработчики и администраторы БД, а также технические руководители.

Однако, прежде чем предложить результаты опроса вниманию читателей, хотелось бы сразу сделать оговорку.

Критика

Во всяком деле бывают специалисты, и в составлении опросов тоже. Я сознаю свое дилетантство в этой области, и свидетельствую, что даже в рамках такой простой акции столкнулся с определенными сложностями в подборе вопросов, обработке ответов и в планировании опроса. Естественно, нужно критически отнестись к представительности ("репрезентативности") выборки, к ее малому объему и способу формирования. Можно подчеркнуть, что проведение подобных акций требует больше знаний, времени и прочих ресурсов, нежели их имелось в моем распоряжении. Я рекомендую при проведении подобного рода исследований обращаться к специалистам.

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

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

Результаты опроса

Результаты опроса практически в необработанном виде (анонимно и с минимальными корректировками) приведены для всех желающих по адресу http://www.ccas.ru/~prz/hp2.html. Малое число респондентов делает ответы обозримыми.

Сводка результатов приведена в таблицах 1, 2 и 3. Организация таблиц требует пояснения.

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

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

Для более аккуратной интерпретации результатов они приведены на языках оригинала (русском и английском).

Некоторые выводы

Общее наблюдение, связанное с "нашими"/"не нашими" ответами, таково. Зарубежные ответы оказались лаконичнее и единообразнее отечественных. Иногда создается ощущение, что все зарубежные коллеги отвечают под впечатлением одного и того же прочитанного учебника либо же обзора/отчета фирмы-консультанта. "Наши" ответы менее "причесаны" и, напротив, более разнообразны и оригинальны. Если это ощущение не случайно, оно могло бы регистрировать факт более технологичной профессиональной обстановки зарубежных коллег, подразумевающей распространенность базового образования и наличие внимания и доверия к мнению консультирующих институтов. В результате общественное мнение зарубежных специалистов сформировано в целом отчетливее нашего.

Наблюдения по таблице 1(а, б)

Бросается в глаза то, что у отечественных пользователей вслед за Oracle (не забудем, что опрос производился среди пользователей Oracle) с большим отставанием следует группа "персональных" систем управления данными, в то время как у зарубежных коллег более чем в половине случаев упоминаются системы одного класса с Oracle. Западный список сам по себе короче и почти вообще не содержит малых систем наряду с крупными.

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

Насколько мне известно, такой расклад для западных фирм не случаен. Есть не менее двух типичных ситуаций, его порождающих. Во-первых, это тот случай, когда СУБД появляется под новую задачу. Старые задачи при этом обслуживаются старыми СУБД, а новая СУБД подбирается как бы заново, исходя скорее из требований новой задачи, чем из-за оглядки на знакомую систему. Во-вторых, очень многие западные фирмы (а по-моему, так большинство, если речь идет о средних и больших) сознательно выдерживают практику опоры более чем на одного поставщика, каким бы "непотопляемым" некий поставщик ни казался (IBM, Oracle).

Для наших же фирм выбор СУБД — это более болезненное явление, поскольку выбирается одна в своем классе и на долгое время ("с ней дальше жить..."). Есть и другое умозаключение по поводу такого выбора. Известно, что разработчикам, сделавшим себе имя (личное или корпоративное) на приложениях, базирующихся на персональных системах управления данными, трудно перестраивать свою работу под использование больших СУБД. Образно выражаясь, "для этого нужно перестроить мозги", то есть осуществить одну из самых болезненных операций для человека. Трудность ее подтверждается нерадужным опытом перевода на большие СУБД отечественных приложений, бывших успешными на базе малых систем управления данными.

Наблюдения по таблицам 2(а, б)

Бросается в глаза, что бесспорными лидерами в ответах отечественных пользователей являются технические критерии выбора СУБД, за ними с небольшим отрывом идут финансовые. Любопытно, что активный учет финансовых критериев не помешал приобретению такой "дорогой" системы, как Oracle.

В противовес этому у зарубежных коллег критерии Technical, Market position и Political равноценны и опережают Financial. Можно предположить, что технические характеристики не столь сильно заботят западного пользователя, возможно полагающего, что у целого ряда СУБД они не так уж радикально разнятся. Западные пользователи чаще ориентируются на устойчивое положение фирмы-поставщика на рынке (проблема гарантированного будущего) и на политические (тоже внешние по отношению к техническим) мотивы. На уровне тенденции решение о расходах вторично, проще говоря, "сколько потребуется, столько заплатим, лишь бы это было то, что нужно". У нас аналогом этого утверждения нередко служит: "Сколько потребуется, столько заплатим, если эта система действительно такая замечательная".

У наших пользователей политические мотивы относительно малопопулярны, а положение на рынке как таковое вообще не упомянуто.

Очевидно, что отношение к техническим критериям у отечественных организаций более ревностное, чем у зарубежных, хотя не исключено, что общность такого наблюдения зависит от ролевого восприятия опросного списка (на вопрос "как дела?" одни люди начинают рассказывать о своих делах, а другие отвечают: "Хорошо").

Наблюдения по таблицам 3(а, б)

Бросается в глаза, что из значимых технических критериев, по мнению отечественных пользователей, лидируют производительность, надежность и средства разработки (качество с количеством), а у зарубежных — переносимость и средства разработки. "Наш" приоритет критериев подтверждает предположительную тенденцию выбора СУБД как "одной, любимой, и надолго", а западный — "под проект" и/или как альтернативу. Можно предположить, что парк аппаратных платформ в отечественных фирмах не столь разнообразен, и в типичном случае сводится к NT-серверу (вариант: Unix-серверу) и Wintel-рабочим станциям, а потому переносимость для нас не столь актуальна.

Примечательно, что двое из пяти зарубежных пользователей отметили хорошую реализацию SQL в Oracle; отечественные на это не обратили внимания (еще одно подтверждение предположениям о базовом образовании пользователей и "граничных условиях" выбора СУБД).

Любопытно, что наши пользователи почти не называют аппаратные требования в качестве критерия выбора. Припоминается, лет десять назад этот критерий был у нас одним из важнейших. Или направленность данного опроса пришлась на вполне определенную нишу?

Один из возможных общих выводов по таблице 3(а,б) таков: отношение к техническим критериям у отечественных пользователей более ревностное, чем у западных коллег, подход к ним более тщательный. Вопрос, правильно это или нет, можно предложить для раздумий.

Частные наблюдения

Некоторые подмеченные из таблиц закономерности (кто-то наверняка сделает и свои наблюдения) носят, конечно, обобщенный характер в силу обобщенного характера самих таблиц. Знакомство с полными текстами ответов демонстрирует разброс конкретных мнений. В качестве примера можно взять отношение к техническим критериям выбора. Здесь имеются две крайние точки зрения: одна подразумевает очень въедливое рассмотрение самых разных системных характеристик (см. Web-страницу, сравнение Oracle с Sybase), другая же, противоположная, сводится к суждению типа "что бы там о системе ни писали, все равно ее до конца не узнаешь, пока не купишь и сам не поработаешь". Примечательно, что вторую точку зрения разделяет не только часть наших пользователей, но и некоторые зарубежные, вероятно стесненные определенным поведенческим стереотипом в отношении лицензионной практики. Оказалось, что распределение мнений между этими двумя крайними точками зрения приблизительно равномерно (см. исходные тексты ответов на Web-узле).

Еще один пример диаметральных позиций: в одних организациях выбор СУБД предопределен внешними факторами (например, когда речь идет о фирме-разработчике, для которой СУБД называет заказчик), а в других неясно сформулировано даже прикладное назначение СУБД, следовательно, о технических критериях выбора становится говорить очень сложно, и роль их при выборе отходит на задний план. Примечательно, что вторая ситуация знакома не только у нас в стране, но также и за рубежом. Возможно, по этой причине один из западных респондентов отметил, что рассмотрение технических характеристик "только усложняет выбор".

Интересно рассудительное высказывание одного из западных респондентов, который рекомендует "использовать Oracle для больших систем с неоднородной аппаратной базой; сервер Informix — для Unix-платформ, потому что он на них быстрее; MS SQL Server — для сетей из PC (Windows NT); Access для PC-платформ (Windows 95)". "Продукты Microsoft — не самые эффективные, однако они дешевы, распространены и будут улучшаться", — продолжает респондент. (Это немного напоминает другое правило из категории тех, что американцы называют rule of thumb: "Для нормальной работы мэйнфрейм нужно перезагружать раз в год, Unix — раз в квартал, а Windows NT — раз в неделю".)

Оставляю удовольствие остальные наблюдения и выводы сделать читателям самостоятельно.

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