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

Холодная война между 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

Согласно одному из толкований Карра, все ИТ коммодитизированы, а источником конкурентных преимуществ они могут служить только с точки зрения лидерства по издержкам (экономии на них самих), а следовательно их нужно отдать на аутсорсинг провайдеру, способному сократить стоимость ИТ за счет масштабов. Из-за этого обобщения, коммунальный подход представляется излишне универсальным и незаслуженно низведенным в разряд нерелевантного для бизнеса. В действительности же, загнанный в угол, Карр признается, что "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

В своих "размышлениях о судьбе стартапов", Иван Бегтин затронул близкую мне тему: что определяет успех стартапа. 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

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

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

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

technorati tags: utility computing

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

technorati tags: soa

Как я упомянул в предыдущем посте, 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 началось и по-русски. Сколько ни пишут журналы на эту тему, дискуссии никак не получается. И только с появлением 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

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

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

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

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

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

technorati tags: longtail, utility computing, ondemand, saas

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 кардинально отличается от подходов вендоров традиционных корпоративных приложений.

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