Эндрю С. Оливер, основатель Apache POI и директор по продуктовому маркетингу MariaDB Corporation, считает, что приближается день, когда компании будут представлять собой разрозненные комбинации программных сервисов с отдельными коалициями людей, выполняющих цифровые обещания. Вы готовы? Переход на SaaS (программное обеспечение как услуга) обусловлен как деловыми, так и технологическими факторами. С точки зрения бизнеса, компании-разработчики программного обеспечения стремятся к надежному постоянному доходу вместо того, чтобы тратить на исследования и разработки заранее и надеяться, что клиенты купят продукт или обновят его на серверной части.

С технологической точки зрения пользователи программного обеспечения часто не обладают опытом и ресурсами для поддержания инфраструктуры, необходимой для запуска сложного программного продукта, такого как, например, распределенная база данных. В обмен на постоянный доход производитель берет на себя бремя эксплуатации и технического обслуживания программного обеспечения для заказчика. Очевидно, что SaaS имеет большой смысл для создателя распределенной базы данных. Но что, если ваш бизнес - это не программное обеспечение как таковое, а производство, или логистика, или страхование, или какая-то другая бизнес-услуга? SaaS все еще может иметь смысл для вас. Добро пожаловать в SaaS-ификацию!

Грань между тем, что такое программное обеспечение, и тем, что такое бизнес-сервис, уже давно размыта. Рынок рассматривает такие компании, как Uber, Grubhub и Amazon, как технологические компании. Между тем, Yellow Cab, Domino's и Walmart — компании, которые предоставляют одни и те же виды потребительских услуг, а также имеют веб—сайты и приложения, - не считаются технологическими компаниями. Как и большинство компаний, предоставляющих бизнес-услуги, даже несмотря на то, что эти услуги могут предоставляться с помощью программного обеспечения.

Традиционно компании считают себя либо потребителями, либо поставщиками технологий или услуг. Однако бизнес может быть и тем, и другим. Существует значительное количество исследований о том, как будет работать этот новый мир, но он все еще зарождается. Пока еще не существует реального рынка, на котором предприятия могли бы покупать услуги, выходящие за рамки только ИТ (например, AWS Marketplace), и десятилетия попыток создать их потерпели неудачу. Таким образом, еще есть время, чтобы опередить события.

Даже если бизнес не ставит во главу угла продажу своего внутреннего опыта другим компаниям в качестве услуги, SaaS-ификация имеет свои преимущества. Способность пробовать новые идеи, запускать новые сервисы и быстро терпеть неудачу - один из ключей к успеху Ubers и Grubhubs по всему миру. Быстрый запуск, неудача или успех требуют, чтобы изменения были легкими. Эволюция может быть быстрой и простой, если ваши бизнес-возможности упакованы в виде автоматически масштабируемых облачных микросервисов, управляемых с помощью автоматизации бизнес-процессов и управляемых моделью devops.

Становление SaaS внутри и снаружи

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

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

Это означает понимание вашей политики и практики и преобразование их в бизнес-процессы с помощью системы управления с замкнутым циклом, поддерживаемой поддержкой принятия решений на основе данных и встроенной в нее системой ситуационной осведомленности. Компании, которые совершают этот переход, по своей сути более ценны. Стоимость компании - это, отчасти, ее теоретическая цена покупки при приобретении или слиянии акций. Однако приобретения - это рискованный бизнес. По данным Harvard Business Review, от 70% до 90% слияний и поглощений не выполняют своих обещаний. Ключевым фактором успешной оценки приобретения является прозрачность систем и управления приобретаемой компании, а также четкий путь интеграции. Компаниям, которые представляют собой комбинацию слабо связанных сервисов и алгоритмов бизнес-процессов, по своей сути должно быть проще объединяться.

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

Что означает SaaS-ификация для IT

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

Рассмотрим стандартный внутренний ИТ-отдел с сервером Active Directory (AD) и множеством экземпляров Oracle, MySQL, MariaDB и SQL Server, которые предоставляют данные для ряда приложений stovepipe. Каждое из этих приложений или будущих слабо связанных сервисов опирается на базовое клиент-серверное программное обеспечение, которое масштабируется только до ограниченного уровня и обеспечивает ограниченное резервирование. В зависимости от того, какую базу данных SQL вы используете, вы, очевидно, можете перейти на совместимую распределенную базу данных SQL, и Microsoft рекомендовала бы перейти на Azure AD, но не все так просто перенести.

Эта миграция обычно представляет собой возможность дедупликации и объединения служб. Вместо того чтобы иметь несколько экземпляров AD для разных подразделений компании или серию баз данных stovepipe, часто имеет смысл объединить связанные данные и системы. Например, инвентаризация может находиться в базе данных Oracle, а служба ценообразования или каталога - в MariaDB. Там может быть один рекламный экземпляр для запада и один для востока. Сохранение этого разделения при переходе к сервисам может не иметь смысла, особенно в облаке. Меньшее количество систем и данных легче администрировать, обслуживать и обеспечивать безопасность.

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

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

У нас есть технология

Хорошей новостью является то, что технология уже существует. Почти все это возможно с помощью контейнеров, Kubernetes, облачных вычислений и распределенных баз данных. Однако для этого потребуется другое мышление и изменение культуры. Архитектура облачных сервисов должна быть данностью для всего, что ОНА разрабатывает или управляет. Эти услуги должны соответствовать стандартам, необходимым для SaaS-ификации, включая масштабирование, уменьшение масштаба и глобальные возможности. Во многих случаях основные службы (такие как безопасность и базы данных) должны быть объединены, чтобы сделать их более удобными в обслуживании.

Что еще более важно, предприятия должны мыслить в терминах услуг и процессов, а не иерархий. Услуга - это не просто “ИТ-штука”, а то, как бизнес организует себя. ИТ-специалисты и бизнес-специалисты должны модулировать все как облачные SaaS, включая отраслевые сервисы, горизонтальные системы взаимодействия, системы учета, базы данных и безопасность. Да, пришло время перенять технологические инновации последних нескольких лет, но принятие этого изменения в мышлении еще более важно.