«Нарождающаяся «волна сервисов» будет иметь разрушительный эффект — услуги, по самой своей сути масштабируемые на сотни миллионов пользователей, радикально изменят природу и стоимость решений, предоставляемых как крупному, так и мелкому бизнесу», — написал в одном из своих меморандумов Билл Гейтс. Этот документ был разослан сотрудникам компании Microsoft 30 октября 2005 года, когда прочное утверждение сервисного подхода в индустрии программного обеспечения уже можно было считать свершившимся фактом, хотя истинный масштаб его грядущих последствий до сих пор осознан далеко не всеми.
Концепция программного обеспечения как сервиса (Software as a Service, SaaS) сегодня вызывает неподдельный интерес у архитекторов, разработчиков, поставщиков и пользователей программных продуктов, что отражается как в изменении стратегий ведущих поставщиков программного обеспечения, так и в высоких темпах роста данного рыночного сегмента. Вместе с тем и сегодня концепция SaaS порождает немало скепсиса, вызванного как ее незрелостью, так и терминологическими разночтениями.
Хорошо забытое старое?
Ключевым моментом концепции SaaS является отказ от традиционной модели установки программного обеспечения у заказчика. Отныне за его инсталляцию, обеспечение высокой готовности, своевременное обновление версий и т.п. отвечает внешняя компания-провайдер, предоставляющая клиентам услугу доступа к программному продукту. Приложения, предлагаемые по модели SaaS, находятся на удаленном сервере и арендуются пользователями, а поставщик дистанционно осуществляет их поддержку одновременно для множества клиентов. Браузер оказывается единственным клиентским программным средством, которое потребуется пользователю, а это означает существенное смягчение требований к конфигурации его компьютера.
Данный подход радикально отличается от привычной схемы, в соответствии с которой после приобретения лицензии пользователь становится полноправным обладателем программного продукта. Как с архитектурной, так и с финансовой точки зрения поставка ПО в качестве сервиса знаменует смену парадигмы в индустрии программного обеспечения. По мнению ряда экспертов, эта смена началась примерно три года назад, хотя многие возразят, что идея аренды программного обеспечения зародилась еще в первой половине 90-х годов. В самом деле, поставщики SaaS-решений внешне мало отличаются от провайдеров услуг аренды приложений (Application Service Provider, ASP). Идея ASP пользовалась большой популярностью, а среди отечественных участников этого рынка самым известным, пожалуй, является группа компаний IBS с проектом Data Fort. Однако прошло немного времени, и нежизнеспособность модели ASP стала очевидна.
Различия между двумя концепциями станут очевидны, если присмотреться к деталям — и прежде всего в области архитектуры приложений. Компании, работавшие по модели ASP, по сути, просто перепродавали услугу хостинга ПО заказчикам, которые по тем или иным причинам не хотели устанавливать его в своих организациях. Архитектура приложений при этом не претерпевала каких-либо изменений. Это приводило к тому, что начальные и текущие затраты на хостинг программ, каждая из которых использовалась только одним клиентом, для большинства ASP-провайдеров оказывались непомерно высокими, а возможности компенсировать их путем повышения стоимости предоставляемых услуг были небезграничны. Как следствие, многие ASP-провайдеры не смогли удержаться в этом бизнесе.
Принципиальным моментом в модели SaaS является разделяемый доступ множества пользователей к единственному экземпляру приложения. Такая архитектура позволяет провайдеру повысить эффективность использования вычислительных ресурсов, одновременно снизить расходы на приобретение и сопровождение ПО. Платой за повышение эффективности является необходимость строго разграничить данные разных пользователей и обеспечить их надежную защиту. Сегодня эту проблему можно считать решенной. Две ключевые особенности модели SaaS — совместный доступ к коду и разграничение пользовательских данных — метко соединил в своей метафоре Питер Граф, вице-президент по маркетингу корпорации SAP, назвав модель SaaS «изолированным членством».
Другие различия между концепциями ASP и SaaS являются прямым следствием отмеченной разницы в архитектуре. Разделяемый доступ к единственному экземпляру приложения означает огромный размер потенциальной клиентской базы поставщиков SaaS-решений, предлагающих по приемлемым ценам доступ к прикладному ПО. В модели ASP расширение клиентской базы требует значительного наращивания ресурсов, что не позволяет удержать стоимость услуг аренды приложений на конкурентоспособном уровне. В результате для клиента снижение затрат на само программное обеспечение (по сравнению со стоимостью покупки лицензии) оказывается незначительным.
Преимущества модели SaaS
Различия между моделями SaaS и ASP становятся еще очевиднее, если проанализировать выгоды, которые сулит смена парадигмы использования ПО заказчикам и поставщикам программных решений.
Для заказчика эта смена означает резкое сокращение начальных инвестиций, которые при традиционном сценарии связаны с приобретением лицензий. Определенная экономия возможна и в дальнейшем, поскольку модель SaaS предполагает гибкие схемы оплаты предоставляемых услуг. На практике пока встречаются случаи, когда клиент вносит фиксированный платеж за услугу вперед на продолжительный период, но все большее распространение получают схемы, при которых оплата производится помесячно, да еще с учетом числа пользователей, которые работали с тем или иным приложением, продолжительностью их работы и востребованной функциональности. В результате у организации появляется возможность контролировать и регулировать уровень текущих расходов на программное обеспечение. Более того, по мере развития бизнеса изменения бизнес-процессов или ситуации на рынке организация-заказчик имеет возможность подписать своих сотрудников на новые функции, доступные в рамках используемого SaaS-решения, либо, напротив, отказаться от возможностей, потребность в которых отпала.
Отказ от приобретения лицензий и инсталляции ПО на собственных вычислительных мощностях позволяет значительно сократить размер корпоративной ИТ-инфраструктуры, развертывание, эксплуатация и модернизация которой отнимают значительные ресурсы. Это означает новое распределение статей корпоративного ИТ-бюджета (рис. 1). В традиционной схеме львиная доля расходов связана с аппаратными средствами и с профессиональными услугами, а средства на ПО нередко выделяются по остаточному принципу. Благодаря существенной экономии на других статьях расходов модель SaaS позволяет основную часть бюджета направить именно на ПО в виде оплаты услуг доступа к приложениям по требованию (рис. 1 б).
Высокая масштабируемость современных SaaS-решений позволяет тестировать надежность и производительность приложений по требованию в рамках ограниченных пилотных проектов, а затем постепенно расширять их внедрение. Согласно результатам опроса корпоративных заказчиков, проведенного компанией Cutter Consortium, существенное сокращение сроков внедрения и снижение расходов на инфраструктуру — два основных стимула к переходу на модель SaaS (рис. 2).
Внесение ежемесячной платы за пользование услугой доступа к приложению, как и за любой иной сервис, предоставляет свободу в смене как продукта, так и провайдера. Конечно, такая смена может быть сопряжена с затратами на переобучение пользователей, с необходимостью переноса данных и их преобразования к новому формату, однако отказ от текущего решения уже не является фатальным. Для пользователей этот факт имеет принципиальное значение, особенно когда речь заходит о крупных корпоративных системах. Приобретению программного продукта предшествует мучительный процесс выбора решения и поставщика, а также длительное согласование контракта, приводящие, как свидетельствуют результаты исследований, проведенных компаниями Standish Group, KPMG и Business Imrpovement Architects, к тому, что более чем в 50% случаев проекты терпят фиаско либо внедренные системы не оправдывают ожиданий заказчиков. Другими словами, в половине случаев финансовые, временные и людские ресурсы тратятся впустую. Многие организации принимают решение оставить внедренную систему и молчаливо мирятся с тем, что она оказалась далека от оптимальной, а когда терпению приходит предел, они решаются заменить прежнюю систему на новую, зачастую не соответствующую индустриальным стандартам либо опять же не способную полностью удовлетворить их запросам.
При переходе на модель SaaS ситуация меняется радикально. Если приложение не оправдало возлагавшихся на него надежд, то подписчик перестает вносить ежемесячную плату либо инициирует пересмотр условий контракта с поставщиком. Многократное снижение финансовых рисков, а также смягчение проблемы интеграции приложений приводит к сокращению цикла выбора продукта, упрощению согласований, ускорению процесса внедрения. Необходимость в услугах дорогостоящих консультантов отпадает вовсе либо соответствующую статью расходов удается заметно сократить.
Данные изменения благоприятно сказываются и на бизнесе SaaS-провайдеров — помимо эффекта масштаба и значительного расширения клиентской базы провайдеры получают возможность сократить цикл продаж. Другое преимущество состоит в появлении постоянной обратной связи с пользователями и возможности организовать непосредственный мониторинг производительности и функционирования ПО, предоставляемого в качестве сервиса. В традиционной модели замечания, высказанные заказчиком по поводу недостатков продукта, либо пожелания о расширении его функциональности учитываются разработчиком на протяжении нескольких месяцев или даже лет. В модели SaaS, благодаря «короткой» обратной связи с разработчиками, замеченные ошибки устраняются оперативнее, а постоянный анализ мнений пользователей относительно используемого продукта позволяет работать над совершенствованием последнего практически непрерывно. Наконец, плоды этой работы становятся доступны пользователям значительно быстрее, чем в случае приобретения лицензий. Поставщики услуг SaaS обновляют версии своих продуктов чаще, причем во многих случаях переход на новую версию происходит прозрачно для пользователей. Некоторые разработчики SaaS-приложений за последние годы выпустили более 20 основных версий и десятки мелких ежемесячных расширений своего ПО.
Переход на новую модель помогает решить проблему пиратства (поскольку приложение выполняется на серверах провайдера), а значит, сократить размер недополученной прибыли.
Оборотная сторона медали
Снижение начальных инвестиций, а также расходов на обновление версий, загрузку файлов исправлений, управление конфигурационными изменениями и другие виды поддержки еще не означает, что заказчик получит выигрыш в долгосрочной перспективе. Опыт использования приложений по требованию реальными заказчиками свидетельствует о том, что по истечении определенного времени расходы в сервисной модели оказываются выше, чем в традиционной. Прикладная система при этом по-прежнему не является собственностью заказчика. Последнее обстоятельство может стать непреодолимым препятствием на пути перехода к новой парадигме, ведь во многих организациях финансовые службы крайне неохотно выделяют бюджеты на приобретение продуктов, которые не включаются в активы компании.
Высокая масштабируемость SaaS-решений имеет свои негативные последствия. Поскольку доступ к одному экземпляру ПО предоставляется значительному числу пользователей (зачастую из разных организаций), вопрос о специальной настройке его конфигурации и функциональности под нужды конкретного заказчика даже не возникает. Такая настройка может затронуть пользовательский интерфейс, но не более того. Другими словами, SaaS-решение представляет собой массовый продукт, на базе которого провайдер имеет возможность реализовать ограниченный набор услуг. Применение подлинной многопользовательской архитектуры, которая предполагает доступ сразу нескольких пользователей к единому экземпляру приложения и хранение их массивов данных в одном экземпляре базы данных, размещенной на оборудовании провайдера, не позволяет предоставить заказчикам (особенно крупным) каких-то уникальных конкурентных преимуществ. Таким образом, в соответствии с известным правилом «20 на 80» те 20% характеристик, которые отличают компанию от конкурентов, SaaS-решениями не покрываются.
Впрочем, считать ли это серьезным недостатком модели SaaS — большой вопрос. По мере того как информационные технологии проникают во все «ткани» современного бизнеса, а функциональность решений сопоставимых продуктов разных производителей неуклонно сближается, информационные технологии вообще перестают быть конкурентным преимуществом, превращаясь в жизненно необходимый инструмент ведения бизнеса (Kaplan J.M. SaaS Appeal Growing. Cutter Consortium Executive Update, 2006, v. 7, No. 21.). Следовательно, потребности в «отстройке» от конкурентов будут по-прежнему заставлять предприятия обращаться к поставщикам традиционных прикладных систем, поскольку они обладают опытом работы на конкретном вертикальном рынке и способны реализовать в своих решениях более широкую функциональность с учетом изменяющихся бизнес-процессов, пронизывающих различные подразделения компании. В конечном счете многие предприятия сделают выбор в пользу смешанной модели.
Но здесь обнаруживаются проблемы технического характера. Хотя схема SaaS избавляет ИТ-службу заказчика от множества рутинных операций, она все равно требует очистки данных, тестирования и интеграции систем, обучения пользователей и ряда других технических и организационных мероприятий. В частности, при использовании смешанной модели крайне актуальной становится проблема интеграции SaaS-решений с приложениями и данными, находящимися у заказчика (включая маршрутизацию и защиту возникающих между ними информационных потоков), а также необходимость адаптации таких решений к внутренним бизнес-процессам.
Проблема интеграции встает остро и в другом контексте. Гибкость в выборе программных продуктов, которую принесла с собой модель SaaS, позволила отдельным организациям перейти на схемы модульных и децентрализованных закупок ПО, осуществляемых не ИТ-отделом, а менеджерами, отвечающими за текущие операции в бизнес-подразделениях компании. В результате разные структурные единицы для решения аналогичных задач начинают использовать разные SaaS-решения, которые по-разному обрабатывают накопленные в организации данные и т.п. Потеря контроля над этим процессом может привести к тому, что задача консолидации данных превратится в самостоятельный дорогостоящий проект.
Вообще пользовательские данные в модели SaaS являются настоящим камнем преткновения. «Кому принадлежат наши данные и как поставщик распорядится ими в будущем? Кто гарантирует защиту и целостность данных и несет ответственность за нарушение конфиденциальности? Что произойдет с данными после расторжения договора с провайдером?» Видимо, заказчик должен сформулировать для себя четкие ответы на подобные вопросы, прежде чем затевать переход на схему SaaS. С другой стороны, если речь не идет о конфиденциальной информации, то местонахождение данных, как и наличие в собственном офисе стопки инсталляционных компакт-дисков, не так уж и важно. К тому же перенос данных на площадку провайдера позволяет сократить расходы на их резервное хранение и достичь интеграции с ИТ-системами партнеров. Примечательно и то, что именно перенос данных на внешнюю площадку заставил некоторых заказчиков всерьез задуматься о создании и реализации в собственной компании программы обеспечения непрерывности бизнеса.
Наконец, стоит упомянуть об организационной стороне дела. Далеко не все ИТ-менеджеры будут в восторге от идеи поступиться частью своих полномочий в области ИТ, положившись на способность внешнего провайдера обеспечить безупречную работу центра обработки данных. Определенный скепсис, особенно у представителей крупного бизнеса, вызывает способность SaaS-провайдера гарантировать практически непрерывную доступность предоставляемого сервиса, зафиксировав соответствующие обязательства в контракте об уровне обслуживания (SLA).
Развенчивая мифы
Опасения по поводу перерывов в предоставлении услуг вполне объяснимы, однако сегодня мнение о невысокой надежности сервиса следует скорее отнести к числу мифов, возникших в связи с аббревиатурой SaaS. Это мнение зародилось и укоренилось под влиянием продолжительных сбоев в предоставлении услуг SaaS, которые возникли на рубеже 2005-2006 годов у одного из пионеров этого рынка — компании Salesforce.com. Однако с тех пор сбои сопоставимого масштаба не наблюдались ни с сервисами Salesforce.com, ни с сервисами других провайдеров, так что события двухлетней давности стоит считать скорее исключением из правил.
Другой миф гласит, что SaaS-решения ориентированы только на мелкий и средний бизнес, поскольку крупные компании предпочитают использовать решения, обеспечивающие гибкую адаптацию под их потребности. В действительности на схему SaaS сегодня все активнее переходит и крупный бизнес, подобно другим компаниям заинтересованный в эффективной автоматизации рутинных операций и передаче на аутсорсинг непрофильных видов деятельности. Как показывает практика, пользователем сервиса SaaS может стать организация любого размера. Например, Salesforce.com сообщает о том, что среди ее клиентов постоянно растет число компаний из списка Global 2000 либо являющихся владельцами известных брендов, включая AOL, Avery Dennison, Nokia, Perkin-Elmer и SunTrust. Аналогичная ситуация наблюдается среди заказчиков Click Commerce и других SaaS-провайдеров.
Наконец, третье заблуждение заключается в том, что якобы на модель SaaS может быть переведен лишь узкий круг горизонтальных приложений, прежде всего программы для конечных пользователей и средства обслуживания клиентов. Эта точка зрения опровергается непродолжительной историей развития рынка SaaS-решений, а также выходом на него крупнейших мировых производителей программного обеспечения.
Перспективы
Рынок SaaS еще не достиг той точки, в которой традиционная модель потеряла бы свою актуальность, но первоначальная стадия пройдена. Уязвимость данных и информационных систем, недостаточная гибкость SaaS-решений, проблемы с производительностью и большие времена отклика — вот лишь часть факторов, которые обусловят живучесть традиционной модели использования ПО на протяжении долгих лет. И все же вряд ли кто-то возьмется оспаривать то, что рыночный сегмент SaaS успешно миновал точку возврата. Скажем, компания Salesforce.com, возникшая в 1999 году, сегодня обслуживает более полумиллиона пользователей из 25 тыс. организаций, а ее годовой оборот вплотную приблизился к 500 млн долл.
Своим первоначальным успехом модель SaaS обязана преимуществам, которые получают индивидуальные пользователи, однако сейчас неподдельный интерес к ней проявляют крупные компании. Со временем эта тенденция будет только усиливаться. Исследования аналитических фирм Gartner, AMR Research, Aberdeen, Saugatuck Research и THINKstrategies указывают на то, что уже через пять лет четверть всех корпоративных прикладных систем будет использоваться в соответствии с моделью SaaS, в то время как сегодня эта доля составляет считанные проценты. Среднегодовые темпы роста данного рыночного сегмента существенно выше темпов увеличения продаж лицензий по традиционной модели, и это различие вряд ли можно отнести к разряду случайных.
В каталоге SaaS-решений (www.saas-showplace.com) сегодня имеются все основные категории программных продуктов, причем каждой из них соответствует список из нескольких поставщиков. Жесткая конкуренция между производителями ПО начинает распространяться и на рынок приложений по требованию, что будет способствовать совершенствованию их архитектуры, повышению качества, расширению функциональности и снижению цен, а значит, уменьшению скепсиса заказчиков в отношении SaaS-решений со стороны.
Поставщики и продукты
До недавнего времени модель SaaS применялась преимущественно для автоматизации деятельности менеджеров по продажам (Sales Force Automation, SFA) и управления отношениями с клиентами (Customer Relationship Management, CRM). Однако успех первопроходцев этого рыночного сегмента в лице NetSuite, Salesforce.com и RightNow заставил традиционных поставщиков других категорий ПО пересмотреть свои взгляды на портфель предлагаемых решений. В результате стали набирать вес SaaS-системы управления логистическими цепочками (Supply Chain Management, SCM) – об этом прямо свидетельствует внушительный список пользователей программного обеспечения Demand Chain Management компании Click Commerce. Затем, в дополнение к средствам проведения Web-конференций от WebEx (сегодня им уже пользуются более 2 млн. подписчиков), список SaaS-решений пополнили антивирусные продукты McAfee, Symantec, Trend Micro и других компаний.
Сегодня на схему SaaS переведены практически все категории горизонтальных прикладных программ (рис. A), по модели SaaS предоставляется доступ к платформам для вертикальных приложений, да и сами эти приложения активно предлагаются (рис. Б) поставщиками нишевых продуктов (Kaplan J.M. Spreading SaaS: Horizontally and Vertically. Cutter Consortium Executive Update, 2007, v. 8, No. 4.). Согласно данным компании Forrester Research, по состоянию на середину 2006 года примерно четверть организаций на Западе уже использовали модель SaaS для работы с отдельными приложениями, еще около 10% находились на стадии пилотных проектов либо планировали их инициировать (Bartels A., Rymer J.R. The Future Of Enterprise Software. Forrester Research, June, 2006).
Ведущие производители приложений в лице SAP, Oracle и Microsoft время от времени пытаются приписать популярность модели SaaS не объективной потребности в смене парадигмы индустрии ПО, а умелой работе маркетологов из компаний-первопроходцев. В действительности рост спроса на приложения по требованию настолько велик, что традиционным поставщикам корпоративного ПО волей-неволей придется пересмотреть свою стратегию и перевести часть предлагаемых решений в архитектуру SaaS. Достаточно назвать гибридные многопользовательские продукты CRM On Demand от SAP и Siebel CRM On Demand от Oracle, а также Microsoft Windows Live, Microsoft Dynamics CRM Live (который, по заявлению производителя, непременно будет переведен на полноценную многопользовательскую архитектуру) и Microsoft Office Live – онлайновые двойники сегодняшних приложений Microsoft для ПК. Активность на рынке SaaS-решений проявляют также Business Objects, IBM, Progress Software и даже компания Google, выпустившая в 2007 году пакет приложений Google Apps.
Несмотря на бытующее мнение о том, что новая парадигма индустрии ПО подрывает бизнес поставщиков традиционных решений, крупные разработчики корпоративных приложений вряд ли смогут долго игнорировать преимущества модели SaaS. Не последнюю роль в их числе играет предсказуемый график получения дохода – в противоположность циклическому и трудно прогнозируемому поступлению средств при традиционных продажах. В модели SaaS стоимость ежемесячной подписки несравненно меньше стоимости лицензии, однако за «время жизни» одного подписчика на подобные услуги производитель получает такой же, если не больший, доход. Впрочем, отдельные компании (SAP, Oracle) пытаются придерживаться «золотой середины» – ряд SaaS-продуктов предлагается ими как составная часть традиционных программных решений. Подобное смешение жанров, а также выход в сегмент SaaS крупнейших мировых разработчиков ПО дал повод некоторым аналитикам говорить о размывании границ между традиционными программными продуктами и приложениями по требованию (рис. В).
Расширяющееся распространение SaaS-решений создало дополнительные рыночные ниши. Одна из них постепенно заполняется фирмами-агрегаторами – компаниями, которые не создают SaaS-приложения сами, а специализируются на хостинге продуктов сразу нескольких разработчиков и предоставлении доступа к ним пользователям со всего мира.
Другую нишу образуют компании, которые занимаются поддержкой внедрения приложений по требованию. Иногда можно услышать, что продажа SaaS-решений аналогична продаже звуковых треков в формате MP3. На самом деле представление о том, будто, подписавшись на требуемое ПО, пользователь может сразу же приступать к работе, плохо согласуется с действительностью, особенно если речь идет о сложных корпоративных системах класса ERP, CRM, SCM и т.п. Как правило, сам SaaS-провайдер не располагает достаточными ресурсами для содействия процессу внедрения, а поддержки в онлайновом режиме зачастую оказывается недостаточно. Например, у компании Salesforce.com в ряде стран, где находятся ее заказчики, нет даже торгового представителя. Здесь-то и открывается широкое поле для деятельности сервисных компаний, специализирующихся на поддержке внедрения SaaS-решений. Надо ли говорить, что при смене провайдера или продукта их услуги будут востребованы вдвойне. Примерами компаний, уже развернувших деятельность на этом поприще, могут служить Saaspoint, обслуживающая клиентов Salesforce.com и Business Objects, Cap Gemini, помогающая пользователям приложений Google Apps Premium Edition, а также многочисленные региональные партнеры компании NetSuite.
Экосистемы SaaS
Многие SaaS-провайдеры, несмотря на стремительное развитие своего бизнеса в последние годы, осознали, что для успеха в долгосрочной перспективе необходимы принципиально новые шаги. Основную угрозу для себя они усматривают в массовом характере предлагаемого сервиса: функции, реализованные в приложениях по требованию, без труда могут быть воспроизведены традиционными поставщиками ПО. В результате в сегмент SaaS проникла далеко не новая идея создать сообщества независимых разработчиков (Independent Software Vendor, ISV), которые были бы способны значительно расширить возможности SaaS-решений и тем самым повысить их привлекательность в глазах пользователей.
Как и подобает пионерам рынка, первой на этот путь вступила компания Salesforce.com, создав экосистему AppXchange, позднее переименованную в Apex. Сегодня Apex объединяет более 300 ISV и около 500 программных продуктов, заметно расширивших исходные возможности разработки от Salesforce.com. Идея, изначально положенная в основу платформы AppXchange, состояла в предоставлении как партнерам, так и клиентам компании возможности создавать, распространять и продавать готовые приложения, функционирующие в хост-среде Salesforce.com.
Создание экосистемы Apex преследовало и другую задачу – поломать имидж поставщика решений класса CRM/SFA, который сформировался за годы деятельности Salesforce.com, и выйти на другие рыночные сегменты. Компания уже наладила сотрудничество с поставщиками BI-решений и средств интеграции данных (Business Objects, Informatica, Pervasive Software), решений для управления схемами стимулирования сотрудников (Centive, Xactly, Cellarstone, Perks.com), средств конфигурирования прикладных систем и управления взаимоотношениями с партнерами (Selectica, Comergent, Webcom, Big Machines, Firepond). А компании, примкнувшие к экосистеме Apex недавно, все чаще склоняются к разработке услуг для финансового и смежных секторов экономики.
В декабре 2006 года Salesforce.com представила сообществу Apex стратегию AppStore. Речь идет о формировании единой среды для тестирования, приобретения и развертывания приложений по требованию, объединяемых платформой Apex. Предполагается, что AppStore позволит раскрыть истинный потенциал платформы Apex и одноименной партнерской программы, заметно ускорить разработку, вывод на рынок и продажи практически любого приложения по требованию. Утверждается, что благодаря AppStore приобретение таких приложений клиентами будет столь же простым, как покупка мелодий в сервисе iTunes. Разработчики же избавятся от необходимости содержать штат продавцов и формировать собственные каналы продаж. Наконец, глобальные инкубаторы AppXchange помогут компаниям создавать новые продукты на платформе Apex, а также будут способствовать развитию бизнеса существующих партнеров Salesforce.com.
Вслед за появлением экосистемы Apex аналогичный шаг сделала и NetSuite — в 2006 году компания представила новую платформу разработки приложений SuiteFlex, адресовав ее своим реселлерам. Последние теперь могут поверх системы управления бизнес-процессами NetSuite создавать для клиентов собственные вертикально-ориентированные приложения, а также заказные интегрированные пользовательские интерфейсы. Разработки, созданные на новой платформе, впоследствии будут предлагаться заказчикам в качестве онлайновых приложений по требованию. Компания выпустила также пакет Suite Bundler, который сам позиционируется в качестве SaaS-решения и позволяет партнерам NetSuite реализовывать на программном уровне и встраивать непосредственно в систему NetSuite лучшие индустриальные практики.
Успехи первых проектов по созданию экосистем инициировали создание аналогичных экосистем вокруг SaaS-платформ других производителей. Подобные проекты анонсировали либо уже начали реализовывать IBM, Microsoft, Oracle, Progress Software и WebEx (в партнерстве с Cordys – известным поставщиком средств разработки, внедрения и интеграции приложений на базе архитектуры SOA).
Компоненты архитектуры SaaS
Архитектура SaaS-приложения во многом напоминает другие категории программных продуктов, разрабатываемых в рамках сервисного подхода (см. рисунок). Сервисы процессов формируют интерфейсы, вызываемые интеллектуальными клиентами или функциями уровня Web-преставлений, а также инициируют синхронные потоки данных или долговременные транзакции, которые вызывают бизнес-сервисы. Последние, в свою очередь, взаимодействуют с хранилищами данных и выполняют операции извлечения либо записи бизнес-данных. Сервисы безопасности осуществляют функции контроля доступа к приложению со стороны конечных пользователей и программных сервисов, запущенных на сервере. Наконец, предоставление услуг доступа к SaaS-приложению требует появления уровня разделяемых сервисов, нацеленных на поддержку текущих операций управления предоставляемыми услугами (OSS) и их тарификации (BSS).
Основное отличие приложений по требованию от традиционного ПО заключается в наличии сервисов метаданных, при помощи которых можно настроить особенности функционирования приложения с учетом потребностей сотрудников конкретной компании. Поскольку доступ к одному экземпляру ПО могут иметь тысячи пользователей, работающие в разных организациях, метаданные становятся единственным, хотя и ограниченным, механизмом персонификации SaaS-решения.
В процессе взаимодействия с сервисами метаданных интеллектуальные клиенты и другие сервисы извлекают информацию о конфигурации и расширениях, специфических для конкретного предприятия или его отдельных бизнес-подразделений. Как правило, настройка конфигурации затрагивает четыре области: пользовательский интерфейс, бизнес-правила и потоки работ (в плане их соотнесения с существующими бизнес-процессами), контроль доступа и расширения модели данных. Перечисленным областям соответствует иерархическая структура конфигурационных единиц (scopes), формируемая пользователем по принципу «сверху вниз». Он же может задать принципы наследования значений конфигурационных параметров дочерними единицами у родительских (либо их замещения).
Модель данных должна обладать гибкостью и допускать адаптацию своей структуры к уникальным потребностям организаций или отдельных пользователей. При этом изменения, вносимые в модель данных одним пользователем, не должны затрагивать модели, используемые другими. Существует три подхода к решению этой задачи.
В простейшем случае для каждого корпоративного заказчика создается отдельный экземпляр базы, а сервис метаданных отслеживает соответствия, установленные между организациями и экземплярами базы. Этот подход предоставляет пользователям максимальную гибкость и автоматически решает задачу разграничения данных разных пользователей, но одновременно оказывается наименее эффективным с точки зрения использования вычислительных ресурсов.
Второй сценарий сводится к созданию единой базы данных с разделяемым доступом и заранее фиксированным числом настраиваемых полей, которые пользователи могут задействовать по своему усмотрению. Типы настраиваемых полей могут быть заданы заранее, что позволяет включить механизмы автоматической проверки их содержимого, либо оставаться неопределенными. Модель базы данных с разделяемым доступом намного экономичнее предыдущего сценария, но ее главный недостаток состоит в ограниченной расширяемости — на этапе проектирования базы практически невозможно определить оптимальное число настраиваемых полей, которые будут востребованы пользователями.
Наконец, третий подход сочетает разделяемый доступ к единственному экземпляру базы с предоставлением пользователям права произвольным образом расширять модель данных. Практически неограниченная возможность ее модификации обеспечивается за счет хранения парных записей «имя — значение» в отдельной таблице. В этом случае каждая запись, содержащая настраиваемые пользовательские данные, получает уникальный идентификатор, которому может соответствовать одна или несколько парных записей в дополнительной таблице. В этом сценарии типы пользовательских данных не требуется определять заранее, что означает максимальную свободу в настройке и расширении исходной модели данных при сохранении высокой эффективности. Серьезным недостатком третьего подхода является усложнение функций поиска, индексации, обработки запросов и обновления содержимого записей. Кроме того, любое расширение модели данных неизбежно требует изменения бизнес-логики и логики представления данных.
