Менеджеры Inprise о планах компании
 |
Как известно, в начале этого года Inprise объявила о реструктуризации, которая разделила корпорацию на две части. Одна из них отвечает за производство корпоративного ПО, другая - за инструментальные средства. Что подтолкнуло к реструктуризации: изменилась внешняя рыночная ситуация или причина чисто внутренняя?
Мико Алапиесса (МА): Внутренняя. Произошел перекос: мы слишком много внимания стали уделять корпоративному сектору и слишком мало - разработчикам. Теперь мы стараемся сбалансировать свою политику.
Это два совершенно разных вида бизнеса - в области маркетинга, дистрибуции и всего остального. Дел Йокам объявил о реструктуризации в январе. Новый генеральный директор, Дейл Фуллер, говорит, что надо тщательно разобраться в том, что мы собираемся делать. Сейчас он вместе с аналитиками размышляет над тем, каким образом реструктурировать компанию, чтобы не распылять средства и при этом сбалансировать оба направления. Приходится считаться с тем, что мы выпускаем и средства разработки, и программное обеспечение промежуточного слоя.
СУБД InterBase явно ориентирована на корпоративный рынок, но подразделение InterBase входит в borland.com, а не в Inprise. Поясните, пожалуйста, критерии реорганизации.
МА: Между прочим, мы уже не говорим о borland.com, мы опять говорим о Borland. Критерии - конечно, непростой вопрос. Важен не столько размер компаний-заказчиков, столько участие в процессе внедрения ПО независимых разработчиков. Скажем, InterBase используется в Москве в Центре управления полетами, Delphi используют огромные корпорации наподобие Nokia, но прежде всего это продукты, в которых важнейшую роль играют независимые разработчики.
Какая часть больше по ресурсам, по обороту: "корпоративная" или "инструментальная"?
МА: Они сопоставимы - вот все, что я могу сказать. Корпоративная часть и бизнес, связанный с услугами, развиваются опережающими темпами. Вообще же, если посмотреть на программный рынок, видно, что быстрее всего растет сектор программного обеспечения промежуточного слоя.
Вы, следовательно, предсказываете, что бизнес Inprise будет расти в сторону корпоративного рынка?
МА: Думаю, оба направления будут расти параллельно, поскольку их взаимовлияние очень велико. Наши крупные корпоративные клиенты - например, большие банки, как правило, используют наш же инструментарий: JBuilder, C++Builder, Delphi. Чем успешнее мы будем продвигать корпоративные продукты, тем лучше будут продаваться инструменты и наоборот. Очень многое решает удобство работы. Скажем, писать приложения для многозвенной архитектуры было очень сложно, пока не появились новые средства разработки. Это повторяет картину с клиент-серверной архитектурой, которая появилась лет десять назад, но стала получать реальное распространение, только когда на рынке появился PowerBuilder. То же самое и сейчас: как только станет легко разрабатывать приложения в многозвенной архитектуре, она начнет стремительно распространяться.
Каково будущее InterBase? Ставит ли эта СУБД своей целью занять место в ряду таких систем, как Oracle, Informix, Sybase и т. д.?
Пол Бич (ПБ): Рынок, на который мы прежде всего ориентируемся, - это рынок встроенных приложений. Здесь мы действительно сильны, наша СУБД прекрасно приспособлена для этих целей, мы специалисты в этих вещах и этим наш бизнес принципиально отличается от модели бизнеса Oracle или Informix. Это не значит, конечно, что у нас нет заказчиков, строящих информационные системы, за которые обычно берется Oracle. В России у нас есть два прекрасных примера приложений корпоративного уровня, масштабируемых, критически важных. Мы раздвигаем границы возможностей наших продуктов, но не инвестируем огромные средства и не тратим громадных усилий на создание, скажем, продуктов для гигантских хранилищ данных, которые управляют десятками терабайтов данных и работают на сверхмощных серверах. В этом для нас нет смысла. Впрочем, в этом вообще мало смысла. Нельзя угодить всем. Худший пример таких попыток - Microsoft SQL Server. Он работает и под Windows 98 на настольной машине, и под Windows NT, управляя терабайтными базами данных с тысячами одновременных пользователей. Давайте смотреть в глаза реальности. Реляционные СУБД разрабатывают для того, чтобы они что-то делали, а не для пресс-релизов. Невозможно эффективно делать все. Так не бывает. Нам удалось добиться больших успехов в нашей рыночной нише именно потому, что мы сосредоточились на чем-то одном, а не пытались разрабатывать продукты для поддержки огромных хранилищ данных. Я не понимаю, зачем заставлять СУБД, разработанные для задач OLTP, работать на Windows 95 или Windows 98. Надо просто разработать клиентскую часть под эти ОС.
Благодаря каким чертам InterBase добивается успеха на рынке встраиваемых баз данных? Благодаря своей компактности?
ПБ: Если вам нужна небольшая база данных Oracle, вы покупаете Personal Oracle. Если нужна небольшая база данных Sybase, покупаете Adaptive SQL Anyware. Мы знаем, что наша СУБД не такая масштабируемая, как Sybase. Но у нас другие задачи. Мы хотим занять нишу от малых до средних баз данных, мы можем поддерживать одновременно от 1 до 300 пользователей, у нас очень компактный код, систему просто инсталлировать и администрировать. InterBase очень хорошо подойдет тем, кому нужны распределенные приложения, которые разворачивались бы в филиалах компании и с которыми могли бы работать мобильные пользователи. Вот настоящая задача для баз данных. Сегодня вычисления тоже начинают путешествовать по всему миру, и это нам на руку. К тому же если вам не хочется нанимать на работу администратора баз данных и платить ему 100 тыс. долл. в год, тогда InterBase лучший выбор, чем Oracle. Другими словами, у нас очень низкая общая стоимость владения.
У Delphi красивая история, успех пришел к ней быстро, судьба инструментальных сред для Cи и C++ также складывалась достаточно гладко. А вот с базами данных у Borland были непростые отношения. InterBase - окончательный выбор?
ПБ: Дни СУБД для настольныx систем сочтены. Нужны базы данных большей мощности, с большими возможностями. С другой стороны, стоимость СУБД масштаба InterBase упала за последнее время очень резко. InterBase имеет очень хорошие показатели в отношении цена/производительность. Уже нет смысла использовать dBase, потому что InterBase может гораздо больше почти за те же деньги. То, что Borland продала dBase и Paradox, закономерно. Это признание того, что мы не хотим бороться за рынок СУБД для настольныx платформ. InterBase за последние три года продвигалась необыкновенно успешно.
Этот рост проявился в наибольшей степени в секторе встраиваемых СУБД?
ПБ: Не только, хотя это существенная доля наших доходов. Сектор СУБД для нетрадиционных интеллектуальных устройств также вносит заметный вклад. Но не меньший рост мы наблюдали и в корпоративном секторе.
Когда вы говорите о встраиваемых СУБД, вы имеете в виду и распространение СУБД в комплекте с приложениями, и собственно встроенные системы?
ПБ: Один из примеров применения СУБД InterBase - хорошо известная система безопасности 911, которую продает Motorola. Но они предлагают не InterBase - покупатель даже не знает, что она там задействована, а интегрированное решение. Это и программное обеспечение и аппаратура: наушники, мониторы, серверы, сетевые устройства. Благодаря тому что в основе лежит InterBase, система очень легко настраивается и почти не требует усилий по поддержке. Все это вместе позволяет делать относительно недорогие эффективные системы.
Вы упомянули критически важные приложения. Не требуют ли они иногда и соответствующих платформ, скажем, высоконадежных серверов наподобие Tandem или в каких-то случаях операционных систем реального времени? Не присматриваетесь ли вы к этим рынкам?
ПБ: Если уж кто-то покупает сервер Tandem, то он воспользуется и "родной" для него СУБД NonStop SQL. Он покупает очень специфичный компьютер и систему с фантастически высокой надежностью, но и платит за это соответственно. Причем еще в два-три, а то и в десять раз больше он заплатит за разворачивание системы и поддержку.
С другой стороны, смотря что понимать под критически важным приложением. Система в ЦУПе - это критически важное приложение? Конечно. Мы им дали ровно то, что они хотели, за ту цену, которую были готовы заплатить.
Как вы относитесь к объектным и объектно-ориентированным СУБД, к объектным расширениям?
ПБ: Конечно, это модно, но это действительно очень интересное направление. В InterBase еще лет десять назад появились некоторые элементы объектно-ориентированного подхода, массивы, например, компания InterBase владеет торговой маркой BLOB (двоичные большие объекты). Однако мы пока не реализовали объектные расширения SQL. Мы и сами не вполне уверены, что это лучший путь. Есть небезосновательная точка зрения, что если требуется объектная база данных, надо делать объектную, нужна реляционная - используйте реляционную. А объектно-реляционная - это какое-то промежуточное решение, несмелое. В любом случае это все еще не проверенная технология.
Наш подход - предоставить разработчикам по-настоящему расширяемую СУБД. Мы даем им все возможности: хотите написать функцию, которая бы манипулировала таблицами, столбцами или объектами, - пожалуйста, это возможно. Нужен механизм для работы с большими двоичными объектами - пожалуйста. Для этого не обязательно реализовывать объектное расширение SQL полностью.
Иными словами, цель - сделать СУБД максимально гибкой?
ПБ: В очень большой степени это так. Поскольку InterBase входит в корпорацию Inprise, наша СУБД поставляется со всеми инструментами разработки. Наши важнейшие клиенты - разработчики. Им нужна технология, которая была бы расширяемой как в процессе разработки, так и в процессе развертывания.
Но за дополнительные возможности и большую степень свободы для разработчиков обычно приходится расплачиваться риском, что СУБД будет не так надежна.
ПБ: Любая новая возможность в принципе чревата риском. Это в природе СУБД: любое изменение базового кода может привести к проблемам. Поэтому у нас длинный цикл тестирования, во время которого надо убедиться, что ни одно изменение не приведет к потере стабильности или производительности. Скажем, в пятой версии InterBase были сделаны существенные архитектурные изменения, улучшившие производительность СУБД и позволившие эффективнее использовать ресурсы. Значительные архитектурные изменения всегда опасны, поэтому целых полтора года мы выпускали промежуточные релизы, слушали, что говорят пользователи, и старались как можно быстрее исправить замеченные ошибки.
Вы не так уж часто упоминаете Internet, во всяком случае, по сравнению с другими компаниями, у которых Internet - через слово...
ПБ: Во все инструменты встроена поддержка Internet-технологий. Можно строить Web-инфраструктуру предприятия, обходясь только Delphi. То же самое можно сделать при помощи C++Builder или JBuilder. Когда мы говорим с корпоративными заказчиками, речь заходит прежде всего об интеграции информационной системы предприятия; например, решением может быть разработка Web-интерфейсов для объединения разноплатформенных ресурсов предприятия.
МА: Наш новый генеральный директор пришел как раз из мира Internet (Дейл Фуллер в свое время был директором компании WhoWhere?, поглощенной впоследствии Lycos. - И.Л.). Можно предположить, что Internet будет уделяться больше внимания, чем раньше. Сейчас мы много говорим про многозвенные архитектуры, но они очень близки к современным Internet-технологиям.
А что вы скажете по поводу другого писка моды - языка расширяемой разметки XML? Что делается в этом направлении?
ПБ: Мы внимательно следим за всем, что связано с XML. Если добавить к нашим продуктам соответствующие дополнительные возможности, мы тут же сделаем это.
Но не сейчас?
ПБ: Это вопрос приоритетов. Сейчас XML не на повестке дня. Как только потребуется, мы сразу же займемся этим. Можно интегрировать XML в InterBase, а можно говорить о том, что InterBase должна поддерживать XML, - это совершенно разные задачи. Одна - задача для наших инженеров, другая - скорее вопрос взаимодействия с независимыми разработчиками приложений.
Итак, InterBase - окончательный выбор, больше никаких СУБД приобретать или разрабатывать не нужно?
ПБ: Это на самом деле вопрос технологический. Сейчас, например, у нас есть мысли по поводу реляционных СУБД на Java. Мы присматриваемся к соответствующим технологиям. Или, скажем, наше руководство придет к выводу, что необходима объектная СУБД. Потребуется новая технология.