Добрый день, господин Розенберг! Меня зовут Сергей Кузнецов. Сейчас я представляю компанию ЦИТ Форум, которая здесь в России поддерживает крупнейший сайт, научно-техническую библиотеку по информационным технологиям. Мои личные интересы в основном связаны с технологией баз данных, но я интересуюсь и информационными технологиями вообще. Большое Вам спасибо за то, что Вы согласились дать мне это интервью. Я постарался подготовить вопросы, касающиеся не столько базовых технологий компании Oracle, сколько новых веяний, которые существуют в этой компании. С Вашего разрешения я начну задавать Вам вопросы.

Как мне кажется, в последние годы, может быть, в последние пять-шесть-семь лет немного изменилась ситуация с разделением труда в индустрии программного обеспечения. Раньше было больше специализации, т.е. такие компании, как Oracle, IBM, Informix и т.д. производили базовые программные средства для управления данными. Такие компании, как BEA Systems, Logic Works и т.д. обеспечивали промежуточное программное обеспечение (middleware): мониторы транзакций, системы управления очередями и т.д. В последние годы ситуация как-то изменилась, и все большее число крупных компаний, таких как Microsoft, IBM, Oracle, производит крупные программные комплексы, которые включают в себя очень много разнообразного программного обеспечения. Мой первый вопрос: имеются ли у этого процесса технические причины, или они, большей частью, обусловлены маркетинговыми соображениями, например, стремлением к убыстрению и упрощению выхода на рынок новых продуктов? Чего здесь больше?

Вы совершенно точно заметили (и не Вы первый заметили это), что этот процесс действительно происходит. Я пришел в Oracle непосредственно из BEA Systems, где я провел четыре года. Так что я хорошо знаю этот процесс в том виде, в котором он происходил там. И, естественно, IBM и все крупные производители сегодня пытаются предоставить на рынок объединенные программные средства, предназначенные для горизонтальных и вертикальных решений.

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

Это направление полностью соответствует видению крупнейших аналитиков. Например, компания Gartner Group недавно опубликовала прогноз, что в 2007 г. более 75% корпоративного программного обеспечения будет продаваться именно такими поставщиками интегрированных платформ, а не отдельными производителями каких-то конкретных компонентов. Этот процесс происходит по массе причин, как маркетинговых, так и технических. Естественно, производителю удобно иметь контроль над платформой, когда можно вложить средства и проинтегрировать компоненты сегодня, вместо того чтобы потом работать с клиентами и пытаться каким-то образом слепить систему из разных кусочков.

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

Заказчики получают огромное количество преимуществ. Теперь они должны иметь дело с одним поставщиком. Когда поддержка происходит из одного источника, клиент не должен звонить по разным телефонам и общаться с разными представителями групп технической поддержки базы данных, сервера приложений, портала, продукта поддержки безопасности или средства разработки.

Десять лет назад клиент должен был думать о том, где набрать лучшие компоненты. Он должен был звонить в Oracle по вопросам, относящимся к базам данных, в BEA - по вопросам относительно сервера приложений, в Borland - в связи со средствами разработки, в Oblix - при возникновении проблем с продуктами безопасности и в Siebel - при проблемах с приложениями.

Сегодня такие крупные поставщики, как Oracle и IBM, в меньшей степени BEA, ставят своей целью именно предоставление полного спектра решений, когда клиент может иметь дело только с одним поставщиком. В частности, Oracle за счет приобретения готовых решений (как в случае, например, с Oblix и Siebel) или разработки собственной технологии с требуемой функциональностью (например, сервер приложений и среда разработки JDeveloper) Oracle может предложить все нужные компоненты в составе единой платформы.

Я согласен, что call-центр в компании получается один, имеется одна точка входа. Но мне плохо верится, что можно обеспечить централизованную службу поддержки, потому что при наличии большого разнообразия продуктов невозможно найти двух-трех специалистов, которые смогут ответить на все возможные вопросы. Что Вы думаете по этому поводу?

С одной стороны, это действительно так. Но, с другой стороны, когда происходит цикл продажи или уже цикл поддержки, и когда люди принадлежат одной организации, между ними гораздо больше синхронности и гораздо проще коммуникации. Я, например, помню, что когда я работал в BEA, у нас имелись проблемы в понимании того, как разделить поддержку. Например, люди звонили по вопросу драйвера базы данных. BEA баз данных не предоставляла. База данных была или Oracle, или Microsoft SQL Server, или DB2. Проблема была с драйвером. С одной стороны, драйвер - это вроде бы часть сервера приложений, которая в нем работает, но, с другой стороны, это интерфейс базы данных. Сегодня по таким вопросам человек позвонит в Oracle, и ответ будет найден гораздо проще, потому что мы владеем ...

Более короткой цепочкой?

Да, более короткой цепочкой. И мы больше заинтересованы в том, чтобы не перекинуть вопрос другому поставщику, а решить все возникающие проблемы.

Спасибо. Следующая группа вопросов задевает то, что всегда интересовало меня в наибольшей степени. Я привык (в частности, на примере BEA Systems) к тому, что middleware всегда старались делать максимально, предельно независимым от конкретных систем управления базами данных, чтобы при желании можно было использовать соответствующий продукт любого производителя. Насколько глубок уровень интеграции Oracle Fusion с СУБД Oracle? Действительно ли принципиально требуется использовать именно эту СУБД?

Прежде всего необходимо разделить два понятия. К сожалению, на сегодняшний день на рынке существует некоторое непонимание различия между Oracle Fusion и Oracle Fusion Middleware. Oracle Fusion Middleware - это единая интегрированная платформа программ-посредников (если не пользоваться термином middleware), которая предоставляет набор стандартных программных сервисов, начиная от баз данных, поддержки безопасности, объектной модели, поддержки транзакций, поддержки обмена сообщениями и распространяясь на порталы, среды разработки и т.д. Это то, что называется middleware. И Oracle сегодня консолидировал все эти множественные продукты под общим названием Oracle Fusion Middleware.

Вообще говоря, во Oracle Fusion Middleware не существует жесткой привязки к СУБД Oracle, потому что, если говорить, например, о сервере приложений, являющемся частью Fusion Middleware, то этот сервер полностью соответствует стандарту J2EE 1.4, и мы можем использовать любую базу данных, для которой существует драйвер JDBC. И многие другие продукты, которые включены в платформу Oracle Fusion Middleware, как, например, продукт подержки безопасности от компании Oblix, которую мы недавно купили, тоже независимы от базы данных.

С другой стороны, в составе Oracle Fusion Middleware имеются некоторые продукты, в которых оракловская база данных зашита внутри. Для чего это сделано? Во-первых, для этого, конечно, существуют исторические предпосылки, но более важной причиной является то, что с помощью непосредственного глубокого соединения с базой данных можно обеспечить лучшую пропускную способность и т.д. Это уже не JDBC, не ODBC, а соединение напрямую, и, естественно, это дает клиентам преимущества, но, конечно, лишает их определенной степени гибкости.

Что здесь происходит? Обычно, если компонентам Oracle Fusion Middleware требуется именно оракловская база данных, то на нее не требуется отдельная лицензия, она встроена и включена в эти компоненты, а когда появляется техническая возможность замены базы данных, клиент имеет полную свободу выбора.

Хорошим примером служит BPEL - продукт для управления бизнес-процессами, workflow и предоставления общей интеграционной платформы в рамках сервисно-ориентированной архитектуры. Внутри BPEL требуется некоторая функциональность для хранения состояний. На начальном этапе в Oracle BPEL Process Manager использовалась облегченная версия базы данных Oracle. В настоящее время доступна полная версия BPEL, в которой для хранения состояния используется встроенный компонент "dehydration store", основанный на базе данных Oracle. Я знаю, что сейчас ведутся работы по раскрытию этого компонента. Это, наверное, один из немногих примеров, когда база данных действительно требуется, и требуется именно оракловская база данных, хотя, в принципе, при определенном правильном подключении можно использовать и MS SQL-server. Я не знаю, обеспечивается ли сейчас соответствующая поддержка этого продукта, но абсолютно точно могу сказать, что такие возможности будут существовать.

Другой интересный аспект состоит в том, что сам Oracle BPEL может работать на любом другом сервере приложений, не обязательно на Oracle Application Server. Т.е. идея состоит в том, чтобы все компоненты Oracle Fusion Middleware не были жестко завязаны один с другим.

Так вот, то, о чем что я сейчас говорил, - это Oracle Fusion Middleware. Что же такое проект Oracle Fusion? Это - будущее направление развития оракловских приложений, которое будет основано на Oracle Fusion Middleware. Что касается этого направления, то снова есть некоторые продукты, которые включают в себя оракловскую базу данных как необходимый элемент, потому что так они были построены исторически. И опять-таки клиент в таких случаях не должен даже задумываться о том, какая там внутри база данных, потому что она встроена в продукт, она устанавливается вместе с продуктом; это как черный ящик: он закрыт. Когда же у клиента имеется возможность сделать выбор в отношении базы данных, то этот выбор, в принципе, снова раскрыт для любых баз данных, которые существуют в настоящее время. И чем дальше оракловские приложения будут двигаться в направлении Fusion, тем больше будет происходить это раскрытие - потому что сама по себе платформа Fusion определит раскрытость оракловских приложений, потому что вся она основана на стандартах, на сервисно-ориентированной архитектуре. При использовании таких стандартов, как J2EE, для среды выполнения или объединения компонентов приложения в Web-сервисы практически не будет иметь значения, какая база данных используется, потому что все особенности конкретной базы данных будут скрываться Web-сервисами.

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

Да.

В общем, это понятно и логично. На самом деле, Вы уже частично ответили и на следующую пару вопросов: можно ли интегрировать какие-либо компоненты Oracle Fusion Middleware с продуктами категории middleware других производителей? Можно ли интегрировать решения, построенные, например, на основе Oracle Fusion Middleware и IBM WebSphere?

Что касается этого вопроса, то многие продукты, я бы сказал, практически все продукты, являющиеся компонентами платформы Oracle Fusion Middleware, вовсе не обязательно должны использоваться вместе с другими продуктами из оракловской платформы. Идея состояла в том, чтобы создать нечто подобное ресторанному меню. Т.е. да, все компоненты проинтегрированы вместе, да, все они основаны на одной общей технологии, а именно, Java, J2EE, Web-сервис, XML и т.д., но при этом большинство компонентов может работать на любом другом сервере приложений, или с использованием другого продукта поддержки безопасности, или, например, передавать данные на другой портал и т.д. И это потому, что все основано на стандартах.

Можно привести пример интеграции компонентов Oracle Portal и Oracle BPEL Process Manager. С использованием оракловского же продукта JDeveloper с помощью одного-двух кликов можно проинтегрировать бизнес-процесс и сделать из него портлет. И этот портлет будет сразу доступен через Oracle Portal. Но портлет, который генерируется этим продуктом, основан на стандартах JSR 168 и WSRP (Web Services for Remote Portlets), и благодаря поддержке этих стандартов этот портлет может быть установлен на любом портале. Естественно, и этот портал должен быть основан на стандартах, потому что иначе на нем вряд ли кто-либо сумеет что-либо разместить, кроме самого его производителя.

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

Я уже говорил, что такой фундаментальный компонент Oracle Fusion Middleware, как BPEL, прекрасно работает на всех основных серверах приложений; у нас есть клиенты, которые используют BPEL на WebLogic, на WebSphere и даже на JBoss. И практически все основные компоненты платформы Fusion Middleware могут использоваться на любых серверах приложений, в том числе и компоненты поддержки безопасности - это еще один пример, когда мы просто увидели лидера и купили компанию (Oblix), но поскольку она была долгое время независимой, то, естественно, свою технологию строила как открытую для разных платформ, и мы унаследовали от нее эту открытость.

Итак, что касается интеграции с продуктами других производителей, то если они основаны на стандартах, проблем не возникает. Это могут быть даже не официальные стандарты, а стандарты де-факто, как, например, у продукта MQSeries компании IBM. Это, может быть, и не стандарт, но у него открытый и известный интерфейс.

Я абсолютно с этим согласен, и всю жизнь, можно сказать, тоже ратовал за стандартизацию в области информационных технологий, но тогда мне хотелось бы спросить Вас: насколько Вы удовлетворены состоянием стандартизации в этой области?

Да, конечно, здесь всегда существует противоречие между тем, что хочется, и тем, что можется. И вот когда то, что хочется, отличается от того, что существует, то нужно вводить новые стандарты. Компания Oracle сегодня вовлечена во все основные комитеты по стандартизации, начиная от J2EE и кончая OASIS и W3C и т.д. И Oracle ведет огромное количество этих стандартов - и в мире J2EE, и в мире порталов и т.д. Вообщем-то, эта тема заслуживает отдельного разговора, но факт в том, что стандарты должны кем-то продвигаться, они сами по себе не возникают и сами по себе не развиваются. Когда крупные поставщики типа Oracle (так же поступают IBM, BEA и другие компании) видят спрос на рынке на определенную технологию, они, естественно, пытаются эту технологию сначала разработать, а потом внедрить ее как стандарт.

Ну что ж, мы отчетливо видем этот подход на примере процесса стандартизации технологии SQL.

Да, а потом крупные поставщики типа Oracle говорят, что мы кооперируемся c другими компаниями в области стандартов, но конкурируем в области реализации этих стандартов.

Ярким примером является BPEL. BPEL - это не оракловский стандарт, он изначально был разработан объединенной группой инженеров из IBM и Microsoft. Стандарт разрабатывался в течение 10 лет, и существовало много параллельных вариантов стандартов для управления бизнес-процессами. Например, компания BEA продвигала свой собственный стандарт, называвшийся Process Definition for Java, который они воплотили в своем продукте. Но, очевидно, люди из BEA неправильно почувствовали требования рынка и направление стандартизации, и предлагаемая ими спецификация осталась воплощенной только ими, только одним поставщиком, и сегодня они отчаянно пытаются двигаться в сторону BEPL. Естественно, это нелегко - перестроить продукт, существующий уже много лет.

В то же время, в Oracle пару лет назад поняли, что BPEL - это то, чего сегодня хотят клиенты, то, что видится как будущее направление информационных технологий в области управления бизнес-процессами и т.д. И компания Oracle приняла сознательное решение - приобретение компании Collaxa, которая в то время являлась лидером в области BPEL. Это произошло около двух лет тому назад, и на сегодняшний день BPEL является такой же неотъемлемой, фундаментальной и проинтегрированной частью Oracle Fusion Middleware, как и все остальное. Т.е. очень важно еще правильно почувствовать, куда дует ветер, в какую сторону двигаются стандарты, потому что во многих областях имеется много предложений для стандартизации.

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

Кроме того, имеется возможность инвестирования в другие привлекательные технологии и их собственной разработки. В качестве примеров можно привести продукты Oracle Enterprise Services Bus, Business Rules engine, Portal. Примером нового стандарта, продвигаемого компанией Oracle (в партнерстве с другими ведущими производителями), является Push Mail (P-IMAP). Целью этой технологии является обеспечение согласованного стандарта, позволяющего принимать сообщения электронной почты на беспроводных устройствах любого типа с так называемом режиме "проталкивания" ("push mode") (в отличие от режима "опроса" ("polled mode")). Сегодня такая технология обеспечивается проприетарным образом популярной в США компанией Blackberry. Oracle и группа других поставщиков создают технологию и продвигают стандарт, чтобы сориентировать рынок в этом направлении. Это хороший пример ситуации, когда такая большая и мощная компания, как Oracle, занимает финансовую и техническую позицию, позволяющую влиять на направление развития рынка.

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

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

Когда в начале интервью мы говорили о консолидации программных продуктов, я не затронул еще один очень важный момент, относящийся к жизнеспособности мелких поставщиков. Когда большая компания, например, крупный банк или крупный производитель автомобилей, выбирает решение для своей интеграционной платформы на много лет вперед, ее руководители хотят быть уверенными, что поставщик, с которым они имеют дело, останется в бизнесе еще 10-15 лет, и для них довольно рискованно пользоваться услугами каких-то мелких поставщиков, даже если в их технологии на сегодняшний день воплощены некоторые функциональные возможности, пока отсутствующие в продуктах Oracle или IBM. Что будет с этими многочисленными XML-репозиториями, которые существуют сегодня, завтра, через 2 года, через 3 года? Да, существует шанс, что их купит те же Oracle или IBM, и тогда все нормально, но гораздо больше шансов на то, что их просто не будет. И что тогда делать с поддержкой этих репозиториев? Особенно, если данные в них хранятся в каком-то особом внутреннем формате.

Решение о выборе программного продукта обычно принимается на уровне стратегических IT-решений и часто основывается в большей степени на бизнес-соображениях. При наличии очень многих технических возможностей, пригодных для подобного рода задач, более надежно пользоваться продуктами и услугами крупного поставщика, такого как Oracle, который с большой вероятностью останется в бизнесе еще много лет и будет с большим или меньшим успехом предоставлять корпоративные решения, лидировать в этой области наряду с компаниями IBM, HP, Microsoft - естественно, никто из них тоже не уйдет из бизнеса в ближайшее время.

В то же время, компании среднего уровня, даже такие, как BEA, сегодня теряют темп развития именно потому, что они не в состоянии быстро реагировать на требования рынка. Они не в состоянии так распоряжаться бюджетом, так планировать свои разработки как, например, это может делать компания Oracle, которая сегодня может вложить гигантскую сумму, например, в телекоммуникационный рынок (Oracle очень сильно продвигается в область предоставления телекоммуникационных решений). А что значит вложить средства? Это значит купить какие-то компании, являющиеся ключевыми производителями каких-то конкретных функций, которые могут сразу поставить нас в лидирующую позицию. Кроме того, нужно еще вложить огромные деньги в создание новой внутренней команды разработчиков, которая реализует недостающие функции. Более мелкие производители просто не могут себе это позволить.

Около трех лет назад мне пришлось участвовать в нескольких попытках инициации проектов автоматизации бизнес-процессов в российских государственных организациях. Тогда у меня создалось впечатление, что российские государственные структуры не готовы к принятию технологий уровня workflow. Что думают по этому поводу в Oracle сегодня?

Боюсь, что я не в курсе всех деталей. Может быть, мне поможет присутствующий здесь Владимир Алексеев, руководитель направления Oracle Fusion Middleware Oracle СНГ?

Владимир Алексеев: В секторе государственных структур соответствующие технологии Oracle активно продвигает компания Форс.

Насколько я понимаю, речь идет о некотором проекте для московского правительства. Мне кажется, что в Москве ситуация все-таки проще, чем в других регионах России.

В.А.: Да, этот проект базируется на BPEL, и, конечно, Москва во всех отношениях - и в отношении финансов, и в отношении общего уровня используемых информационных технологий, и в отношении общего понимания технологических потребностей - находится на более высоком уровне, чем большинство других регионов.

Вадим Розенберг: Я думаю, что так или иначе российские государственные структуры воспримут технологию автоматизации бизнес-процессов, поскольку это общемировая тенденция. Еще раз повторю, что мне трудно оценивать состояние российского рынка, но я могу привести характерный пример из жизни государственных ведомств США.

Одним из наших клиентов являются Вооруженные силы США (US Army), которые могут конкурировать с российским правительством по уровню бюрократии, распределенности управления и т.д. Они внедрили BPEL для управления всеми своими жилыми, складскими и промышленными ресурсами. Все процессы по выделению ресурсов, утверждению распоряжений, определению текущего местоположения и т.д. реализованы на основе BEPL. И мне кажется, что этот вариант использования BPEL очень похож на те, которые требуются правительственным организациям.

В.А. Да, у нас имеется много примеров. В частности, в администрациях нескольких голландских городов, включая Роттердам, тоже внедрена технология BPEL для работы с населением, управления бизнесом. И я думаю, что в России это должно начинаться именно с крупных муниципальных образований, таких как Москва и Санкт-Петербург. Их правительства опробуют технологию, определят то, что их устраивает, и то, что нуждается в доделках, и станут лидерами, способствующими распространению технологии автоматизации бизнес-процессов в регионах.

Подходя к концу нашей беседы, мне очень бы хотелось услышать от Вас о ключевых преимуществах, которые обеспечивает Oracle Fusion Middleware, может быть, в сравнении с продуктами основных конкурентов.

Хорошо, начнем с компании Microsoft. Microsoft действительно предоставляет довольно обширные и хорошо проинтегрированные решения. Я бы сказал, что степень интеграции решений Microsoft в их платформах может служить примером для всех, включая Oracle: лучше проинтегрировать просто невозможно (конечно, я говорю про MS Office и среду Windows). Почему так сложилось и какие у этого недостатки? Я думаю, что ответить на этот вопрос очень просто. Когда поставщик имеет дело с одной операционной системой, с одним типом аппаратуры, с одной кодовой линией практически для всех продуктов, то вопрос интеграции как бы решается сам по себе, но это отрицательно влияет на открытость и на возможность внедрения разного рода лучших решений. Если ты становишься клиентом Microsoft, то это надолго, разве что ты примешь какие-то абсолютно радикальные решения что-то полностью изменить. Ты становишься зависимым и по линии аппаратуры, и по линии операционной системы, и т.д.

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

Да, продукты Microsoft, конечно, могут сегодня исполняться на разного рода blade-серверах и мультипроцессорных системах, но опять-таки все это ограничено Windows, это все изначально, глубоко внутри основано на тех же решениях, которые используются для домашних компьютеров. Я не уверен, что квалифицированные заказчики захотят управлять авиалинией, или банком, или сталелитейным заводом с помощью, в общем-то, немного расширенного, немного улучшенного, но все-таки домашнего компьютера. Конечно, это может звучать как преувеличение, но, тем не менее, когда речь заходит о высокобезопасных, высокопроизводительных, масштабируемых системах, мы слышим от клиентов, что в этой области компания Microsoft еще не готова к конкуренции с другими крупными производителями и вряд ли и будет готова когда-то в будущем, потому что вся историческая линия развития компании состоит в поддержке индивидуальных пользователей или малого и среднего бизнеса.

Что касается компании IBM, то она тоже может послужить в некотором смысле примером - по обширности решений, по охвату разного рода вертикальных рынков и т.д. Т.е. компания IBM, в принципе, наиболее близка к Oracle в том смысле, что у нее тоже можно проследить решения от базы данных до интегрированных платформ middleware. IBM проигрывает Oracle в отношении уровня интегрированности своих решений. IBM тоже частично шла по пути консолидации путем покупки компаний, но вопрос интегрированности меньше стоял на повестке дня, был менее приоритетным, чем у Oracle.

Можно, например, сказать, что семейство продуктов WebSphere, в действительности проинтегрировано только путем использования общего названия. В частности, продукт MQSeries, хотя теперь и называется WebSphere MQ, был и остается продуктом, который изначально был написан на языке Cobol с некоторыми вставками на языке C и с миром Java общается с помощью внешнего тонкого интерфейса.

Другим примером может служить Tivoli. Этот продукт происходит из мира корпоративного управления, а теперь его предлагается использовать совсем в других целях.

В отличие от этого, Oracle Enterprise Manager разрабатывался совместно не только со многими компонентами Oracle Fusion Middleware, но и со средствами управления базами данных и Grid. Такого уровня интегрированности в IBM нет.

Кроме того, IBM очень сильно полагается на свои консалтинговые службы, очень многие продажи производятся через эти службы. В отличие от этого, Oracle тесно сотрудничает с массой независимых консалтинговых служб по всему миру, с которыми IBM конкурирует. Oracle помогает своим партнерам в тех случаях, когда клиенты считают, что стандартное решение Oracle не полностью удовлетворяет их требованиям, или когда стандартные средства Oracle не могут обеспечить достаточно быстрый цикл разработки. Подход IBM, обязывающий заказчиков работать с собственными консалтинговыми подразделениями компании, ограничивает возможности клиентов.

Компания BEA Systems тоже заслужила почетное место в мире программного обеспечения, ориентированного на поддержку бизнеса. Компания создала лучший для своего времени сервер приложений, WebLogic. Но к сегодняшнему дню они отстали. Отстали в отношении поддержки стандартов, в некоторых направлениях выбрали неверный путь развития, из-за чего и отстали, и теперь им приходится нагонять, как в случае с упоминавшимся ранее BEPL. А может быть, это связано с тем, что компания все-таки небольшая, и у нее не хватило мощности вложить ресурсы в некоторое направление, где они могли бы развить большую скорость в предоставлении решений, чем другие крупные поставщики. Сегодня вообще серьезно стоит вопрос о выживании компании, поскольку у нее имелся очень большой спад в то время, когда у всей отрасли наблюдался подъем.

Сервер приложений BEA Systems продолжает оставаться в группе лидеров, но сервер приложений Oracle по многим параметрам к нему приблизился, а по некоторым и превзошел. То же можно сказать и про WebSphere. Т.е. WebLogic во многом утратил уникальность своих достоинств, и сегодня, в лучшем случае, занимает не более одной трети общего рынка серверов приложений. Технология серверов приложений к настоящему времени уже настолько отшлифована и стандартизована, что клиент, выбирая между серверами разных поставщиков, обращает внимание на массу других вещей: перспективы дальнейшего существования компании, наличие родственных продуктов у этого же производителя и т.д. И поскольку BEA в свое время не приложила усилия к созданию дополнительного бизнеса, то при утрате лидирующей позиции на рынке серверов приложений она просто не может предложить ничего нового.

Монитор транзакций Tuxedo тоже давно ушел в прошлое, на его основе уже не ведутся новые разработки. В результате компания BEA все больше переходит в область обслуживания ранее проданных продуктов, что для софтверной компании является почти приговором. В то же время, рост объема продаж Oracle Fusion Middleware сегодня является рекордным для всего этого сектора рынка.

Теперь я получил ответы на все свои вопросы. Я очень Вам благодарен и думаю, что Ваше интервью будет интересно для многих наших читателей.

---

Вадим Розенберг (Vadim Rosenberg), Директор по стратегии развития и архитектуре Oracle Application Server Suite, Штаб-квартира корпорации Oracle в США

Вадим Розенберг более 15 лет занимается разработкой, проектированием и маркетингом инфраструктурного ПО и бизнес-приложений. Являясь директором по стратегии развития и архитектуре Oracle Application Server Suite, Вадим концентрируется на решении проблем в таких областях, как сервисно-ориентированная архитектура, моделирование и автоматизация бизнес-процессов, grid-технологии и другие инновационные направления разработки и интеграции корпоративных приложений.

До прихода в Oracle Вадим Розенберг в течение 4 лет работал в компании BEA, занимаясь маркетингом и стратегиями продаж сервера приложений WebLogic Server. До этого, работая инженером в компании Compaq Computers (в подразделении Mission Critical Servers, созданном в результате приобретения компании Tandem), Вадим занимался разработкой отказоустойчивой и масштабируемой J2EE-структуры и систем обмена сообщениями. В начале 90-х годов он работал IT-консультантом в одной из крупнейших сетей супермаркетов Северной Америки Safeway Stores, а до этого - разработчиком программного обеспечения в компании Fourth Dimension Software, где занимался созданием приложений по бронированию мест для индустрии путешествий.

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

В начале ноября 2005 г. Вадим Розенберг приезжал в Москву, чтобы принять участие в Oracle TechForum. Пользуясь случаем, мы взяли у него интервью.

В начало