Практика «больших данных» радикально отличается от теории в одной «несущественной» детали. Теория подразумевает, что big data уже есть, то есть, предусматривает наличие источника данных. На практике же такой источник ещё надо найти. И раз уж речь идёт о действительно «больших данных», масштабы (и косвенно стоимость) их источника даже по идее должны быть пропорциональны невнятному «большому».
Естественно, огромные, планетарного масштаба, сервисы, являются подходящим источником «больших данных». Но здесь возникает явный конфликт даже не между интересами двух сторон (поставщика услуг и пользователя), а между потребностью в данных и спецификой пользователя. Например, речь может идти о конфиденциальной коммерческой информации, степень конфиденциальности которой определяется стоимостью стоящих за ней проектов. Явно с учётом всего этого довольно очевидного, в Microsoft делают попытку формирования источника больших данных, ориентированного на корпоративных пользователей.
Речь идёт о новой системе, которую точнее всего можно назвать «раскопками (data mining) в косвенной информации», при этом вся «техника для раскопок», собственно место «раскопок» и результаты локализованы в пределах одной корпоративной подписки на сервисы Office 365.
Система Microsoft Office Graph, анонсированная сравнительно давно (в марте2014 года), но до уровня preview доведена только буквально на днях. На деле она является REST-интерфейсом к API одной из подсистем Office 365. Вопреки некоторым обзорам, рисующим глобальные перспективы перехвата, например, персональных чатов для автоматической выдачи контекстной информации и рекламы, ничего подобного Microsoft Office Graph не предусматривает. Более того. Office Graph – это строго ограниченный корпоративный доступ к данным об активностях пользователей корпоративных подписок Office 365, Exchange и SharePoint, а не «подглядывание» в содержимое документов, с которыми они работают (на рисунке внизу слева – Office 365).
Использованный в названии математический термин graph не случаен (не следует путать Office Graph с просто Microsoft Graph, являющимся единым REST-фронтендом к API Office 365, ранее называвшимся «Office 365 unified API»). Office Graph собирает информацию о действиях пользователей в пределах одной корпоративной подписки и отображает её в виде графа, позволяющего вскрыть латентные отношения между пользователями, документами и пользователями/документами.
Пользователь в терминах Office Graph называется «актёром», документ – «объектом», а перечень активностей, связывающих «актёра» и «объекта» весьма ограничен и строго разделён на «публичные» (неограниченный доступ всем пользователям корпоративной подписки) и «приватные» (доступ только конкретного пользователя). Активностей всего (на этапе preview) 10, и они не содержат никакой «крамолы», кроме констатации безвредных внутрикорпоративных фактов, как-то: доступа «актёра» к «объекту», обозначения иерархии между актёрами, совместной работы «актёров» с «объектом». Из этого строится математический граф (или, если больше нравится, – на основе этой информации ведётся принадлежащая корпоративному подписчику граф-ориентированная база данных). А для «выуживания» чего-то, что может оказаться ценным подписчику предназначен аналитический инструмент под названием Delve («Раскопщик»).
Вся подсистема в целом не является чем-то исключительным, во многие системы, основанные на идеологии и модели wiki, нечто подобное встроено (разве что исполнено совершенно иначе, но, если говорить о высокоуровневой функциональности, можно рассмотреть концептуальную близость моделей). Смысл такой специфической функциональности, по идее, заключается в формировании динамической корпоративной базы знаний, позволяющей автоматически вскрывать латентные связи, например, между группами пользователей и документами. Никакой rocket science в этом нет. Вскрытые связи могут описываться простыми правилами, которые лучше всего объяснить на очевидном примере. Если группа пользователей А работает с документами B,C,D, а группа пользователей Z в это же время работает с документами C,D,E, логично предположить, что документ E также интересен (полезен) группе пользователей A, а документ B – для группы пользователей Z.
Из этого короткого описания понятно, что по-настоящему ценные и нетривиальные результаты от такой системы можно получить, во-первых, не сразу, во-вторых – при эксплуатации её в виртуальных организациях больших масштабов (насколько больших – никто толком не знает, но очевидно, что «корпоративный подписчик» с тремя активными пользователями ничего полезного для себя с помощью всех этих сложностей не откроет).
Появление подобной подсистемы в Office 365 – не столько примечательный факт (этому утверждению будет пояснение), сколько показатель агрессивности «новой Microsoft» и готовности корпорации играть в долгие игры с повышенным риском.
По сути, Microsoft предлагает корпоративным подписчикам Office 365 новое единое инструментальное средство высокоуровневого, «наддокументного» расширения функциональности штатных офисных приложений за счёт латентной информации о внутрикорпоративной активности и выявленных из наблюдений за этой активностью связях между документами и людьми. Не важно, прибегнут ли пользователи к услугам собственных подразделений разработки ПО, или обратятся к сторонним исполнителям, важно одно – Office Graph даёт возможность создавать максимально независимые от платформы (REST API, всё-таки) и её технологических средств совершенно новые приложения «наддокументного» уровня. Такой приём очевиден и был вполне ожидаем. И приложения, использующие Office Graph, уже есть в «Office store», пусть их совсем немного, они дают обзор возможностей новой платформы «офисного прикладного программирования».
Если сложить особенности двух практически одноимённых подсистем Graph (хотя бы на основе общности исполнения и целевого назначения), можно рассмотреть ту самую повышенного риска стратегию Microsoft и понять саму причину рисков.
Получение возможности программного доступа ко всем «офисным» подсистемам корпоративного пользователя − календарю, контактам (и, косвенно, информации о бизнес-взаимоотношениях), – с помощью API Microsoft Graph, и латентной граф-модели информационной и организационной структуры компании (API Office Graph), при полной независимости от технологических средств и сложных middleware подсистем, по идее, должно привлечь и разработчиков, и пользователей. Но красота идеи здесь сталкивается с суровостью реальности, и в первую очередь даже не с политиками безопасности и конфиденциальности.
Office 365 не является абсолютно полноценной заменой обычному «настольному» Office, и его отличия для каких-то пользователей могут оказаться радикальными. Причём речь идёт именно о тех «офисных пользователях», для которых эти отличия критичны. Возьмём хотя бы отсутствие макросов в «онлайновой» версии Word и Excel, а также Active X элементов в документах последнего. Это атрибуты профессиональной работы с Office. И их отсутствие как бы подчёркивают – пользователям Office 365 такие возможности не нужны, что подтверждается популярностью платформы. На фоне этого подтверждённого, предложение расширения возможностей «по-другому», в совершенно новой области, ещё и с привлечением сторонних разработчиков, владеющих неспецифическими для офисного класса приложений технологиями (REST-доступ к API – это слишком далеко от Visual Basic), выглядит очень смело. Ещё смелее стратегия выглядит, если учесть резко повышающиеся требования к системным администраторам корпоративных подписок Office 365 – использование Office Graph требует предварительного построения модели компании, полноценно учитывающей все тонкие нюансы внутрикорпоративной конфиденциальности.
Всего 12 приложений в Office Store все эти соображения подтверждают.
Но в Microsoft умеют играть в «долгие» игры, и ставка очевидно сделана на «подрастание» пользователей Office 365 до готовности к возможностям, скрытым за API двух разных Graph.
Про DCIM у забезпеченні успішної роботи ІТ-директора