Консьюмеризация ИТ, то есть использование личных мобильных устройств для выполнения рабочих обязанностей в режимах BYOD (Bring Your Own Device) [1] и BYOA (Bring Your Own Applications — «принеси собственное приложение») [2], привела к изменению на предприятии роли ИТ-службы: из главного покупателя, оценщика и хранителя информации она превращается в координатора, работающего в федеративной среде. BYOD и BYOA вызвали инверсию ролей — теперь сами пользователи стали движущей силой внедрения новых технологий.
Такая трансформация не обошлась без сложностей [3], но она создает новые возможности для ИТ-служб с точки зрения улучшения адаптируемости и повышения результативности своей работы. BYOD может помочь компаниям и организациям поспевать за культурными изменениями в обществе — например, отвечая требованиям поколения Y, рассчитывающего, что любимые устройства будут полезны как в корпоративной обстановке, так и в домашней. Тематика консьюмеризации ИТ актуальна для директоров ИТ-служб, директоров по технологиям и архитекторов решений. Однако основная часть публикаций касается практических аспектов консьюмеризации, включая вопросы эксплуатации [1] и разрушительного влияния политик, связанных с BYOD, на существующую организацию ИТ. Тем не менее изучать движущие силы консьюмеризации необходимо хотя бы для того, чтобы управлять процессами изменения отношений между работниками и работодателями и переопределения границ предприятия, а затем подготовиться к переходу к экономике, ориентированной на сервисы.
Работник и работодатель
Изменение отношений между работниками и работодателями — одна из главных причин, заставляющих предприятия переходить на BYOD. После кризиса в финансовом секторе 2008 года структура рабочей силы компаний стала более разнородной, выросло количество контрактных сотрудников, поставляемых агентствами по комплектации штата наподобие Volt и Kelly Services, а также независимых и частично занятых работников. Штатных сотрудников — традиционных потребителей ИТ-сервисов — становится все меньше, чему также способствует переход на облака, по сути равносильный аутсорсингу инфраструктуры.
Временные работники пользуются для выполнения обязанностей своими личными инструментами и не стремятся осваивать принятые в компании инструменты и процессы. Временные команды часто применяют более удобные для себя средства контроля хода проектов, управления отношениями с клиентами и др., и это не контролируется корпоративной ИТ-службой. Развертывать локальную инфраструктуру для подобных инструментов не имеет смысла, и обычно они представляют собой ПО в виде сервиса, доступ к которому осуществляется через мобильные устройства.
Даже когда нужно работать с корпоративными приложениями и данными, новые служащие, особенно временные, пренебрегают предоставленными им работодателем инструментами, предпочитая собственные. В результате создается чрезмерная нагрузка на ИТ-службу, связанная с необходимостью поддерживать личные устройства.
Переопределение границ
Сегодня крупные корпорации, к примеру производители самолетов и автомобилей, по сути стали гигантскими системными интеграторами, которые управляют сложными цепочками поставок, а мелкие компании следуют той же тенденции либо участвуют в различных сетях поставки. В итоге к корпоративным приложениям и данным постоянно обращается разнородное сообщество пользователей. Когда компоненты приложений или целые системы, например электронная почта, переносятся в облако, не всегда можно понять, что находится внутри предприятия, а что — за его пределами: корпоративные процессы пользуются ресурсами, находящимися вне периметра корпоративной сети.
При этом самих сотрудников не волнуют различия между внутренними и внешними ресурсами — они рассчитывают пользоваться устройствами, данными и инструментальными средствами так же, как всегда. ИТ-служба по сути больше не контролирует устройства, соединяющиеся с корпоративными данными и приложениями, и жесткий запрет BYOD вызовет лишь враждебное отношение пользователей, которые просто будут применять инструменты по своему выбору в обход ИТ-службы. Простого способа разрешения противоречия нет, и, чтобы выработать оптимальное решение, нужно понимать причины, движущие консьюмеризацией.
Переход на сервис-ориентированную экономику
Как представляется, все эти перемены на самом деле обусловлены еще одним, более фундаментальным преобразованием — долгосрочным и необратимым отказом индустрии от ориентации на производство и продукт. Вместо этого по мере глобализации мировая экономика становится сервис-ориентированной — экономическая ценность финансовой, транспортной, юридической, медицинской и других сервисных отраслей становится больше, чем у производства, сельского хозяйства и добывающей промышленности. Если сравнить долю валового внутреннего дохода сервисных секторов со всеми остальными, то будет видно, что во многих странах этот переход произошел уже десятилетия тому назад. В частности, в США он начался после Второй мировой войны, и в 2012 году доля сервисного сектора в валовом внутреннем продукте США составляла около 79%. Даже в КНР, которую считают страной производства, аналогичный показатель уже составляет 45% и продолжает расти.
Сервисные ИТ
Переход на сервисную экономику не миновал индустрию ИТ, в которой он начался относительно поздно, будучи инициирован появлением WWW, развитием веб-сервисов и, наконец, появлением сервисных сетей.
Появление Всемирной паутины стало возможным благодаря HTML, URI/URL, HTTP, а ее ценность — в универсальном интерфейсе человек-машина, обеспечивающем доступ к данным и приложениям в Интернете независимо от различий в машинной архитектуре. Следующий этап технологической эволюции связан с осознанием того, что WWW подходит не только для связи человека с машиной, но и для межмашинной связи. Этот этап ознаменовался произошедшим в начале 2000-х годов развитием веб-сервисов, доступных по протоколам SOAP и REST. И наконец, примерно в 2007 году появились сервисные сети, ставшие возможными благодаря повсеместному внедрению облаков и BYOD — это одно из следствий появления сервисных сетей. На рис. 1 перечислены основные вехи технологической эволюции.
.png "Рис. 1. Эволюция сервисной экосистемы — основные этапы перечислены в овалах. В прямоугольниках слева — аппаратное обеспечение, способствующее наступлению очередных стадий развития, справа — ключевые игроки эволюции сервисной экосистемы")
Появление сервисных сетей
Появление сервисных сетей первоначально было обусловлено распространением стандартных протоколов и совместимого ПО (в том числе с открытым кодом), которое работало на соединенных с Интернетом машинах. Протоколы веб-сервисов позволяют программам и пользователям обращаться к сетевым ресурсам по обычному URI. Все согласование и сопряжение между сторонами происходит в момент доступа по принципу динамического связывания. Традиционные системы, не знающие этого принципа, требовали большого объема конфигурирования для обмена информацией, развертывание сопровождалось большими накладными расходами, а интероперабельность была ограниченной. Чтобы старые системы могли работать, все компоненты их кода должны были компилироваться вместе либо как минимум для систем, обменивающихся информацией, нужно было использовать определенные версии ПО, предпочтительно от одного и того же поставщика. Приложения традиционных сильносвязанных архитектур необходимо было собирать строго из совместимых друг с другом компонентов, и выпуск новой ревизии или произвольная доработка могли потребовать иного набора компонентов с тем же функционалом, но неспособных работать в старой или обновленной среде. Могло оказаться, что какой-то компонент поддерживает лишь одну копию приложения, а для всех остальных его нужно воспроизводить. Несовместимость версий приводила к ненужному дублированию и лишним сложностям. Для интернет-приложений все это совершенно неприемлемо. Доступность слабосвязанных веб-сервисов позволила разработчикам отказаться от реализации стандартных функций — теперь они предоставляются в виде самостоятельных сервисов.
Когда сильносвязанная архитектура была нормой, приложения работали в вертикальных стеках (рис. 2) — каждое приложение (A1, A2, A3) работает на отдельном оборудовании. Затем в эпоху слабосвязанных веб-сервисов функциональность, общая для всех трех стеков, абстрагируется, реализуется единожды и предоставляется в виде сервиса. Дублирующиеся стеки, характерные для сильносвязанных приложений, уступают место новой структуре, изображенной в виде графа, каждая вершина которого представляет собой отдельный общий сервис. Лес стеков сменяется сервисной сетью. Сжимается периметр корпоративной сети — становится меньше экземпляров приложений, но при этом они соединяются с ресурсами, развернутыми в облаке. Для приложений новой архитектуры обязательна поддержка многих режимов доступа.
.png "Рис. 2. Переход от традиционных приложений к сервисным сетям. Приложения со структурой в виде вертикальных стеков сменяются сетями сервисных компонентов. Доступ к новым приложениям могут осуществлять как постоянные служащие, так и временные работники с корпоративных ноутбуков и личных устройств, а также внешние разработчики, в том числе мобильных приложений")
Каждый узел сети — это сервисный компонент, сервлет, представляющий собой самостоятельный элемент приложения, доступный по URI и обнаруживаемый через реестр UDDI с использованием языка WSDL. Как показано на рис. 2, все три уровня прежнего стека преобразованы в общеупотребительные внутренние сервисы S2, S3 и S4. Часть сервисов также предоставляется извне (S6, S8 и S9). Приложение A1 предъявляет строгие требования к безопасности и поэтому пользуется сервлетами, работающими во внутреннем (частном) облаке. Приложение A3, менее требовательное к безопасности, реализовано как ПО в виде сервиса и пользуется внешними сервлетами. Приложение A2 — нечто среднее между двумя этими вариантами.
Сервлеты рассчитаны на использование в качестве компонентов и потому сами по себе могут не быть полноценными приложениями. Сегодня сервлеты обычно работают в виртуализованной среде, операторы которой могут балансировать нагрузку в таком пуле, меняя условия запуска задач и перемещая виртуальные машины согласно определенным политикам.
Экстернализация сервиса
Приложения, состоящие из сервисных компонентов, называются составными, а их архитектура — сервисная (SOA), предназначенная для радикального уменьшения затрат на предоставление ИТ предприятию за счет отказа от дублирующихся и ненужных функций. Конкретные функции реализуются лишь единожды в виде сервиса, а не воспроизводятся для каждого приложения. Пример — система Common Directory Information System корпорации Intel, репозиторий данных по служащим. С CDIS связываются все приложения, которым нужна информация по сотрудникам, в том числе система расчета зарплаты, система отчетности по расходам и каталог самих работников.
Благодаря универсальности URI, практически не имеет значения, находится ресурс внутри или вне организации, и тогда в ИТ-службах поняли, что размещать общеупотребительные сервисы локально не всегда экономически целесообразно, особенно когда эти сервисы к основному бизнесу не имеют отношения (электронная почта, обмен сообщениями и даже хранение данных).
Появление около 2007 года облаков позволило разработчикам окончательно осознать преимущества сервисных сетей, а с переходом на составные приложения стало ясно, что, даже если сервисные компоненты изначально создавались внутри организации, нет причин, мешающих получать эти сервисы извне. Системы расчета зарплаты, формирования отчетов о расходах и размещения объявлений о вакансиях вполне можно получать в виде сервиса от третьих сторон, которые, пользуясь экономическим эффектом масштаба, могут предоставлять подобные приложения по меньшей цене, чем это обошлось бы при локальной эксплуатации.
От сервисных сетей к консьюмеризации
Движущие силы экстернализации были чисто экономическими, однако участие нескольких сторон (компания — поставщики сервисов) сопряжено с трудностями, которые возникают на пути обеспечения безопасности и качества обслуживания. Тем не менее экономические выгоды настолько привлекательны, что эти проблемы не мешают внедрению составных приложений, когда риски приемлемы.
Родство облаков и сервисных сетей проявилось в перетекании функциональности между ними. Вначале произошла экстернализация сервлетов, затем появились полноценные онлайн-приложения, первыми из которых стали сервисы веб-почты (Google Mail, Yahoo Mail и др.) и система CRM от Salesforce.com. На рис. 1 отражено, как унаследованные приложения крупных компаний были преобразованы в составные; вначале использовались внутренние сервлеты, но в конечном счете, когда это стало экономически оправданно, были задействованы и внешние.
По мере того как индустрия осваивала составные приложения, был достигнут эффект масштаба, благодаря чему доступ к таким приложениям получили организации, не имеющие квалифицированных кадров и больших финансовых ресурсов,— началась демократизация ИТ. Сервлеты достигли индивидуальных потребителей в форме тысяч приложений, доступных через магазины Google Play, Apple App Store и порталы наподобие Dropbox.
Как показано на рис. 1, переходу на BYOD и BYOA способствовало появление порталов управления интерфейсами программирования. Движущей силой при этом стала обратная экстернализация, когда в организациях стали понимать, что, наряду с использованием внешних сервлетов, внешняя экспозиция некоторых корпоративных приложений — как в виде сервлетов, так и через браузер — позволяет получать дополнительный доход и расширять клиентуру. Примеры — системы бронирования туров, сети цепочек поставки, а также сайты электронной коммерции Amazon и eBay, превратившиеся в торговые площадки с огромным количеством продавцов и покупателей.
Подобные возможности доступны сторонним разработчикам через порталы управления API, с помощью которых относительно просто создавать мобильные интерфейсы для облачных сервисов. Сами пользовательские интерфейсы тоже сильно эволюционировали — они адаптируются к различным браузерам и мобильным устройствам. Порталы управления API стали новыми точками интеграции для прежде внутренних функций, которые теперь предоставляются из публичных облаков, — разработчики мобильных приложений стали новыми интеграторами.
Для поддержки облачных составных приложений создают «нативные» сервлеты, однако на практике можно превращать в сервисы и унаследованные приложения — путем их дооснащения интерфейсами программирования. И наоборот — ПО, созданное в качестве сервлета, можно превратить в самостоятельное приложение с помощью облегченного графического пользовательского интерфейса, работающего с сервлетом через API (рис. 2).
При этом переработанные приложения обязаны поддерживать несколько режимов доступа, в том числе традиционный из корпоративной сети, доступ из персональных приложений и с личных устройств, а также доступ разработчиков через портал управления API.
Когда сервлеты от сторонних поставщиков стали доступны любому разработчику, появились новые бизнес-возможности — внешние программисты начали создавать приложения тех типов, которые до этого разрабатывались внутри предприятий. Поскольку в этом по сути участвует вся компьютерная индустрия, темпы эволюции быстро ускорились. Большинство новых приложений не приживаются, но те, которым это удается, получают пользовательскую базу в сотни тысяч всего лишь за несколько месяцев.
Развивавшаяся в этом контексте консьюмеризация имеет колоссальное влияние на экономику — ЦОД стоимостью в сотни миллионов или миллиарды предоставляет доступные потребителям приложения буквально за копейки. В роли заказчика вначале выступало единственное предприятие, которому нужен был полный стек из собственных решений. Затем аудитория выросла до нескольких сотен крупных корпораций, а впоследствии — до десятков тысяч малых и средних предприятий и десятков миллионов индивидуальных пользователей. На фоне консьюмеризации с теми же когда-то корпоративными приложениями познакомились индивидуальные пользователи и снова вернули их на предприятие, замкнув круг. Мощным фактором влияния стали предпочтения поколения Y, представители которого вышли на рынок труда, а значит, новый стиль работы сохранится надолго.
А что завтра? BYOD — это прежде всего взаимодействие человека c машиной. Уже появились вестники новой эпохи межмашинных взаимодействий — Интернета вещей, объединяющего устройства наподобие принтеров, которые становятся сетевыми узлами.
***
Перемены, обусловленные консьюмеризацией, переопределят роль ИТ в целом, но происходящее сейчас — лишь верхушка айсберга. Переход развитых стран к сервисной экономике принципиально меняет взаимоотношения между организациями и их сотрудниками, попутно преобразуя сами принципы предоставления ИТ. Консьюмеризация также выражается в размывании границ предприятия.
Грозит ли ИТ-службам ненужность — превращение в регулятора все более узкого круга основных функций предприятия? Такой риск существует, но при наличии подходящей стратегии — вряд ли. История свидетельствует, что ИТ-службы способны трансформироваться. В начале 1990-х, когда из-за заморозки развития мэйнфреймовых приложений бизнес-подразделения начали без ведома ИТ-служб пользоваться электронными таблицами из коробки, индустрия взяла на вооружение клиент-серверные и трехуровневые архитектуры на основе серийно выпускаемых серверов. В ответ на падение спроса на внутренние услуги в начале 2000-х ИТ-службы повысили свою результативность за счет перестройки приложений на базе сервисной парадигмы и перехода на облачные технологии.
Консьюмеризация — долгосрочная тенденция, и рассматривать ее лишь с точки зрения необходимости управления новыми конечными точками непродуктивно. У ИТ-служб есть возможность найти новые способы приносить пользу бизнесу — в частности, личные устройства и приложения можно интегрировать в бизнес-процессы, автоматизированные с помощью BPEL. Это позволит выяснять, согласуются ли персональные инструменты с имеющимися потоками работ, а также устанавливать объективные критерии, по которым можно отличать полезные приложения от ненужных. Сейчас подобных возможностей еще нет.
Литература
- Bring Your Own Devices Best Practices Guide: A Practical Guide for Implementing BYOD Programs at Your Organization. Good Technologies/Dell Inc., 2012. URL: http://i.dell.com/sites/doccontent/business.smb/sb360/en/Documents/good-byod-best-practicesguide.pdf (дата обращения: 18.10.2014).
- J. Bughin, A.H. Byers, M. Chui. How Social Technologies Are Extending the Organization. McKinsey Quarterly, Nov. 2011. URL: www.mckinsey.com/insights/high_tech_telecoms_internet/how_social_technologies_are_extending_the_organization (дата обращения: 18.10.2014).
- C. Boulton. Failed iPAD Experiment Shows BYOD Belongs in Schools. blog, The Wall Street J., 15 Oct. 2013. URL: http://blogs.wsj.com/cio/2013/10/15/failed-ipadexperiment-shows-byod-belongs-in-schools (дата обращения: 18.10.2014).
Энрике Кастро-Леон (enrique.g.castro-leon@intel.com) — корпоративный архитектор и стратег, Intel Data Center Engineering Group.
