Представьте себе сложность задачи сведения воедино административных интерфейсов, которые разрабатывались в разные годы для разных локальных продуктов, и создания на их основе единой формы для «облачной» службы. Именно этим приходится заниматься Microsoft по мере развития Office 365. И если для новых приложений, таких как Delve и Video Portal, интерфейсы создаются с нуля, то Exchange Online и SharePoint Online должны сохранять совместимость со своими локальными аналогами. Кроме того, существует единый центр администрирования Office 365 для управления лицензиями, учетными записями и т. д. Office 365 упрекают в том, что его административные интерфейсы беспорядочно перемешаны и единственной общей нитью является браузер. На языке тех, кто занимается разработкой пользовательских интерфейсов, в Office 365 нашли воплощение разные аспекты языка проектирования. Иными словами, Office 365 может выглядеть и функционировать по-разному, в зависимости от того, какую часть службы вы используете.

Эти различия могут не беспокоить тех, кто довольствуется работой с «облачной» версией своего любимого локального приложения, но может помешать тем, кто хочет использовать весь потенциал Office 365. Иногда бывает сложно разобраться в том, как выполнять те или иные действия в конкретном приложении.

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

• Разные продукты, из которых каждый имеет собственную историю. У Office 365 лишь недавно появились первые уникальные компоненты в лице Office Delve и Office 365 Video Portal. Прочие основные компоненты Office 365 уходят своими корнями в корпоративные локальные аналоги. У SharePoint 2001 могла бы быть общая база данных с Exchange 2000, однако начиная с версии 2003 между ними появилось расхождение, которое продолжалось до последнего времени. Мне могут возразить, что язык проектирования интерфейсов Metro, существующий начиная с версий 2013, внес некую общность в консоли на основе браузера, но у разработчиков пользовательских интерфейсов, работающих с Exchange, SharePoint и Lync, очевидно, разные представления о том, как следует управлять приложениями.

Кроме того, между локальными программными продуктами и их «облачными» аналогами должна поддерживаться некая общность. Если полностью переписать интерфейсы администрирования для Exchange Online и SharePoint Online, то это создало бы еще одно препятствие для плавного перехода компаний в «облако». Это нежелательно, так что степень возможных изменений ограничена, исходя из данного соображения.

Действительно, центр администрирования Office 365 представляет собой организующее начало, но больше в отношении таких компонентов, как учетные записи, лицензии и отчетность, а не рабочего управления на уровне приложений. Более примечательна существующая сегодня тенденция формирования общего управления функциями, реализованными сразу во многих продуктах. Наиболее яркий пример — центр соответствия, обеспечивающий каркас управления функциями, такими как поиск, удержание и предотвращение потери данных в Exchange, SharePoint и OneDrive для бизнеса. При всем своем сегодняшнем несовершенстве центр соответствия, однако, демонстрирует возможность сведения воедино отдельных функциональных фрагментов разных продуктов. Формирование единого администрирования по всему сервису Office 365 требует дальнейшего развития именно такого подхода.

• Разные слои и масштабы. Office 365 унаследовал много хорошего, что было достигнуто в локальных версиях Exchange, SharePoint и Lync, но все это совершенно разные операционные среды. Администратор локальной системы имеет дело с четко определенными слоями управления — например, Active Directory и Exchange, если компания использует один экземпляр Active Directory наряду с одним экземпляром Exchange. Office 365 — более многогранный продукт. Помимо Azure Active Directory, существуют службы Exchange Online Directory Services (EXODS), используемые Exchange Online в каждом регионе Office 365. Exchange использует EXODS для хранения информации об объектах, таких как общие папки с поддержкой почты, которых нет в Azure Active Directory. Эти две службы каталогов органично синхронизированы, причем соединение заметно лишь тогда, когда случаются небольшие задержки визуализации объектов в том или ином месте. Однако различия все же велики, и при наличии многочисленных центров данных Office 365, развернутых в разных регионах для обслуживания десятков тысяч различных клиентов, данные которых должны быть изолированы и защищены, становится очевидным, в чем эти различия состоят и как они могут замедлить продвижение на пути к единообразию.

• Разная функциональность и различные пути реализации функций. Exchange 2013 и Exchange Online имеют общую базу кода, но это разные продукты. Exchange 2013 работает независимо, тогда как Exchange Online — одна из деталей «конструктора» Office 365, позволяющего составлять новые компоненты, такие как Office 365 Groups, из фрагментов Exchange, SharePoint, OneDrive для бизнеса, OneNote и т. д. Другими словами, польза от Exchange Online для Office 365 не ограничивается простой ролью «центральной оси» для развернутых экземпляров. Поэтому любая компания, переносящая свою электронную почту в «облако», должна попытаться полностью задействовать все возможности Office 365, а не просто удовлетвориться функциями электронной почты в «облаке».

Сегодня Microsoft предпочитает поставлять клиентам новые компоненты в незавершенном виде — по крайней мере, в глазах администраторов, многие из которых выразили озабоченность при появлении Office 365 Groups, Office Delve, Office 365 Video с очень ограниченными средствами управления либо вообще без таковых. Пользователи ощущают меньше неудобств, получая в свое распоряжение новое программное обеспечение, выпускаемое на регулярной основе. В «облаке» ИТ-специалиста отодвигают в сторону, оставляя ему лишь функции поддержки вместо регулирующего воздействия на бизнес.

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

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

Кроме того, под рукой всегда есть PowerShell, и, если вам не нравится то, что предлагает Microsoft, создайте собственные средства администрирования — по крайней мере, там, где PowerShell поддерживается (то есть далеко не везде, хотя это одно из основных средств автоматизации для Office 365).

Мы живем в несовершенном мире, и это лишь еще один пример несовершенства. Неудобства просто нужно пережить!