Ключевым достоинством концепции "программа как сервис" (Software as a Service, SaaS) считается оптимизация затрат, поскольку она предполагает оплату за доступ только к тем приложениям, которые нужны, и тогда, когда нужно. Но эта концепция имеет и ловушки, которые становятся все заметнее с течением времени. Так полагает аналитик компании Gartner Роберт Десисто.

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

Десисто не один год изучал рыночные предложения в сфере SaaS и опыт работы клиентов Gartner с приложениями, предлагаемыми на таких условиях.

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

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

Среди разработчиков приложений SaaS такие компании, как Salesforce, Taleo, Workday, NetSuite, Oracle, SuccessFactors и Microsoft Dynamics.

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

Потребители  SaaS должны настаивать на составлении контрактов с учетом изменений потребностей пользователей (хотя бы раз в год) и на возможности иметь "альтернативы на базе мощности", предложил Десисто.

Пользователей подстерегает еще одна ловушка: соглашениям об уровне обслуживания, как правило, недостает конкретности, а подчас их просто не существует. «Необходимо требовать SLA на уровне от 99,7 до 99,9%", — рекомендует Десисто. Кроме того, в контрактах должно быть четко указано, какие "осязаемые меры» могут быть предприняты, если что-либо случится. Необходимо иметь полное представление об операциях центров данных SaaS, а для многих может оказаться шокирующей новостью то, что во многих случаях вовсе не предусматривается восстановление после сбоев.

"Для крупной компании это почти безумие — не иметь системы восстановления после сбоев", — считает Десисто.

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

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

Еще одной сложностью в связи с SaaS оказывается так называемое "множественное владение" (multi-tenancy). Данное понятие обычно применяется, чтобы охарактеризовать способ совместной работы с приложениями. Этот термин явно не исчерпывает все многообразие ситуаций, и клиентам всегда необходимо уточнять, что конкретно подлежит совместному использованию: аппаратное обеспечение, база данных, контейнеры или что-либо еще, чтобы получить некое общее представление о получаемой архитектуре, поскольку именно она во многом определяет особенности организации защиты и управления.

SaaS может быть не самым подходящим вариантом для интенсивных вычислений по интернет-соединению, подчеркнул Десисто. Необходимо проводить тестирование времени реакции, чтобы определить, будет ли SaaS адекватно работать на том или ином предприятии.

Интеграция приложений SaaS в системы предприятия требует усилий и может вылиться в постоянную работу по тестированию модернизаций приложений SaaS. Если предприятие использует много приложений, предоставляемых как сервис, оно оказывается "в состоянии постоянного тестирования, необходимого для обеспечения работоспособности", как выразился Десисто. Интеграция в этом случае представляет трудную задачу, поскольку многие приложения SaaS интегрируются в пакетном режиме через сетевой экран.

Неудивительно, что до сих пор так мало предприятий применяют эту модель.

"У большинства предприятий нет корпоративной политики в отношении SaaS", — отметил Десисто. Необходимо сформировать фундаментальные основы взаимодействия информационных и бизнес-подразделений, чтобы решать, как будут использоваться приложения SaaS, кто будет владеть процессами управления изменениями конфигурации, будет ли отдача для подразделений.

"Теоретически модель SaaS может охватить всю ИТ-структуру", — сказал Десисто.