Даниил Фейгин: мысли вслух

Наконец хоть Jon Udell выразил то, что я давно думаю и периодически пытаюсь высказать. Последний раз я эту тему упомянул в сентябре:

Еще в пике доткомовского бума я познакомился в Silicon Valley с командой, организовавшей резервирование столов в участвующих в этом проекте ресторанах с использованием телефонии. Для этого нужно было обеспечить надежное общение с рестораном в режиме real-time, получить от заведения подтверждение или альтернативное время, когда бронь возможна. Так как рестораторам было проще принимать автоматизированный телефонный звонок (за $), чем гарантировать немедленную реакцию на email, было решено использовать обычную телефонную связь. В дальнейшем эту инфраструктуру планировалось распространить на другие сферы. Возможно эта бизнес-модель прижилась бы в России, учитывая наличие здесь широкого контингента SMB, гораздо более плотно подключенного к телефонии, чем к интернету.

Но SOA -- удел большого бизнеса. Куда вероятнее что к тому времени, когда CTI будет общим местом, большинство вызовов будут инициироваться не из внутренней сети, а внешним сервисов. Google Calendar, например, уже сейчас умеет посылать напоминания по SMS (которые я хронически читаю, когда они уже неактуальны). А мог бы и позвонить, заодно получив обратную связь -- перенести встречу или отменить ее, чтобы больше не беспокоил.

technorati tags: voip, cti, soa, saas

Компания Salesforce.com, один из лидеров рынка On Demand приложений, на своей недавней конференции Dreamforce обнародовала планы развития своих прикладных решений и платформы. Ключевым элементом этих планов безусловно стала технология Apex, впервые позволившая клиентам и партнерам Salesforce.com программировать свои решения на платформе компании. Текущая версия платформы AppExchange 7.0 допускала расширение функциональности лишь на уровне информационной модели и экранных форм, а также удаленное взаимодействие с ними. Возможность обработки данных на стороне сервера появилась впервые.

Пока Apex находится на стадии закрытого бета-тестирования и используется "преимущественно" (только?) внутренними разработчиками Salesforce.com для создания ее собственных прикладных решений. Более того, сообщается, что синтаксис языка программирования почти наверняка претерпит изменения, как, возможно, и некоторые элементы модели программирования Apex. Тем более странными кажутся заявления о том, что Apex -- первый язык программирования и платформа своего рода. Как известно, NetSuite представил свой SuiteScript в апреле 2006.

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

Язык Apex обладает синтаксисом Java, полным набором управляющих конструкций (включая, например, "for" в стиле Java 5). В отличие от Java, примитивные типы, похоже, будут взаимозаменяемы с их объектными эквивалентам (т.е. int = Integer), а массивы соответствуют понятию коллекции. Более подробный обзор основных конструкций языка на данный момент содержится здесь. В отличие от NetSuite SuiteScript, основанного на JavaScript, язык Apex не динамический, а структуры данных в нем типизированные, со всеми вытекающими последствиями, в целом позитивными для сферы корпоративных приложений.

Известно, что Salesforce.com использует СУБД Oracle, которая имеет встроенную JVM для исполнения кода. Исходя из этого можно сделать некоторые предположения о механизмах реализации Apex. Вероятно, исходный код транслируется "препроцессором" Apex в Java (разворачивая, например, SOQL в соответствующий SQL, добавляя вызовы JDBC и объектно-реляционные преобразования, осуществляя auto-boxing/-unboxing и устраняя прочие несоответствия спецификации и библиотекам Java) и в этом виде загружается в СУБД вкупе с прослойкой PL/SQL. Там он компилируется в двоичный байткод и в дальнейшем исполняется.

Такой метод реализации вполне вписывается в архитектуру платформы Salesforce.com, поскольку позволяет использовать тот же способ организации схем(ы) базы данных, который прежде использовался только для реализации многопользовательской модели управления данными (кстати, отличный обзор от Microsoft на эту тему). Ведь в СУБД и код и модель данных представляются в единой метамодели -- схеме, унифицирующей эти понятия. Так или иначе, но конечной средой исполнения, судя по документации, явно является JVM. Интересно, к каким библиотекам при этом имеется доступ (как насчет java.net.*?).

Тут же выявляются первые проблемы. Во-первых, можно констатировать полное отсутствие переносимости кода с платформы Salesforce.com с более стандартную среду. Выходя на рынок через Salesforce.com, отвязаться от него впоследствии будет трудно, даже когда он будет уже не подталкивать рост, а ограничивать его относительно высокой стоимостью платформы (что всегда происходит при наличии lock-in). Во-вторых, при выпуске новой версии виртуальной машины Apex, обратная совместимость может быть утрачена. Представители Salesforce.com утверждают, что в этом случае старая версия платформы будет продолжать функционировать. В то, что поддержка старой версии платформы будет вечной (даже учитывая постоянную модель оплаты), не верится. И в этом есть некоторая уязвимость пользователей и партнеров, доверяющих свой код такого рода платформе. Платформа может утратить совместимость с их кодом и им придется переписывать код, хотят они этого или нет.

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

technorati tags: salesforce.com, apex, appexchange, sforce, netsuite, suitescript, netflex, webex, saas

Ken Rudin возглавлял подразделение Siebel OnDemand, поработал в NetSuite и salesforce.com, прежде чем основать LucidEra. На недавно завершившейся конференции Office 2.0 он поделился инсайдерским взглядом на то, как реагируют укоренившиеся компании на революцию On Demand:

На практике, они хотят выйти на этот рынок, чтобы притормозить конкурентов. Моя цель в Siebel OnDemand была остановить salesforce.com, но мы не слишком преуспели... Не делая ничего, вы медленно умираете; реагируя, вы создаете гражданскую войну внутри компании между новой и старой моделью, в результате чего умираете только быстрее.

Siebel видел в salesforce.com в первую очередь наглеца, портившего вечеринку для вендоров CRM, и в большей степени, конечно, для лидера рынка Siebel. Ведь Siebel, SAP и Oracle научились неплохо зарабатывать на своих священных коровах поддержки, обновлений и консалтинга (лицензии обычно только окупают R&D). Как объяснить акционерам, что доходы от одного клиента за каждый отчетный период впредь должны быть ниже? Это означает пересмотр всей структуры издержек, иначе, даже если Siebel останется прибыльным, рентабельность бизнеса упадет, а это приведет к пересмотру P/E -- а значит и капитализации -- в сторону понижения. В такой ситуации не только опционы окажутся под водой, но и до позорного изгнания недалеко.

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

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

Могу понять, почему Ken Rudin ненадолго задержался в должности генерального менеджера такого подразделения. Любая инициатива Siebel OnDemand должна была если не поддерживать, то хотя бы не мешать и без того стагнировавшему бизнесу коробочного ПО. Трудно упрекать его за переход в salesforce.com, где у него были развязаны руки. Как и трудно было бы упрекать любого другого человека, оказавшегося в его вполне типичном положении.

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

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

Так, например, поступил IBM, создавая Personal Systems Group. Эксперимент вполне удался, учитывая расцвет индустрии "персональных вычислений" на базе архитектуры IBM PC и оттеснение инициатора взрывной волны Apple на позиции нишевого лидера. Так поступил HP, создавая лазерный принтер. Однако эти примеры, как свидетельствует множество других, являются скорее исключениями, чем правилом. А правило состоит в том, что существующие лидеры оказываются неспособны (в первую очередь по вышеупомянутым организационным причинам) к адаптации к технологиям, подрывающим основу их бизнеса. Поэтому в связи с SaaS следует ожидать серьезных изменений в будущем составе отрасли IT.

technorati tags: saas, disruptive, ondemand, siebel, salesforce.com

Oracle все-таки выпустил собственное биллинговое решение Oracle Communications Billing and Revenue Management. Оно базируется на активах приобретенной в апреле-июне компании Portal Software. Теперь у телекоммуникационных операторов в лице Oracle появился поставщик не только технологической платформы для новых сервисов, но и прикладного решения, обслуживающего существующие. Вероятно, их интеграция будет приоритетом ближайших релизов этих продуктов (e.g, авторизация доступа к сервису на основании статуса лицевого счета).

Все это, как я упоминал раньше, не самым лучшим образом отразится на ISV-партнерах, строивших свои решения для telco на базе продуктов Oracle. Вотчиной партнеров также были отрасли розничной торговли и банковских услуг, пока Oracle не приобретел Retek и i-flex. Резонно предположить, что тенденция к консолидации на рынке коробочных бизнес-приложений и, соответственно, вытеснения ISV-парнеров крупными вендорами продолжится. Тем более, что этот рынок не ожидают особые перспективы роста.

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

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

technorati tags: saas, isv, oracle, billing

На Software as a Service (SaaS) в 2005 году пришлось 5% всех доходов от реализации ПО для бизнеса. К 2011 году доля SaaS в этом сегменте возрастет до 25%.

Не верите мне? Тогда читайте пресс-релиз Gartner.

technorati tags: saas, forecast, gartner