Между предоставлением ПО как услуги (Software as a Service, SaaS) и сервисно­ориентированной архитектурой (SOA) нет обязательной связи: не являются редкостью потребители и провайдеры SaaS, не развернувшие у себя SOA, так же как и предприятия, где SOA есть, но в ее рамках связываются только внутренние сервисы. Однако эти развивающиеся сейчас подходы к предоставлению функциональности прикладных систем позволяют полностью раскрыть свой потенциал только в сочетании друг с другом.

SааS минус SOA равняется ASP

По мнению аналитиков, модель SaaS сейчас стремительно развивается: так, согласно отчету Gartner в 2005 году на долю программ, предоставляемых как услуги, приходилось лишь 5% всего рынка ПО для бизнеса, а к 2011­му этот показатель должен вырасти до 25%. По­видимому, новый подход успешнее предыдущего, применявшегося так называемыми ASP (Appliccation Service Providers): из­за ограничений по масштабируемости и гибкости бизнес ASP оказался малоприбыльным, и многие из них его свернули. «Всё зависит от того, есть ли у вас окружение для работы со многими заказчиками или нет, — говорит Филипп Винсент, один из партнеров компании Accenture, консультирующей поставщиков ПО по вопросам SaaS. — ASP первого поколения предлагали обычное ПО по запросу в среде, рассчитанной на единственного заказчика, и не слишком преуспели. По сути это лишь аутсорсинг управления приложениями, их обслуживания и предоставления по запросу».

Решение проблем ASP стало возможным благодаря переводу их ИТ­архитектуры на рельсы SOA. Провайдеры SaaS, вооруженные SOA, могут обслуживать тысячи и даже десятки тысяч клиентов с помощью единственного экземпляра приложения, и используемые ими архитектуры позволяют им очень эффективно масштабировать, гибко видоизменять и развивать свое ПО. «Поставщики SaaS должны быть способны предложить нечто настолько гибкое, чтобы отвечать нуждам клиента, но вы не можете делать это эффективно без очень хорошей модели SOA, — считает Филипп Винсент. — Если у них недостаточно гибкости, чтобы обеспечить ту функциональность, которая вам нужна, или они не в состоянии интегрироваться с другими вашими приложениями значительно быстрее, чем это удалось бы при классической инсталляции соответствующего ПО, значит, то, что они предлагают, в действительности скорее всего не SaaS».

Поставщик ПО как услуги компания RiskMetrics предпринимает переход на SOA, чтобы улучшить обслуживание 650 с лишним пользователей, подписанных на ее ПО для анализа финансовых рисков, — главным образом крупных банков, страховых компаний, фирм по управлению активами и компенсационных фондов. «Внедрив SOA, мы станем создавать множество различных конфигураций как в области пользовательского интерфейса, так и для обработки, — говорит Пол Шмиттер, директор RiskMetrics по управлению процессами. — SOA позволит нам масштабировать и комбинировать сервисы». И совсем не случайно, что будучи сервис­провайдером SaaS, RiskMetrics является и потребителем SaaS: почти три года назад компания перешла с обычной CRM­системы на услуги, предоставляемые Salesforce.com, и Пол Шмиттер считает, что внедрение SOA обеспечит лучшую интеграцию услуг от Salesforce как с установленной в компании бухгалтерской системой Epicor, так и с информационными системами, взаимодействующими с клиентами.

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

«Кусочная» автоматизация

Теперь посмотрим на возможности подхода SaaS с точки зрения пользователя. В самом по себе предоставлении ПО через Интернет нового, конечно же, мало. К примеру, компания WebEx предлагает свою систему для организации онлайновых встреч еще с 1996 года — естественно, ее основное приложение совершенствовалось и расширялось по мере того, как росли возможности инфраструктуры и пропускная способность каналов, развивались браузеры и средства разработки для Web. В результате такого развития уже несколько лет сервисы WebEx позволяют инициировать совещания непосредственно из CRM­систем, документов Microsoft Office и других приложений, использующих стандартный API взаимодействия с сервисами. Что получается в результате? У компании­заказчика создается комбинированное приложение, часть функционала которого в полном соответствии с идеологией SOA взята в виде сервиса у другого приложения. Но самое важное, что этот сервис находится вне корпоративной сети. И это принципиально новая возможность. Предложения по SaaS способны стать важнейшими ингредиентами для создания комбинированных приложений.

Очень важно, что провайдеры услуг SaaS не стремятся сделать свои приложения единственными компонентами корпоративных информационных систем, как это очень часто бывает среди поставщиков традиционного ПО. На онлайновых торговых площадках, таких как StrikeIron.com, уже доступен богатый выбор автономных мини­сервисов: пересчет валют, проверка кредитоспособности и т. п. Интернет­магазин Amazon предлагает функции электронной коммерции в рамках Amazon Business Services, и нет сомнения, что на этот рынок вскоре выйдут и Google, и Yahoo, и Microsoft.

«Площадки, торгующие сервисами, будут более популярны, чем провайдеры SaaS, — уверен консультант в области SOA Дэвид Линтикем. — Я могу получить CRM­систему как сервис у Salesforce, но ведь мне еще нужны и анализ рисков, и управление кадрами, и расчет зарплат. Я не стану строить их самостоятельно, а вместо того найду нужные мне сервисы в Интернете и вставлю в свое приложение за скромную ежедневную плату». Хотя поставщики услуг SaaS также предлагают отдельные функции, компоненты и расширения своих основных SaaS­предложений: хорошим примером может служить популярная интеграционная платформа Sforce от Salesforce.com. «Ценность этих услуг должна заключаться в выполнении не каких­то масштабных, а самых скромных задач, таких как проверка состояния запасов, обновление или удаление информации о клиенте, проверка кредитоспособности, — считает Дэвид Линтикем. — Нужна возможность оркестровать их и сделать частью собственного процесса. Тогда вы приобретете подвижность, а как раз на ней и делаются деньги в SOA за счет избавления от бессистемной архитектуры».

Комбинированные приложения за межсетевым экраном

Хотя часть экспертов считает, что каждая услуга SaaS должнаохватывать очень узкий функционал, сейчас активно развивается и противоположный подход. Некоторые SaaS­провайдеры позиционируют свои сервисы не как дополнительный функционал к внутренним корпоративным системам, а как ключевое приложение, с которого пользователи начинают работу, а позже подключаются к критически важной внутренней информации предприятия. Так, используя преимущества Web­сервисов, WebEx недавно вывела на рынок услугу для совместной работы WebEx Connect — с прицелом на интеграцию внутренних ИТ­систем компании в эту систему коллективной работы. «Таким путем мы пытаемся создать новый класс комбинированных систем коллективной работы, — говорит Дэвид Найт, вице­президент компании WebEx. — SOA является ключевым моментом в обеспечении этого, так как позволяет нам привнести внешние источники данных в нашу среду совместной работы и построить новые микроприложения класса B2B».

При этом пользователь работает с одной Web­формой, в которой отражаются, например, данные из SAP о затратах на производство продукта, данные CRM­системы о его стоимости по каталогу, специализированного приложения для оценки допустимой скидки и т. д. «Конструктор форм на основе браузера, работающий с WDSL­интерфейсами Web­сервисов, позволяет нам разными способами заглядывать в системы, — комментирует Дэвид Найт. — Раньше для того, чтобы извлечь данные, мне понадобились бы прямой доступ к базе или вручную сформированный SQL­запрос, а теперь я просто выделяю эти источники мышкой и перетаскиваю в форму».

Проблемы интеграции остаются

Однако отнюдь не всё так легко и просто. Несомненно, благодаря Web­сервисам поставщики услуг SaaS смогли существенно уменьшить проблемы интеграции с внутрикорпоративными системами, имеющимися у клиентов. Но задача существенно усложнится, когда организации начнут более широко строить комбинированные приложения, сочетающие внутренние и внешние сервисы. «Просто построить одно комбинированное приложение за межсетевым экраном уже представляет собой довольно серьезную проблему, — говорит аналитик из Gartner Роберт Десисто. — А пять разных провайдеров SaaS — это пять точек, в которых надо следить за работоспособностью канала, и пять отдельных SLA (соглашение об уровне обслуживания. — Прим. ред.), при этом я, возможно, буду не в состоянии управлять релизами и версиями».

Несложно сделать набор функций или приложение доступными как Web­сервис, но стандарты — такие, как UDDI или WSDL, — не идут дальше этого в обеспечении взаимодействия. За комбинациями на уровне API должна стоять большая работа по созданию SOA с соответствующими моделями, мерами безопасности и режимами руководства. «Даже если у вас с обеих сторон замечательные SOA­среды, нужно еще согласовать форматы данных, определения и протоколы, используемые при информационном обмене, — говорит Роберт Десисто. — Иначе технология SOA, как она ни хороша, интеграцию не обеспечит». Принося сервисы «с той стороны» межсетевого экрана, необходимо проверить их на соответствие ожиданиям. «Удостоверьтесь, что они не слишком тонки и не слишком грубы, — соглашается Дэвид Линтикем, — что они надежны и хорошо работают в любых сочетаниях». Ключ к построению комбинированного приложения — это высокий уровень общего менеджмента, управления ИТ­услугами и информационной безопасности.

Надежность выше?

Еще одна проблема — безопасность и надежность. Среди консервативных организаций может встретить сопротивление уже идея работы с одним­единственным поставщиком SaaS, поскольку это требует передачи данных за межсетевой экран и ставит бизнес­процесс в зависимость от инфраструктуры внешнего поставщика. Однако сторонники SaaS настаивают на том, что они предлагают намного более высокую устойчивость и защищенность, чем могут обеспечить ИТ­отделы компаний, инсталлируя ПО традиционным способом.
Эти заявления поколебали было известные отказы сервиса Salesforce.com в начале 2006 года. Однако у сторонников SaaS есть аргументы. «В ответ на эти события Salesforce усилила избыточность своей инфраструктуры и начала публиковать информацию обо всех ее отказах на своем Web­сайте, — говорит Филипп Винсент (его компания Accenture является партнером­интегратором Salesforce.com). — Сколько вы знаете ИТ­подразделений с такого рода прозрачностью? Я работаю со многими, и лишь единицы могут претендовать на высокую степень удовлетворенности своих клиентов из бизнеса. Если вы глянете на показатели удовлетворенности у поставщиков SaaS, то увидите, сколько у них счастливых клиентов».

Успех SaaS зависит от SOA

Сегодня большинство предприятий еще не определились с тем, следует ли им вообще использовать SaaS. Даже среди компаний, двигающихся к SOA, лишь в немногих сервисная архитектура достигла той степени зрелости, которая необходима для работы с комбинированными приложениями, не говоря уже о соединении внешних и внутренних сервисов. Но Роберт Десисто убежден, что в ближайшие три — пять лет фирмы начнут активно создавать комбинированные приложения, включающие внешние сервисы. Если предсказания сбудутся и 25% ПО для бизнеса к 2011 году действительно будет предоставляться по модели SaaS, то лишь благодаря прочной архитектуре SOA по обе стороны сервиса. «Для предприятий, правильно выстроивших SOA и выбравших сервисы, не будут проблемами безопасность, масштабируемость и настраиваемость», — заключает Дэвид Линтикем.
В «прекрасном новом мире» источники данных и унаследованные приложения, заключенные в оболочку сервиса, будут предоставляться через Web вместе с новыми услугами. SaaS и более мелкие сервисы присоединятся к корпоративным сервисам, и появится возможность оркестровать их как часть более сложных составных приложений.