SaaS: со щитом или на щите?

Если рассмотреть типичную организацию работы типичного офиса, то первое, что бросается в глаза, — десктопы. На них, как правило, Windows (и как опция — вирусы), реже — Linux, на десктопах установлено офисное ПО, ну и как вариант — учетная система. При этом сами десктопы могут быть «не первой свежести», но — «функции свои выполняют, значит — списывать рано». И так — из года в год, лет пятнадцать точно. И вроде бы — выхода нет...

Собственно говоря, а из чего надо искать выход? Во-первых, из нежелания постоянных инвестиций в парк компьютерной техники. Общеизвестно, что компьютеры стареют быстрее, чем растут требования программ. Соответственно, обновление на новую версию корпоративной учетной системы или даже на новый «офис» может стать серьезной нагрузкой для старой техники. Во-вторых, из динамики: переезд, рост и сокращение численности сотрудников фирм в наше время не редкость. В-третьих, совсем не редкость (даже скорее обыденность) — географическая распределенность сотрудников компаний или необходимость иметь мобильных сотрудников. И если потребности последних относительно легко удовлетворить ноутбуками, то про остальных такого не скажешь. Потому что если ноутбук старый, то программа не станет на нем работать быстро. К переезду он, правда, приспособлен лучше, чем стационарный компьютер (перенести и подключить его может сам работник, да и создавались они изначально именно как мобильные устройства). Но вот, например, в разрезе изменения численности сотрудников, особенно в меньшую сторону, ноутбук никак не повлияет, оставаясь невостребованным для производственной деятельности активом. Пессимистическая картина, не правда ли?

Про решения

Честно говоря, волшебной палочки-выручалочки тут нет. Есть лишь некоторые вещи, способные в какой-то степени помочь.

Первое — это, конечно, использование облачных приложений — сервисов. Они доступны всегда и отовсюду (отметим для точности, что это утверждение условно и зависит от настроек безопасности под конкретного клиента и для конкретного приложения). Важно и то, что они, как правило, не требуют «толстого» клиента или требуют — но достаточно «легкого». Кроме того, для большинства облачных систем есть мобильные клиенты (под iOS, Android и т. д.). Таким образом, пользователь перестает быть привязанным к конкретному рабочему месту и начинает «жить» в информационном пространстве облака, имея в нем необходимые данные, разработки и наработки. Что немаловажно, такой пользователь в крайнем случае может работать со своего мобильного устройства. Сейчас вообще есть компании, которые распределены чуть ли не по всем миру. Например, разработчики могут находиться в Индии, менеджеры — в России, тестировщики — в Корее, а заказчик — в Финляндии. Эти люди могут вообще никогда не встретиться лицом к лицу, но способны плодотворно сотрудничать.

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

Третье — переориентация на сервисную модель работы. Причем не с конкретным приложением-сервисом, а вообще. В целом. Всей командой, всей компанией. На Западе сейчас модно говорить, что компания поставляет сервис потребителю. Можно дополнить — поставляет, потребляя.
Получается, кстати, классический unix way в масштабах компании: есть некие компоненты (приложения-сервисы, люди, и регламенты), из которых формируется итоговое предложение — сервис. Он, в свою очередь, потребляют другие компании, работающие по той же самой цепочке.

Про матчасть

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

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

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

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

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

Про адаптацию

При всей своей привлекательности модель SaaS внешне имеет один серьезный недостаток. Он состоит в том, что приложение SaaS является условным монолитом, то есть единым, неделимым и одинаковым для всех пользователей. На самом деле все несколько сложнее.

Для того чтобы проиллюстрировать этот тезис, взглянем на SaaS ретроспективно. Не для кого, хоть как-то связанного с компьютерами, не секрет, что SaaS — это «хорошо забытое старое», фактически логический слепок эпохи менфреймов, когда один большой компьютер, сервер, передавал данные в видеопамять устройств вывода (терминалов) и принимал сигналы с их устройств ввода (клавиатур). Разумеется, ни о каком дизайне тогда не могло быть и речи: монохромные мониторы и восьмибитная псевдографика напрочь отбивали желание «дизайнить». Да и вычислительные мощности расходовались более разумно: не было ни излишков памяти, ни производительности, а именно они и необходимы для поддержания дизайна рабочего окружения пользователя. Все было утилитарно и направлено на выполнение основных функций. Точка.
C развитием технологий и увеличением вычислительных мощностей появился дизайн. Одновременно с ним появились персональные компьютеры, следом — изолированные в рамках локальной сети приложения, затем — приложения, которые каким-то образом умели работать через Интернет. Я помню, как в одной из компаний были обеспечены удаленные рабочие места — через Интернет, через VPN-тоннель шли данные (между “»толстым» приложением и удаленным сервером) и телефонный трафик. Кажется, я тогда впервые в жизни увидел IP-телефон, которому не нужно было ничего, кроме доступа в Сеть. И это было реально круто.

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

На уровне бизнес-пользователя, как правило, можно сделать тюнинг приложения, изменив цветовое оформление, настроив «под себя» меню быстрого доступа, поменяв обои рабочего стола и т. д. Ничего кардинального, влияющего на функциональность приложения в целом, на этом уровне изменить не получится.

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

Грубая настройка — это настройка, осуществляемая на сконфигурированном SaaS приложении под конкретную группу пользователей, путем внесения различных настроек. Фактически, это скрытый от обычных пользователей уровень настроек системы. Тонкая же настройка — это доделки системы, выполняемые в виде патчей, но чаще плагнинов и модулей, которые перекрывают функциональность, необходимую для полноценной работы конкретного заказчика.
Следует отметить, что тонкая настройка SaaS обычно проходит по той же схеме, что и настройка классического приложения: проводится обследование, составляется ТЗ, система дорабатывается, сдается заказчику... Разница лишь в том, что заказчик, оплативший такого рода доработки, все равно не имеет на них никаких прав (как правило).

Отсюда следует один простой вывод: системы SaaS крайне малоэффективны там, где требуется много доработок под заказчика. Это разрушает монолитность массового решения, превращая его из системы класса «один для всех» (с относительно небольшими расходами на поддержку) в систему, которая по свой сути уже не является монолитной. Фактически приходится поддерживать ядро и то количество настроек «под клиента», которое есть в системе. Проще написать новое решение, под заказчика, и продать ему его. Но это получается уже совсем отдельный бизнес.

Кое-что про безопасность

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

Сейчас в Интернет передается гигантский объем данных. В том числе данных, которые являются ценными и конфиденциальными, а разглашение крайне нежелательно. При этом элементарные средства, такие как шифрование и защищенная передача (хотя бы по VPN-тоннелю), не гарантируя 100%-ной защиты, создают достаточно препятствий для действий технического характера. Что же касается провайдера, тут все еще проще. Как правило, провайдеру данные пользователей просто неинтересны, если только речь не идет о выполнении судебных решений или получении сведений, необходимых для выставления счета. Увы, печальная статистика говорит о том, что чаще всего виновными в утечках становятся сотрудники организации, откуда произошла утечка, а не провайдера. Провайдеру репутация значительно дороже — и он будет делать все, чтобы она не пострадала. Это если говорить о фактической составляющей. Если же перейти в юридическую плоскость, то при заключении договора на использование SaaS-приложения между провайдером и клиентом обычно заключается достаточно жесткий договор о конфиденциальности, нарушение которого грозит провайдеру большими штрафами.
И еще один аспект, имеющий косвенное отношение к безопасности, — для своей работы SaaS-приложению нужно иметь постоянное подключение к Интернету. Это заложено в его сути — без этого не будет SaaS как класса. Соответственно, если по той или иной причине доступ в Интернет пропадает, SaaS перестает функционировать. Но подобный риск легко нивелируется наличием резервных интернет-каналов, и максимум, что могут потерять пользователи, — данные текущей сессии. Обидно, но не смертельно.

Про баланс

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