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

Links for 2008-06-06 [del.icio.us]

Sat, 07 Jun 2008 00:00:00 PDT

The Innovator's Dilemma
Chapter One of Clayton Christiansen's classic.

Links for 2007-11-07 [del.icio.us]

Thu, 08 Nov 2007 00:00:00 PST

Facebook недополучил инвайт от Google

noreply@blogger.com (Daniel Feygin) — Sun, 04 Nov 2007 14:32:07 PST

Холодная война между Google и Facebook за будущее Веба обрела конкретные очертания. Facebook подвергнется разоружению со стороны альянса EBFB (Everyone But Facebook). События развивались настолько стремительно, что еще за 36 часов до анонса не все члены альянса осознавали, что они к таковым относятся. MySpace до последнего утверждал, что строит собственную закрытую альтернативу FBML и Facebook API. Тем не менее, ближайшие интересы альянса связаны именно с MySpace, как обладателем наибольшей активной пользовательской базы. Также свою социально-сетевую сторону открыли в себе Salesforce.com и Oracle, присоединение которых к альянсу демонстрирует его более отдаленное будущее (и более индикативно о будущем корпоративных приложений).

Под бравым предводительством Google яльянс совершил ожидавшийся, но, тем не менее, окутанный стратегическим туманом маневр. Обструкция была создана штатным IT-вооружением: стандартом. В данном случае, EBFB и его предводитель придумали спецификацию, описывающую интерфейс социальной сети (каковой может являться почти любой портал) для интеграции в нее приложений третьих сторон, предоставляемых удаленно. Успех операции обеспечивает ее широкая поддержка, небезосновательно позволяющая членам альянса рассчитывать на переманивание разработчиков приложений Facebook на свою сторону. Цементируя успех, спецификации было присвоено гордое название OpenSocial API.

Оставим пока в стороне технические аспекты OpenSocial (с опубликованными материалами я ознакомился, Orkut sandbox испробовал и готов поделиться своими впечатлениями). Больший интерес вызывает другое.

Истинную мотивацию маневра раскрывают, даже скорее обнажают (учитывая PR), условия использования спецификации. Не подумайте, что речь в соглашении идет о каком-то конкретном сервисе Google, ее реализующем, это не так. Речь в нем идет о самой спецификации. И согласно этим условиям, Google вправе устанавливать правила игры по своему единоличному усмотрению. И эти правила могут быть направлены против кого угодно в любой момент. Чтобы не пугать людей, можно было конкретизировать: имеются в виду, конечно, только те, кто угрожает будущим доходам Google. Это те, кто не вошел в изначальный состав альянса -- Facebook, Microsoft, Yahoo.

Вызывает сомнение, что launch partners подписали то же соглашение, что предлагается прочим смертным. Осмелюсь предположить, что в их версии TOS исключается любой наезд на любого из подписантов по поводу поддержки OpenSocial. Также в нем должно упоминаться, что Google номинируется подписантами на роль администратора публичного TOS и, соответственно, (это уже не упоминается) палача неугодных, если таковые окажутся среди пользователей OpenSocial. Так что рассуждения на тему вступления Facebook в этот клуб при текущем раскладе абсолютно беспочвенны. Наверняка Microsoft поделится со своим младшим братом прискорбным опытом баталий с Sun вокруг Java и соответствующего соглашения. (Вспоминается, что в Sun нынешний CEO Google заведовал направлением Java, которое удивительно схожим образом боролось с Microsoft.)

Заодно замечу, что Google обычно тщательно скрывает любые свои инициативы, не объявленные официально. В случае с OpenSocial слухи стали просачиваться незадолго до подписания Facebook инвестиционного соглашения с Microsoft. После подписания стало известно, что Facebook поднимает раунд у других инвесторов, исходя из нововмененной капитализации $15 млрд. Очевидно, что утечки и перенос официального анонса OpenSocial на более раннюю дату могут быть связаны с попыткой Google повлиять на эти процессы.

Легко быть хорошим в благоприятных обстоятельствах. Истинный же характер проверяется в сложных. Хочется верить, что в ходе доработки всего проекта OpenSocial TOS претерпят существенные изменения, в результате которых условия использования API не будут единолично контролироваться одной компанией.

technorati tags: opensocial, social networking, web 2.0, google, facebook, microsoft, yahoo

Links for 2007-08-01 [del.icio.us]

Thu, 02 Aug 2007 00:00:00 PDT

InfoQ: Service Composition
Excellent examination of service composition strategies/architectures/approaches.

Links for 2007-04-25 [del.icio.us]

Thu, 26 Apr 2007 00:00:00 PDT

BizTalk Labs
Home of BizTalk Services
» The next frontier: Infrastructure as a service? | Between the Lines | ZDNet.com
"I don't want bodies. I want a service with clear costs"
» My SaaS deployment is bigger than yours … | Software as services | ZDNet.com
Providers claim 6-figure seat numbers for individual SaaS deployments.
James Governor’s Monkchips » Why IBM Should Acquire Amazon
Not your average bolt-on acquisition, but the idea is not without merit.
» Microsoft to help other software vendors go the SaaS route | All about Microsoft | ZDNet.com
Microsoft makes another step in building its SaaS ecosystem.
» Is Microsoft’s Cloud OS actually a Cloud DB? | All about Microsoft | ZDNet.com
According to rumor Microsoft team is building multi-tenant storage platform (a.k.a. CloudDB) and "new distributed OS" (a.k.a CloudOS). True or not, they better be!

Коммунальная модель ИТ в конкурентной стратегии фирмы

noreply@blogger.com (Daniel Feygin) — Fri, 23 Mar 2007 09:53:25 PDT

Согласно одному из толкований Карра, все ИТ коммодитизированы, а источником конкурентных преимуществ они могут служить только с точки зрения лидерства по издержкам (экономии на них самих), а следовательно их нужно отдать на аутсорсинг провайдеру, способному сократить стоимость ИТ за счет масштабов. Из-за этого обобщения, коммунальный подход представляется излишне универсальным и незаслуженно низведенным в разряд нерелевантного для бизнеса. В действительности же, загнанный в угол, Карр признается, что "IT is ... one place to look for things [that can distinguish companies from their competitors]".

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

Под инфраструктурой будем понимать сервера, системы хранения, СУБД и прочее неприкладное обеспечение. Отнесем туда же всевозможные процессы и ресурсы, связанные с их обслуживанием: планирование, закупка, установка, администрирование, защита, обновление, резервное копирование, disaster recovery, электропитание, охлаждение/отопление, provisioning/deprovisioning (подключение/отключение доступа) и т.п. Коммунальная инфраструктура, объединяющая множество клиентов и приложений на одном виртуализированном экземпляре платформы, может быть новой платформой для создания и предоставления приложений, какую бы роль в стратегии компании они не занимали -- вопрос исключительно наличия инструментов и целей.

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

Аналогично и с ИТ. Часто Вам приходилось слышать, чтобы очередной сервер Dell/HP/IBM/Sun/Google (шутка, пока...) был предметом гордости бизнеса? Для провайдера коммунальной инфраструктуры выбор собственных ресурсов (в т. ч. людей) и правильная их сборка (в т. ч. процессы) безусловно будут источником преимуществ. Для клиента же аналогичным образом будет важно то, какие приложения и как он будет использовать на этой инфраструктуре. И здесь, кстати, мы в полном согласии с Карром, который наиболее последовательно во всех своих прокламациях, фактически, призывает к поиску преимуществ в бизнес-процессах. Например, вот товарищ вполне стратегическим образом использует платформу как услугу (семинар), поселив на ней бизнес-процессы своей компании.

В результате появления такой коммунальной платформы, доступ к первоклассным инфраструктурным технологиям существенно расширился. Теперь любой малый бизнес обеспечен ИТ-инфраструктурой, превосходящей по надежности и масштабируемости подавляющее число mission-critical систем Fortune 500. Что делает инфраструктурную часть ИТ еще менее вероятным источником конкурентных преимуществ (для их конечных пользователей), чем раньше.

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

ИТ, как и любые другие технологии, всегда коммодитизировались и всегда будут коммодитизироваться с течением времени (т. к. в их основе лежит интеллектуальный вклад, т. е. фиксированные издержки, ergo marginal revenue ~= profit). По мере расширения числа коммодитизированных категорий ИТ, пользователям будет доступен все более широкий спектр ИТ. Это, в свою очередь, только расширит возможности создания конкурентных преимуществ на основании того, как организация использует доступные ей технологии, то есть в совокупности с какими другими технологиями, в интересах каких бизнес-процессов и как именно. И модель поставки, SaaS или в коробке, никак на это не влияет. Влияет только доступность приложений, которую SaaS обеспечивает гораздо лучше.

technorati tags: utility computing, saas, on demand

Links for 2007-03-17 [del.icio.us]

Sun, 18 Mar 2007 00:00:00 PDT

Gartner Says Service Providers Must Prepare Now for the Software as a Service Wave
Gartner's press release announcing its 2006 SaaS research and forecast. Very thoughtful, instructive and un-PR-like.
Carolina SaaS User Group
Charlotte's local SaaS user group, organized by Hosted Solutions.
Repealing the SaaS Tax
Apprenda's CEO Sinclair Schuller does a great job explaining the emergning concept of and the rationale behind the SaaS platform.

Факторы успешности стартапов

noreply@blogger.com (Daniel Feygin) — Tue, 06 Mar 2007 03:06:48 PST

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

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

Все крупные корпорации всегда обладали профессионализмом, иначе они бы не стали крупными. Можно, впрочем, различным образом ранжировать их по степени профессионализма, как, например, в Good To Great. Но нельзя сказать, что Microsoft или Oracle внезапно поумнели к 2000-м годам (динамика их капитализации на фоне поведения рынка -- раньше и теперь -- говорит скорее об обратном). При этом они не всегда и не во всем были успешнее стартапов.

Приобретение -- это почти всегда не успех, а признание провала для приобретателя. Наглядный пример: YouTube, который обошелся Google в $1.65 млрд. (в известном эквиваленте). Собственный аналог, Google Video, по всем показателям, в том числе опережающим, уступал YouTube, хотя, в отличие от последнего, был запущен с помпой в Лас-Вегасе с достойными контент-партнерами, обеспечившими начальную критическую массу контента ("голову" кривой "длинного хвоста"). YouTube одолел Google Video, помимо приема пиратского контента и прочих тактик, недоступных Google, хитроумно просочившись в MySpace.

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

Что касается технологий, то фактор их преемственности IMHO слабо влияет на перспективы приобретения, если только речь не идет о приобретении собственно технологий. В редких случаях стартапы создаются с целью продать технологии (кстати, продать PageRank до создания компании пытались Page и Brin, но покупателя не нашлось, и в результате они коммерциализировали технологию самостоятельно). Когда покупают готовый бизнес или продукт, технологическая преемственность играет самую последнюю роль, после превеликого множества других факторов. Известно множество примеров, подтверждающих это, таких как Hotmail или Writely.

Напрашивается вывод: технологии нужно выбирать наиболее соответствующие задаче и команде, а не предполагаемому приобретателю. Тем более, что стратегия выхода, в которой значится конкретный и единственно возможный вариант, сильно ограничивает и стратегию, и valuation. Мечтать, вопреки расхожей поговорке, бывает весьма вредно, поскольку естественная человеческая тенденция выдавать желаемое за действительное (wishful thinking) лишь превращает человека в заложника своих желаний и отнюдь не способствует построению успешного бизнеса.

Более того, выбор стартапом любой proprietary технологии в большинстве случаев неоправдан, поскольку создает для возможных приобретателей (для всех, кроме одного) технологическую зависимость от конкурента. Этот фактор куда значительней технологической преемственности. Так, вряд ли активизировавшаяся в отношении M&A Microsoft будет с энтузиазмом смотреть на перспективу покупки решения, базирующегося на GWT или Berkeley DB (кстати, компания называлась Sleepycat).

technorati tags: startup

Links for 2007-03-02 [del.icio.us]

Sat, 03 Mar 2007 00:00:00 PST

W3C Workshop on Web of Services for Enterprise Computing
Discussion of mutual influences that Web and WS-* might have on each other in the future, convergence vs. divergence, tradeoffs in composition vs. linkability, service level assurance vs. simplicity, etc.

Yoohoo! Google поселится в Северной Каролине.

noreply@blogger.com (Daniel Feygin) — Wed, 24 Jan 2007 04:21:08 PST

Не далее чем 31-го декабря, направляясь встречать 2007 год в Аппалачах, проезжал я через северокаролинский городок Lenoir, что в предгорье тех самых Аппалач. И не догадывался я, какая судьба уже была заготована этому ничем не примечательному центру "сельской культуры" и, не исключено, рассаднику ку-клукс-кланства. Все мои небогатые познания этой местности -- а я несколько лет жил в Северной Каролине -- находили подтверждение в ее внешнем облике: закрытые мебельные и текстильные производства, заброшенные склады, признаки реднеческого жизненнего уклада. И только присутствие выбивающихся из пейзажа Wal-Mart и шарлоттского Belk указывало на наличие здесь контингента, так и не вернувшегося к натуральному хозяйству после ухода отсюда производственных предприятий -- преимущественно в Мексику и в Китай.

И вот, как оказалось, уже тогда в Lenoir была отведена земля под очередной data-центр Google на восточном побережье. Промышленный спад региона и его обилие водными ресурсами (рафтинг повыше в горах -- супер!) оказался как нельзя кстати для Google, считающего стоимость электропитания и охлаждения своих data-центров сравнимой со стоимостью их начинки. Падающая стоимость MIPS в обозримой перспективе выведет стоимость эликтричества, растущую и в абсолютном выражении, в разряд определяющих эксплуатационных расходов.

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

technorati tags: utility computing

10 принципов SOA от Stefan Tilkov

noreply@blogger.com (Daniel Feygin) — Sat, 16 Dec 2006 06:12:58 PST

Stefan, широко известный в узких кругах, составил свой список принципов SOA. Также рекомендую посмотреть более раннее интервью с ним.

technorati tags: soa

SOA и адаптивность

noreply@blogger.com (Daniel Feygin) — Tue, 12 Dec 2006 12:27:37 PST

Как я упомянул в предыдущем посте, SOA следует модели бизнеса, его архитектуре. Если ценность объектной ориентации основывается на том, что объекты могут представлять реальные предметы, то ценность сервисной ориентации основана на том, что сервисы могут представлять то, чем занимаются компании. Таким образом сервисная ориентация сближает бизнес и его IT-отражение (бизнес -> сервисы -> технологии; "->" означает глагол drive(s)).

Анатолий Тенцер справедливо обратил внимание на потребности бизнеса, определяющие в нашем деле. Бизнес же, по крайней мере тот, который в классификации вендоров относится к enterprise, по природе своей децентрализован. В противном случае он парализован. При этом он имеет тенденцию развиваться, если не сказать больше. Управляемость IT, к сожалению, обычно обратно пропорциональна как степени децентрализации, так и скорости изменений. Как же SOA, по определению децентрализованная, учитывает эти требования и сглаживает противоречия?

Короткий ответ: слабая связанность. Ее реализация может основываться на сочетании различных средств и методов.

1. Контракты. Понятие контракта в SOA трактуется несколько шире, чем обычно (например, в CORBA контракт, как правило, исчерпывается IDL -- техническим описанием интерфейса объекта), играя более значимую, если не определяющую роль (контрактно-ориентированная архитектура?). Контракт определяет условия предоставления и потребления сервисов, включая функциональные, технические (не только протокол, но и, например, способ авторизации, QoS) и прочие (стоимость, гарантии) параметры и служит основой соглашения между потребителем и провайдером сервиса на всех этапах его жизненного цикла. Не даром одно из распространенных определений провайдера и потребителя сервисов базируется на том, кто из них контракт предоставляет (провайдер), а кто принимает (потребитель).

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

Контракты не только ограничивают зависимости между элементами архитектуры, но, что не менее важно, делают их явными, овеществленными объектами управления. Постоянное изменение различных участков SOA, таким образом, становится возможно именно благодаря контрактам.

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

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

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

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

Тем не менее, реестр выполняет очень важную функцию в рамках регулирования (governance) SOA, вне зависимости от того, используется он в runtime или нет.

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

Здесь мы вынужденно опускаемся на технологический уровень, поскольку возможность такая для инструментально поддерживаемых прикладных протоколов приобрела распространение лишь с появлением XML в паре с XML schema (душещипательные истории про хаки с расширением IDL-описаний, работающих только для конкретного ORB, пускай даже по стандартному IIOP, не принимаются, т.к. ни стандартными ни поддерживаемыми не являются) и протоколов на его основе. Описание же интерфейса на базе XML schema может содержать абсолютно стандартные wildcard-компоненты, прекрасно используемые валидаторами и в разной степени поддерживаемые всевозможными инструментальными средствами и платформами. Вкупе с определенными подходами, можно реализовать довольно гибкую схему, не ломающую при добавлении новых элементов ни промежуточные звенья, ни какую-либу из взаимодействующих сторон.

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

В качестве примера приведу SOAP, основанный на этом принципе. Все протоколы из серии WS-* являются именно такими расширениями заголовка SOAP-конверта, XML-схема которого содержит wildcard и атрибут булевского типа mustUnderstand, определенный для элементов-расширений. Если расширение с mustUnderstand="true" приходит SOAP-обработчику, не понимающему данный заголовок, то он может корректно сообщить об этом отправителю сообщения, отказавшись от обработки. Если же mustUnderstand="false", то расширение можно игнорировать без опасности утраты критической информации.

5. Перестраивание. Расширяемость -- хорошо, но недостаточно. По хорошему, интерфейс всегда должен быть максимально полным, да и основных проблем управления изменениями расширяемость не решает. Поэтому, рано или поздно, интерфейс приходится менять, адаптировать к измененным бизнес-требованиям. Какие процедуры при этом запускаются каждая компания (в лице ответственного IT-менеджера) сама определяет для своей организации, в зависимости от множества факторов, не последний из которых -- баланс логичности/интуитивности в стиле принятия решений. Для более стабильных организаций характерна бо́льшая регламентация процесса изменений, для более гибких -- меньшая. Каждый регулирует свои изменения подстать себе, руководствуясь -- чем же еще? -- требованиями бизнеса.

Сто́ит отметить, что далеко не все нынешные инструментальные средства помогают в достижении слабой связанности. Они, например, имеют тенденцию по описанию интерфейса генерировать клиентский код так, что тому при инициализации известен адрес и свойства сервиса на момент генерации этого кода. О каком слабом связывании может идти речь? Для его обеспечения приходится добавлять собственный слой обнаружения и инициализации, вполне генерируемый тем самым инструментальным средством либо же упаковываемый в используемый технологический стэк (платформу).

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

Но ни один продукт в принципе не может "сделать SOA", архитектуру нельзя купить в коробке. Продукты -- только средства, причем довольно далекие от архитектуры. Чтобы их эффективно применять (или осознанно не применять), полезно сначала представить себе желаемый результат, отталкиваясь не от конкретных продуктов, а от необходимых свойств архитектуры.

technorati tags: soa

SOA и бизнес

noreply@blogger.com (Daniel Feygin) — Sun, 03 Dec 2006 06:00:25 PST

Предметное обсуждение SOA началось и по-русски. Сколько ни пишут журналы на эту тему, дискуссии никак не получается. И только с появлением ITBlogs.ru наметилась радующая тенденция.

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

Много раньше я порассуждал о разнице в моделировании объектов и сервисов, столкнувшись с несовершенством моделей программирования сервисов на самых популярных платформах. С их подходом действительно можно быстро наладить базовый Web-сервисный RPC, особенно не задумываясь об архитектуре целого решения, корректности интерфейсов, да и о сервисной ориентации вообще. IMHO это крайне странный подход, если осуществляется в рамках SOA, поскольку потребность в SOA возникает совершенно с других позиций, и первые шаги должны быть осуществлены именно в сфере проектирования.

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

Делая провайдером не систему, а бизнес, задача согласования информационной архитектуры выводится на тот уровень, на котором она теоретически решаема -- на уровень бизнеса. Мы уже говорили о том, что семантика идентичных сущностей в разных системах то и дело оказывается несогласуемой и, как следствие, информационное взаимодействие затрудняется. Согласование семантики сущностей, как и бизнес-процессов в целом, является делом бизнеса, а не IT, и ошибка, соответственно никак не в технологиях. <update>~~SOA позволяет корректно вернуть эту задачу бизнесу и получить результат, допускающий техническую реализацию.~~ Сервисная ориентация способствует конструктивному участию IT в оптимизации бизнес-процессов и получении результата, допускающего техническую реализацию.</update> Сервис (в этом контексте его еще называют "бизнес-сервис") является той самой промежуточной конструкцией соответствия (alignment'а) бизнеса и IT.

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

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

Такой двойственный характер информационного обмена в SOA служит постоянным источником противоречий, устранить которые можно только установив границы, помимо функциональных, между асинхронными бизнес-взаимодействиями верхних уровней и преимущественно синхронными сопутствующими IT-взаимодействиями более низких уровней. Лишь на самом низком уровне SOA мы приходим к т. н. "мелкозернистым" (fine-grained) сервисам, которые через RPC-вызовы включаются в бизнес-процессы для хранения и передачи состояния между ними (т.е. для осуществления учетной функции). Основная же область рассмотрения SOA лежит выше.

technorati tags: soa

Закон Мура и Экономика Изобилия

noreply@blogger.com (Daniel Feygin) — Mon, 22 Jan 2007 23:26:43 PST

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

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

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

Сами же провайдеры дальше способствуют снижению стоимости вычислений, но уже не столько за счет Закона Мура (кстати, на самом деле он Мор, а не Мур), сколько за счет повышения эффективности использования IT-ресурсов. Сетевой провайдер может обеспечить в разы более высокий средний уровень утилизации CPU, чем среднестатистическая корпорация и, тем более, индивидуальный пользователь. Это дает еще один многократный выигрыш в себестоимости технологий, но получаемый за счет архитектуры, а не плотности транзисторов. Другие выгодные прелести такой смены архитектуры связаны со снижением стоимости услуг, сопутствующих внедрению IT, таких как поддержка и обновление, не говоря об исключении ненужного посредничества в канале поставки IT. С точки зрения "экономики изобилия", стоимость поддержки одного пользователя для провайдера в долгосрочной перспективе стремится к нулю.

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

technorati tags: longtail, utility computing, ondemand, saas

Следующий Google будет построен на Amazon

noreply@blogger.com (Daniel Feygin) — Wed, 22 Nov 2006 03:46:01 PST

Amazon.com хорошо известен потребителям -- больше 60 миллионов из них Amazon считает активными. На этом сайте свои товары им предлагает свыше миллиона продавцов, помимо хозяина площадки. Но есть у Amazon и третий бизнес, целевой аудиторией которого являются разработчики. И именно в этот бизнес Amazon наиболее активно наращивает инвестиции, стремясь сделать его таким же масштабным (и, по всей видимости, low-margin), как и бизнес электронной коммерции.

Пару месяцев назад число сервисов, базирующихся на информационных и вычислительных ресурсах Amazon.com, пополнилось новинкой Elastic Compute Cloud (EC2). Благодаря EC2, любой разработчик может приобрести время на выделенном сервере или произволного размера кластере, вооружившись не более чем кредитной картой. На самом деле все сервера выделяются из пула виртуализированных машин, каждая из которых эквивалентна Xeon 1.7GHz с 1.75GB памяти. Стоимость составляет вполне конкурентоспособные $0.10 за CPU-час, соответствующие $73/месяц, не считая стоимости трафика. Более важно то, что масштабировать свой data-центр вверх/вниз можно динамично, по мере изменения нагрузки.

Таким образом, путем нехитрых манипуляций, можно не сильно напрягаясь арендовать собственный кластер с root-доступом и хорошей связью. Что делать с этим новообретенным богатством подскажет Google, который большую часть своего бизнеса держит на воспетых прессой commodity-серверах. Для этого он использует собственный технологический стэк, который был частично клонирован в рамках проекта Apache Lucene и сейчас называется Hadoop. Так вот, Hadoop примерили на EC2, и, надо сказать, они неплохо смотрятся вместе.

Для сравнения: Sun Grid Compute Utility, предназначенный именно для параллелизации вычислений в "эластичной" среде, стоит $1/CPU-час. При этом доступ к ресурсам Compute Utility осуществляется только через Compute Server API, и никаким root-доступом не пахнет. Значит эту платформу можно подключать только в качестве расширения собственных вычислительных ресурсов, от которых отказаться совсем не удастся.

Очевидно, что на EC2 можно поставить не только Hadoop, но и любой другой технологический стэк (например, LAMP или JEE) в том числе вовсе не обязательно (кстати, как и Hadoop) связанный с Web. Но теперь фанаты функционального программирования, воодушевленные успехами Google, могут получить нечто очень похожее на его инфраструктуру, если именно этого им не хватало для построения решений "масштаба Web". Ведь хорошие идеи и ресурсы не всегда находят друг друга. Спешить, однако, пока не стоит, так как EC2 (как и Sun Grid) вполне оправданно находится в бете, закрытой для публики. Но, если вам это интересно, то записаться в очередь сейчас самое время.

technorati tags: amazon, google, ec2, sungrid, mapreduce, hadoop, utilitycomputing, ondemand, haas

Модель продаж SaaS

noreply@blogger.com (Daniel Feygin) — Fri, 10 Nov 2006 04:49:18 PST

Модель продаж SaaS кардинально отличается от подходов вендоров традиционных корпоративных приложений.

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

Так на проходившем в San Jose в рамках On Demand Summit круглом столе один из участников охарактеризовал неэффективность продаж "коробочных решений" по сравнению с их Web-альтернативами.

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

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

Скорость принятия решения увеличивается еще и потому, что речь не идет об очередных не всем понятных инвестициях в IT. SaaS требует commitment не больше, чем на год, а чаще всего на месяц. Такая модель оплаты позволяет принципиально новым категориям бюджетодержателей принимать IT-решения. Так, нередко менеджеры небольших групп переводят свои отделы на SaaS пока CIO планирует инсталляцию аналогичного решения на следующий год. Согласование c CIO обходят, так как ресурсы информационной службы не задействуются, а деньги на небольшие ежемесячные отчисления можно найти в "прочих расходах", обходясь также без визы CFO. Таким образом механизм убеждения клиента упрощается донельзя: нравится -- берите, желательно у нас не спрашивая.

Демонстрации, выезды к клиенту, индивидуальные технические и коммерческие предложения уходят в прошлое, а с ними и высокая стоимость индивидуальной поддержки, на которой, собственно, и базируется прибыль вендоров бизнес-приложений. Те, кто работает по-старому, просто увеличивают расходы клиента, который за все это личное внимание (как правило, к своему CIO) в конечном счете заплатит, поделившись этой платой и с самим CIO (порой и не подозревая об этом). Полагаю, что с течением времени желающих будет становится все меньше. Более эффективные модели IT постепенно вытеснят исторически сложившиеся.

technorati tags: saas

SOA и VoIP будут вместе

noreply@blogger.com (Daniel Feygin) — Wed, 18 Oct 2006 09:43:02 PDT

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

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

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

technorati tags: voip, cti, soa, saas

Первые впечатления от Apex, новой платформы Salesforce.com

noreply@blogger.com (Daniel Feygin) — Tue, 17 Oct 2006 15:29:43 PDT

Компания 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

SaaS порождает гражданские войны в IT-компаниях

noreply@blogger.com (Daniel Feygin) — Sat, 14 Oct 2006 06:46:46 PDT

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 и перспективы ISV-партнерства

noreply@blogger.com (Daniel Feygin) — Fri, 06 Oct 2006 06:13:58 PDT

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

Gartner о размере рынка Software as a Service

noreply@blogger.com (Daniel Feygin) — Thu, 23 Nov 2006 23:04:44 PST

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

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

technorati tags: saas, forecast, gartner

WebEx Connect составит конкуренцию AppExchange

noreply@blogger.com (Daniel Feygin) — Thu, 28 Sep 2006 09:06:58 PDT

У Salesforce.com в январе появится первый серьезный конкурент в области платформ для SaaS. Именно тогда планируется выход сервиса WebEx Connect, нацеленного, как и AppExchange, на создание экосистемы приложений On Demand.

О том, что это будет именно экосистема, говорит заложенная в основу Web-сервисная платформа Cordys, заточенная под координацию бизнес-процессов и надежную передачу сообщений между приложениями. Мне удалось увидеть ее первую в истории публичную демонстрацию пару лет назад на Gartner Application Integration and Web Services Summit, где я выступал с докладом сразу после них. Можно только догадываться, насколько все ушло вперед с тех пор, но и тогда они были во многом сравнимы с такими зрелыми интеграционными платформами, как SeeBeyond ICAN (нынче Sun Java System Integration Suite).

В то же время AppExchange страдает как раз от архитектурных ограничений, не позволяющих напрямую интегрировать приложения третьих сторон друг с другом. Можно только дополнять основные прикладные продукты самого Salesforce.com, что не исключает даже коллизий между приложениями партнеров. Возможно именно о решении этих проблем и собирается сообщить Marc Benioff на своей конференции Dreamforce через 10 дней. По крайней мере завлекалка на salesforce.com обещает "the most important announcement ever in On-Demand computing," что, впрочем, вполне в их стиле. WebEx же грамотно воспользовался проходившей в том же San Francisco конференцией SaaScon, опередив конкурента со своим PR. Теперь все будут упоминать этот пре-анонс, докладывая о новостях Salesforce.com.

Судя по всему, сами партнерские приложения будут размещаться на никак не связанном с WebEx хостинге. Но и коробочные приложения, работающие непосредственно у клиентов, также можно будет подключить к Connect. Если же WebEx позволит еще и разумно тарифицировать клиентов через свою систему, то Salesforce.com получит удар сразу по двум своим самым слабым местам. Из его преимуществ останется только итеграция с собственной CRM-системой, но альтернативные ей решения вполне могут начать вырастать вокруг WebEx как грибы (SugarCRM уже заявлен в качестве партнера). WebEx делает ставку на непосредственную работу пользователей с другими людьми через Web, для чего предоставляет такие инструменты совместной работы как обмен документами, онлайн-форумы, IM и, конечно, Web-конференции. CRM же в такой схеме отводится роль лишь одной из учетных систем, которой, кстати, в этой экосистеме может теоретически стать и Salesforce.com.

Теперь стало ясно, как WebEx планирует коммерциализировать свои огромные вложения в MediaTone. Эта глобальная сеть data-центров объединена собственными технологиями передачи медиа-трафика, репликации данных и защиты каналов. MediaTone будет использоваться в качестве инфраструктуры Connect.

technorati tags: webex, appexchange, salesforce.com, saas

Как вырастить стартап

noreply@blogger.com (Daniel Feygin) — Wed, 27 Sep 2006 07:38:50 PDT

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

Универсального ответа на вопрос "как финансировать стартап?" или "как развивать стартап?" не существует. Каждый идет своим путем, и этот путь зависит от множества факторов. Однако мне кажется, что есть довольно широко применимая схема, которой я придерживаюсь.

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

Если начальных денег нет, то остается только создавать продукт собственными силами, по возможности привлекая к этому единомышленников, готовых на работу за equity. Кстати, ко мне по LinkedIn последнее время периодически поступают такие запросы; не вижу, почему MoiKrug не сможет сыграть аналогичную роль. Если собственные силы заняты на другой работе, то, увы, варианта по большому счету всего 2: либо вы от нее отказываетесь сразу (можно попробовать взять длительный отпуск или, например, уменьшить объем работы до part-time), либо для начала пытаетесь совмещать, выверяя жизнеспособность своей идеи. Истории известны успешные компании, произошедшие обоими способами, также как и неизвестно гораздо большее число компаний, так и не появившихся из-за того, что ее потенциальный создатель не нашел возможности преодолеть этот барьер.

Продукт, как правило, следует выпустить на стадии его самого минимально возможного функционирования, дающего возможность только:

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

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

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

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

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

technorati tags: startup, vc

Финансовый анализ SaaS-компаний

noreply@blogger.com (Daniel Feygin) — Tue, 26 Sep 2006 08:26:43 PDT

О преимуществах SaaS для клиентов пишут обильно и часто. Но именно эффективность этой модели для разработчика делает ее угрожающе подрывной для вендоров коробочных решений. О том, как оценивать финансовую привлекательность бизнеса SaaS-провайдера, собираются рассказать в завтрашнем (начало 27 сентября в 22:00 MSK, запись здесь) часовом вебинаре Jason Maynard, директор Credit Suisse по equity research в сфере Software и On Demand, и Jim McGeever, финансовый директор NetSuite.

Jason Maynard, один из самых прославленных инвестиционных аналитиков этого рынка, будет главным докладчиком. Я цитирую его в своих инвестиционных презентациях с 2002 года, когда он еще занимал аналогичную должность в Merrill Lynch. Там он завел вечно растущий индекс публичных SaaS-компаний и с переходом в Credit Suisse забрал его с собой. Теперь это называется Credit Suisse Software On Demand Index (CSSODI).

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

Вебинар обещает быть интересным для венчурных капиталистов, предпринимателей, и финансовых директоров, интересующихся моделями On Demand с точки зрения провайдера (не пользователя).

technorati tags: saas, vc, financing

Oracle SDP: платформа для сервис-провайдеров

noreply@blogger.com (Daniel Feygin) — Tue, 26 Sep 2006 05:34:53 PDT

Как я предсказал немногим более года назад, Oracle основательно занялся телекоммуникационным рынком. Анонсированные в апреле планы принесли первые плоды. Пока Oracle SDP -- это интегрированные на базе Oracle Fusion Middleware (sic) внешние приобретения компании: TimesTen, HotSip и Net4Call. Одно только это дало неплохой набор возможностей, среди которых поддержка IMS (в том числе SIP через JSR 116, SMS/MMS и т.п.) для создания сервисов и Java-клиент Parlay X, подходящий также для интеграции с OSS/BSS. На базе этой платформы Oracle поставляет в составе SDP "готовые" решения, среди которых значится и Virtual PBX (a.k.a. Hosted PBX), т.е. программная имитация отдельной PBX, предоставляемая провайдером.

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

Сейчас же коммуникации -- скорее средство для предоставления доступа к услугам (а не только непосредственно к другим абонентам) более высокого уровня, которых гораздо больше, чем операторов связи. Любой блог или Web-приложение в этом контексте является услугой, предоставляемой в конечном счете по каналам связи. В результате архитектурных изменений, происходящих на рынке телекоммуникационных услуг не первое десятилетие, Orace SDP может быть интересен:

Операторам связи для предоставления своим абонентам новых коммуникационных и сопутствующих услуг.
Провайдерам услуг, предоставляемых посредством телефонии и/или мобильных сообщений (SMS/MMS). Таких провайдеров, никак не связанных с владельцами каналов, сейчас гораздо больше, чем традиционных оператораторов связи. К ним относятся в том числе провайдеры дальней связи, телеконференцсвязи, доступа к контенту и приложениям (например: знакомства, органайзер/"личный" секретарь, гео-навигация, словарь) посредством голоса и/или сообщений.
Корпоративным пользователям для организации внутренней голосовой (VoIP) связи, голосовых меню (IVR), интеграции факсимильной связи и пр. Однако во многих случаях, вероятно, таким пользователям будет более интересен Oracle Collaboration Suite, в котором все эти функции выведены на более понятный IT-службам прикладной уровень.

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

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

Характерно, что Oracle избрал платформенную стратегию в отношении рынка телеком, при том что конкурирующие платформы уже существуют (например, у BEA). Можно было опираться на какие-нибудь из своих прикладных решений (а их у несчастного Oracle при последнем подсчете было целых 5 отдельных линеек), скажем, CRM и Financials, превратив их отраслевые варианты в некий аналог OSS/BSS. Однако этого пока не происходит, что говорит о заинтересованности Oracle не только в старых телефонных компаниях, но и в новых сервис-провайдерах.

technorati tags: oracle, voip, saas

Ингредиенты успешных стартапов 2006

noreply@blogger.com (Daniel Feygin) — Tue, 26 Sep 2006 00:24:28 PDT

Churchill Club ежегодно проводит круглый стол по ситуации со стартапами в Silicon Valley. Guy Kawasaki, по традиции модерировавший дискуссию, поделился записью Startup Success 2006.

Наиболее интересными ремарками отметились Reid Hoffman (LinkedIn, PayPal и др.) и Joe Kraus (JotSpot, Excite и др.).

technorati tags: startup

Венчурные капиталисты без ума от Web 2.0

noreply@blogger.com (Daniel Feygin) — Fri, 22 Sep 2006 09:48:12 PDT

По крайней мере по определению Web 2.0, используемому Dow Jones.

Очередной пузырь? Я так не думаю. На этот раз у всех на устах revenue, а не eyeballs.

technorati tags: web 2.0, vc

Google BigTable адаптивно распределяет массивы данных по Google File System

noreply@blogger.com (Daniel Feygin) — Sat, 05 Aug 2006 12:43:27 PDT

Как заметил бывший президент легендарной AT&T Labs: "нормальное индексирование перестанет работать," когда базы данных дорастут до петабайтовых размеров. Пока для большинства из нас петабайтовые массивы остаются делом будущего, сетевые провайдеры вычислений с ними сталкиваются уже сегодня. В этом контексте их пионерский опыт представляет практический интерес.

Jeff Dean довольно подробно рассказывает в University of Washington о BigTable, одной из инфраструктурных технологий Google. На ней построена в том числе реализация subversion, входящая в состав недавно увидевшего свет Google Project Hosting.

API BigTable, а может и академическая среда лекции, сильно напомнила мне известную с 1980-х распределенную модель программирования Linda. (Отличия, конечно, есть: например, BigTable использует схему данных, хотя и нежесткую, в то время как в базовой модели Linda схемы нет.)

Но еще больше API BigTable напомнил мне собственноручно разработанный API нашего продукта UnitSpace BCR. Здесь и именование "рядов", и "семейственность" атрибутов, и естественная навигация вперед-назад по хранимым сущностям. Только для их идентификации мы применяем URI (а не строку), что позволяет сегментировать пространство хранилища на отдельно управляемые иерархические разделы. И имена атрибутов также являют собой URI, привязанный к записи в общем реестре метаданных. В качестве последнего годится любой UDDI-совместимый каталог, в который же публикуются и сервисы, создаваемые путем point-and-click в административной консоли BCR и описываемые с использованием всех этих метаданных для возможного последующего динамического обнаружения и связывания. Вот вам, кстати, и слабое связывание, которым изначально была так привлекательна Linda, причем как runtime, так и design-time.

Большая же часть лекции посвящена не столько API, сколько описанию основных деталей реализации. В них тоже много интересного, но мое особое внимание привлекла архитектура "целого решения", включающая, помимо BigTable, GFS, Scheduler и Lock Service, систему параллельных вычислений MapReduce. Очевидно, что MapReduce и BigTable хорошо дополняют друг друга при реализации распределенной обработки больших массивов данных. В нашем случае таким дополнением служит BPEL (Web-сервисы, порождаемые UnitSpace BCR, идеально подходят для оркестрации).

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

technorati tags: google, bigtable, utility computing, innovation

Google вооружается против Microsoft

noreply@blogger.com (Daniel Feygin) — Sat, 12 Aug 2006 05:29:45 PDT

Как и ожидалось, Google представил на OSCON сервис по хостингу проектов с открытым кодом. Изначальную функциональную ограниченность Project Hosting авторы обещают вскорости компенсировать, вполне в духе встречающей его посетителей мантры "Release early, release often."

Хотя первое интервью было дано NewsForge, родственному SourceForge сайту, в декларируемую в нем неконкурентность существующей инфраструктуре сообщества (в первую очередь, конечно, SourceForge) блогосфере верится неохотно. Смею предположить, что Google не лукавит, и этот ход был нацелен никак не на мнимого, а на вполне реального конкурента Google.

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

Стратегия Microsoft в условиях победившего SaaS во многом зависит от успеха коробочного бизнеса, т.к. основана на синергетической связи клиент-сервер-сервис. Microsoft, как и Google, будет предоставлять в виде сервисов эксплуатируемые ей серверные решения собственного производства (например, Microsoft SharePoint Services). Но, в отличие от Google, Microsoft может предложить ту же функциональность и в упакованном виде, что дает потенциальному заказчику немаловажную мобильность между форматами on-site и off-site. Продавцам Microsoft эта особенность может быть весьма полезна: продавая очередную коробку, они теперь смогут говорить о возможности беспрепятсвенного перехода клиента на аутсорсинг, когда он будет готов к этому, а продавая сервис можно успокаивать особо неуверенных в своем выборе тем, что его можно будет легко исправить, если новая модель себя не оправдает.

Принципиальное отличие стратегии Google в том, что противопоставить серверной части стратегии Microsoft ему нечего. В этом отношении OSS может сыграть важную роль в конкуренции с Microsoft. Обращает на себя внимание степень проникновения Google в Apache Software Foundation, известную созданием популярного серверного ПО с открытым кодом (в первую очередь одноименного Web-сервера, лидирующего по числу обслуживаемых сайтов). Собственно, один из докладчиков Google на конференции является по совместительству председателем совета директоров ASF. Уровень и широта присутствия Google на этой весьма почитаемой в сообществе конференции говорит о наличии серьезных планов компании в отношении open source.

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

technorati tags: google, microsoft, opensource

Identity 2.0: страсти накаляются

noreply@blogger.com (Daniel Feygin) — Tue, 25 Jul 2006 09:19:23 PDT

Новое поле битвы в Software-as-a-Service (и Web-технологиях в целом) формируется вокруг подходов к идентификации и авторизации пользователей. Следом за централизованными каталогами появились федерации, на смену которым сейчас приходят более изощренные механизмы, с подачи Dick Hardt коллективно именуемые Identity 2.0.

Основной кулуарной дискуссионной площадкой для этих тем является созданная полгода назад рабочая группа IETF DIX (Digital Identity Exchange). Диапазон высказывавшихся изначально мнений был настолько широк, что конечная результативность DIX ставилась многими под сомнение. Однако под идейным натиском представителей Sxip обсуждение обрело конструктивный характер и постепенно перешло в техническую плоскость. Однако с момента выхода Google Account Authentication API дискуссия выплеснулась в публичную блогосферу и превратилась в PR-фиаско для Google.

Dick публично обвинил Google в том, что тот углубляет водораздел, призвав в списке рассылки IETF DIX европейского сотрудника Google Ben Laurie прокомментировать планы по интероперабельности для нового API. В то же время стали плодиться другие публикации, сравнивающие GAA с предложениями Microsoft, такими как Passport и Live ID, в весьма нелестном для Google тоне. Не смог остаться в стороне и главный идеолог и оратор Microsoft на эту тему Kim Cameron.

Основной тезис ответа Ben Laurie состоит в том, что Google ничего не объявляет заранее, а Microsoft в своих коммуникациях по поводу digital identity оперирует исключительно планами, а не реальностью. Напоследок Ben риторически спрашивает, не желает ли Dick использовать сервисы Google под своим логином Yahoo, на что Dick не без удовольствия отвечает утвердительно. Если вам интересна эта тема, то рекомендую ознакомиться с продолжением этой жаркой дискуссии: здесь, здесь, здесь, здесь, здесь и здесь.

Можно было бы считать критику Google беспочвенной, учитывая что Google Account Authentication и не задумывался компанией, как имеющий отношение к Identity 2.0. Однако именно это, похоже, и раздражает критиков, обвиняющих Google в отсутствии не только инициативы, но и декларированной стратегии в отношении интероперабельности механизмов авторизации.

technorati tags: web 2.0, digital identity, google, microsoft

Gizmo делает голосовую связь с Россией бесплатной

noreply@blogger.com (Daniel Feygin) — Thu, 20 Jul 2006 10:32:41 PDT

Как первым сообщил Andy Abramson, Gizmo запустил программу бесплатной IP-телефонии для звонков PC-to-phone. Звонить можно в 60 стран, включая Россию. Одно существенное ограничение все же есть: оба абонента должны быть зарегистрированными пользователями Gizmo, даже если звонок принимается адресатом с телефона. Каждый абонент может зарегистрировать 2 таких телефонных номера: условно-стационарный и условно-мобильный. Учитывая изобретательность экономичных пользователей IP-телефонии, можно предположить, что они сами зарегистрируют своего собеседника и позвонят ему на телефон, если того неудобно беспокоить такой мелочью.

Добавлю, что клиент Gizmo совместим с SIPNET, как и с другими SIP-сервисами и -серверами (например, asterisk), так что можно продолжать принимать звонки с существующих эккаунтов одним общим клиентом. К сожалению, к Skype это не относится.

technorati tags: voip, gizmo, skype, sip