К вопросу о выборе серверной платформы и инструментов разработки прикладного ПО

Евгений Трофимов

Покупка компанией Hewlett-Packard компании Compaq — это нормальное, экономически обоснованное решение. Бизнес HP более разносторонний и устойчивый за счет периферии, систем управления и консалтинга. Хотя Compaq, по моему мнению, более активен в маркетинге. Хорошо, если экономия издержек дополнится объединением сильных сторон компаний.

Не думаю, что слияние HP и Compaq сильно изменит ситуацию на рынке серверных платформ для банковской автоматизации. В создание конечного банковского продукта гораздо больший вклад вносит системное и прикладное ПО. Не так важно, на каком сервере оно будет работать — HP, Sun или IBM. В свете намечающегося укрупнения российской банковской системы желательно при выборе серверной платформы не упускать из виду вопросы масштабирования, избегать «зоопарка» и очень ответственно выбирать партнеров, занимающихся технической поддержкой.

При принятии серьезного, стратегического решения, которое будет определять направление и темпы развития банковской прикладной системы на следующие 5—10 лет, невозможно ограничиться только анализом технических возможностей, необходимо учесть другие факторы.

Длительность жизненного цикла разработанных систем. Информационные системы являются «движком» банковских операционных технологий. Чем дольше они не требуют замены, тем выгоднее были сделаны инвестиции в их разработку. Нужно выбирать инструменты разработки, которые позволяют создавать долгоживущие системы. Например, в 1993 г. АБС можно было создать на FoxBase, Clarion или Oracle Forms. Жизненный цикл у этих систем был бы разный. Чаще всего выбирался средний путь, скорее всего, из-за умеренной стоимости платформы Btrieve. Принимавшие решение понимали, что выбор пути типа FoxBase не даст длительной перспективы, но не просчитали, что дополнительные затраты на Oracle в 30-50 тыс. долл. составляют мизерную часть от будущих семилетних инвестиций в разработку, составляющих, по разным оценкам, от 1,5 до 3 млн долл. При замене платформы эти инвестиции аннулируются. Ничьей вины здесь нет, инвестиции давно окупились. Но если сегодня снова предстоит выбор, почему бы не воспользоваться опытом и не выбрать лучшее решение?

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

Надежность интегрированного набора инструментов. Проблемы, как известно, чаще всего находятся на стыках. Программные средства — не исключение. За счет чего Microsoft раз за разом выбивает своих конкурентов с рынка? В том числе потому, что изменяет свои компоненты без должного информирования. Даже если в такой ситуации нет злого умысла, все равно разбираться с проблемами нестыковок придется разработчику. Работа в рамках взаимосвязанного комплекса программных средств от одного поставщика значительно снижает издержки интеграции различных частей систем, а значит, повышает скорость и качество разработки. Конечно, многие компании говорят о поддержке открытых стандартов. Однако меняются как сами стандарты, так и их версии, и проблемы совместимости снова возникают.

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

В качестве еще одного аргумента предлагаю рассмотреть следующий пример. На рынке труда существует достаточный спрос на программистов, владеющих Delphi и Oracle Developer. Почему уровень заработной платы вторых раза в полтора больше? Экономическая наука дает однозначный ответ: программиста нанимают для производства программного продукта. Рынок, т. е. очень много людей, которые рискуют собственными деньгами, считает, т. е. неоднократно проверил, что отдача (выход продукта) от программиста на Oracle в полтора раза выше. Думаю, каждому сотруднику небезразлична высокая рыночная стоимость его труда — это и уверенность в будущем, и потенциал для увеличения заработной платы.

Исходя из всего изложенного выше, считаю что «поляна» выбора сужена до нескольких брендов: IBM, Oracle, Microsoft.

Об авторе:
Трофимов Евгений Васильевич — директор Департамента информационных технологий АКБ «РОСБАНК».



«Банковские Технологии», № 10 2001