Решение о добавлении компонентов в аналитическое окружение должно быть основано на анализе затрат и доходов, который принимает во внимание, сколько данных потребуется дублировать на новую платформу, сколько будет стоить синхронизация данных и обучение пользователей новым навыкам, обладает ли новая платформа необходимыми характеристиками для операционного масштабирования и многое другое. Бежать покупать новейшую сверкающую игрушку только потому, что она появилась в продаже, – пустая затея.
После того как опоры будут установлены на место, уже не составит труда оптимизировать их использование и распространить данные и аналитические процессы в масштабах всего аналитического окружения организации. Самая большая проблема состоит в том, чтобы обосновать необходимость добавления новый опоры или вспомогательной технологии в аналитическое окружение (подробнее об этом в четвертой главе). Причина очевидна: гораздо дешевле использовать нечто, уже занявшее свое место, чем ставить на это место нечто новое.
Таким образом, для того чтобы организация смогла осуществлять любой необходимый ей анализ данных любого типа и в любое время, она должна сначала установить на свое место опоры. Стоит проводить периодический (возможно, ежегодный) обзор базовых опор или вспомогательных технологий, которые организация еще не внедрила. Возможно, в ходе очередного обзора вы придете к выводу о необходимости разработки бизнес-кейса с целью добавления недостающего компонента в окружение. Если потребности организации в операционной аналитике понуждают к установке новой опоры, организации следует ее добавить, поскольку это увеличит гибкость и функциональность при построении аналитических процессов.
Конечных пользователей не должно волновать, где хранятся данные
Суть в том, что конечных пользователей, будь то профессиональные аналитики или пользователи традиционной бизнес-аналитики, менее всего волнует, где хранятся данные, потребные им для анализа. Пользователям нужен свободный доступ к данным и возможность создавать и реализовывать любые необходимые им аналитические процессы с максимальной легкостью и с достаточной производительностью{46}. Например, подборки сведений о клиентах, таких как демографические данные, представлены в виде таблиц в реляционном окружении или в виде файлов в нереляционном окружении? Пользователям это безразлично, были бы обеспечены доступ, свободное использование и производительность, желаемые пользователями.
Сосредоточьтесь на том, чего желают пользователиПользователям безразлично, где хранятся данные или на каких опорах выполняется аналитика. Им просто нужен доступ к любым данным для любого вида анализа в любое время. Чем меньше пользователи вынуждены думать о физических местах хранения и анализа данных, тем эффективнее они могут действовать.
Поставщики сейчас усиленно работают над тем, чтобы сделать несоизмеримые опоры единого аналитического окружения тесно интегрированными, если не практически прозрачными для пользователей. Они встраивают в них коннекторы, которые позволяют пользователям, работающим на одной платформе, получать свободный доступ к данным на другой платформе. Благодаря этому пользователи могут сосредоточиться на логике аналитического процесса, не беспокоясь о том, где физически находятся данные. На практике это означает, что работающий в реляционной среде пользователь может видеть данные в виде таблицы, тогда как на самом деле они хранятся в виде файла в нереляционной среде. Когда поступает запрос на эти данные, они извлекаются из нереляционного хранилища и передаются на реляционную платформу для обработки запроса. Пользователи не знают о происходящем, да им оно и не важно, пока поддерживается производительность. Если же производительность страдает, системные администраторы могут перенести данные из файла, хранящегося в нереляционном окружении, в реляционную таблицу, чтобы не требовалось осуществлять преобразование данных. И, наоборот, данные из реляционной таблицы могут быть перемещены в нереляционный файл, если общие требования к обработке обусловливают это место как лучшее для хранения данных. В общем, любую часть данных можно разместить на хранение туда, где они будут наиболее пригодны для использования.
При выборе решений для корпоративной аналитической среды важно оценивать как текущие возможности, так и долгосрочные планы поставщиков по добавлению продуктов к единому аналитическому окружению. С одной стороны, не нужно откладывать решение в ожидании следующего поколения продуктов с незначительной дополнительной функциональностью. С другой стороны, не стоит игнорировать долгосрочные дорожные карты продуктов, которые вы планируете приобрести. Технологии меняются быстро, и разные поставщики могут идти разными путями. Вы можете найти двух поставщиков с эквивалентными предложениями для удовлетворения ваших сегодняшних потребностей, но их дорожные карты могут существенно разниться, так что в перспективе один из них способен значительно превзойти другого.
Читатели, безусловно, знакомы с концепцией облака и облачных архитектур, поэтому я не стану давать здесь базовых определений, а остановлюсь на нескольких ключевых моментах, важных в контексте нашего разговора об операционной аналитике. Меня часто спрашивают по поводу использования облака для аналитических процессов, как операционных, так и неоперационных. Чтобы ответить на этот вопрос, важно провести различие между облачными архитектурами и облачными услугами.
Организации могут внедрить облачную архитектуру на собственном оборудовании под защитой своих брандмауэров. Это частное облако позволит обеспечить эффективное совместное использование ресурсов без какого-либо внешнего вмешательства и потери контроля над данными. Другой вариант – аренда пространства на общедоступном облаке у внешнего поставщика облачных услуг. В этом случае организация платит поставщику только за используемые ею оборудование и ресурсы (включая маржу прибыли для поставщика).
Для малого бизнеса или исследователей, которые обычно используют лишь небольшую часть ресурсов сервера, общедоступное облако может быть очень выгодным вариантом, даже несмотря на надбавку к цене со стороны поставщика. У крупных же организаций, использующих большие данные и операционную аналитику, обычно так много пользователей, использующих так много данных, что общедоступное облако в конечном счете может обойтись им гораздо дороже, чем частное. Например, если организация использует вычислительную мощность 20 серверов практически беспрерывно, то аренда ресурсов обойдется ей намного дороже, чем владение собственными. Кроме того, использование общедоступного облака для уязвимых данных поднимает вопросы, связанные с безопасностью и соблюдением конфиденциальности. Эти вопросы могут носить правовой характер или же касаться восприятия: так, многие потребители могут чувствовать себя некомфортно, если компания будет хранить их персональные данные на общедоступном облаке.
Использовать облако или нет?Частное облачное окружение – это чрезвычайно мощная и экономически эффективная архитектура, к которой прибегнут многие организации. Общедоступные облака могут оказаться дорогостоящими для крупных организаций, поэтому вряд ли будут широко использоваться для целей операционной аналитики, как это сегодня рекламируется на рынке. Все опоры и вспомогательные технологии, рассмотренные нами в этой главе, могут работать в облачной архитектуре.
Сегодня многие поставщики предлагают аналитику в виде сервисных пакетов на базе общедоступного облака. Эти приложения позволяют пользователям создавать и осуществлять аналитические процессы с помощью инструментов, которые предлагаются по подписке или на основе платы по мере пользования. Многие, но не все, аналитические сервисные продукты могут быть юридически закреплены за организацией и присоединены к частному облаку. Прежде чем тратить время на оценку конкретного аналитического метода в качестве сервисного продукта, убедитесь в том, что он подходит для вашего запланированного окружения. Например, если вашей организации не разрешено использовать общедоступные облака, вряд ли имеет смысл рассматривать продукты, доступные только там.
Частное и безопасное облачное окружение способно обеспечить гибкость, необходимую для превращения аналитики в операционную, а также хорошую рентабельность. Вместо того чтобы иметь на 15 отделов один сервер, который к тому же часто простаивает или недостаточно используется, можно иметь пять серверов, которые с лихвой удовлетворят потребности всех отделов. Это позволит снизить затраты на обслуживание и административные накладные расходы. В ближайшие несколько лет внутренние частные облачные архитектуры получат широкое распространение повсеместно и будут применяться для поддержки многих операционно-аналитических процессов.
