От анархии данных к их монетизации

Правительства разных стран включились сегодня в глобальную гонку за превосходство в «экономике данных» — например, в 2020 году Китай и ЕС объявили извлечение ценности из данных важнейшим источником своего экономического и социального прогресса на ближайшее десятилетие. Благодаря более эффективной работе со всеми доступными данными, компании могут повышать свои прибыли, создавая дополнительные источники дохода и бизнес-модели. По оценкам аналитиков, монетизация, например, данных о подключенных автомобилях может принести в 2030 году игрокам рынка мобильных сервисов и приложений ежегодный прирост прибыли от 250 млрд до 400 млрд долл. Однако неясно, в какой степени конкретные организации действительно могут реализовать подобные возможности: для начала компании должны внедрить сервисы монетизации данных, освоив процесс извлечения, сбора, обработки, анализа данных и их использования в рамках своего ИТ-ландшафта и бизнес-экосистемы.

Облачные гиганты уже показали, как работает монетизация данных, — их преимущество в том, что они изначально создали архитектуры, ориентированные на обработку данных. Например, еще в 2002 году основатель Amazon Джефф Безос в своем известном обращении «API Mandate» написал, что весь обмен данными между приложениями и сервисами Amazon должен осуществляться через интерфейсы сервисов без каких-либо исключений и независимо от используемых технологий, а любой сотрудник, игнорирующий это требование, будет уволен. Однако в большинстве компаний ситуация иная: имеется ряд разрозненных хранилищ данных, которые наспех объединяются множеством сценариев, интерфейсов и соединений «точка — точка». В конечном итоге такие «спагетти-архитектуры» не только дороги, но и препятствуют монетизации данных: качество данных обычно низкое, а их большие фрагменты вообще не используются. Аналитики IDC считают, что сегодня компании задействуют лишь треть доступных им данных.

Организациям необходим переход на единую ИТ-архитектуру, ориентированную на обработку данных с целью их монетизации.

Принципы архитектур, ориентированных на обработку данных

Рис. 1. Подключение к агрегатору данных по принципу «единоразового подключения» для каждого источника

По своей сути такая архитектура призвана отделить данные от генерирующих их приложений, направляя полезную информацию через основной узел агрегации данных или агрегатор данных (data hub). При этом используются технологии потоковой передачи, такие как Kafka, в сочетании с хранилищем данных на основе реляционных, NoSQL- и графических баз данных, а также с «озером» данных (обычно на основе Hadoop). Каждое приложение действует как «производитель» данных для агрегатора данных, а каждый запрос является «потребителем» обширного распределенного пула информации. Все это встроено в комплексную структуру управления данными.

Все данные передаются в виде потока событий через агрегатор

Все источники данных через поток событий отправляют информацию в агрегатор (рис. 1). В случае приложений, это сведения из логической модели данных, а в случае устройств Интернета вещей — локально собранная информация о текущем состоянии. Данные передаются в исходном формате: на уровне приложения не должно происходить никаких преобразований, что позволяет избежать ошибок и потерь. Соединение основано на принципе «единоразового подключения»: одно соединение для каждого источника данных. Существуют различные варианты передачи данных, включая протокол MQTT, Kafka Connect, CDC (Change Data Capture — «сбор данных об изменениях»), Apache NiFi и т. д. Чем ближе модель передачи к базовой модели данных производителя, тем быстрее и дешевле будет реализована интеграция. Как и источники данных (поставщики), «запрашивающие» приложения и службы (потребители) обмениваются информацией только через агрегатор данных. Это позволяет избежать перенастройки интерфейсов при каждом новом запросе дополнительной информации.

Все производители публикуют метаданные

Для использования данных в долгосрочной перспективе, все передаваемые через агрегатор сведения документируются, что как минимум включает метаданные терминологии и классификации. По мере развития архитектуры метаданные дополняются другими метками, например: о соответствии европейским Общим регламентам защиты данных (General Data Protection Regulation, GDPR), о запросе в рамках GDPR, об удалении в рамках GDPR. Метки также могут указывать на автоматический сбор или сбор вручную, на поступление данных в режиме реального времени или собираемых периодически, на уровень доверия и т. д. Приложение по организации управления собирает эти метаданные и координирует шифрование данных и доступ к ним.

Рис. 2. На основе управления метаданными, ключами и доступом можно обеспечить высокоточный порядок обращения к зашифрованным данным для различных уровней безопасности

Потоки информации из одного источника часто содержат сведения разных уровней безопасности (от C1 до C4: общедоступные, внутренние, конфиденциальные и секретные данные), поэтому необходимо создать тему для каждого из уровней и обмениваться ключами между участниками в зависимости от их роли (рис. 2). Только пользователи, которым разрешен доступ к требуемому уровню безопасности, могут видеть его данные. В качестве первого шага или в рамках продукта с минимальной функциональностью метаданные в приложениях могут быть объединены с ролевым администрированием. Такие элементы управления применяются на уровне темы. На следующих этапах набор элементов можно расширить, включив информацию из системы управления идентификацией и контроля доступа (Identity & Access Management) с помощью микросервисов.

Каждый интерфейс — часть CMDB

Aгрегатор данных должен быть также максимально доступен, как и Kafka или NiFi, однако последний способен работать только на одном узле. В то же время важно, чтобы каждый отдельный интерфейс представлял элемент конфигурации (Configuration item, CI) в базе данных управления конфигурациями (Configuration management database, CMDB) [1] и проходил мониторинг. Более того, требуется проводить мониторинг каждого интерфейса и назначать ему конкретные ключевые показатели эффективности (KPI). Изначально ИТ-департамент вручную создает элементы конфигурации, а на следующих этапах параметры могут быть сгенерированы средствами систем машинного обучения.

Управляемые интерфейсы

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

Поддержка модели данных с использованием каталога и метаданных

Первоначальные данные при передаче в агрегатор максимально соответствуют исходному формату, но далее они должны использоваться в соответствии с моделью данных предприятия (Enterprise Data Model, EDM). Для этого ИТ-департамент определяет, публикует и поддерживает единую EDM — каждый ее блок включен в специальный раздел агрегатора. В каждой теме должны быть правила, определяющие, кто и как может получить доступ. Администрирование контроля доступа и основных правил осуществляется путем управления метаданными, которое тесно связано с управлением архитектурой предприятия, ролями данных, развитием агрегатора данных и поддерживается регулирующими функциями. На этой основе в компании создается каталог данных для подписки пользователей на нужные сведения. Необходимо четкое определение обязанностей по управлению данными для каждой роли: владельцы данных определяют порядок хранения и использования; распорядители оперируют данными в соответствии с пожеланиями владельца данных и несут ответственность за их качество и своевременное удаление.

Фокус на пользователях

Рис. 3. Прикладной программный интерфейс на основе микросервисов

ИТ-команда предоставляет каталог данных для приложений, пользователей и, при необходимости, партнеров. Для приложений данные доступны по сервисной модели через API-интерфейсы, а для пользователей и партнеров — через специализированные интерфейсы на базе микросервисов. Такие API (рис. 3) позволяют быстро разрабатывать ориентированные на пользователя приложения, которые предоставляют сотрудникам именно ту информацию, которая необходима. На следующих этапах приложения могут быть адаптированы не только к конкретной должности сотрудника, но и к регионам и культурным особенностям.

Актуальная, конкретная, понятная и доступная документация

Гибкость и управление данными требуют прозрачности, поэтому рекомендуется документировать соответствующие инструкции в формате редактируемой страницы, к которой есть доступ у всех заинтересованных сотрудников. Документация содержит описание принципов архитектуры, изложение передового опыта, исключения из правил и их причины, протоколы, модели данных и, в частности, EDM. Если компоненты исходного кода являются частью архитектуры, то должна быть ссылка на репозиторий кода. К компонентам архитектуры добавляются ссылки на лучшие практики. Также должны быть документированы и доступны операционные концепции, концепции тестирования, правила работы с кодом и управления тестовыми данными. Все это облегчает взаимодействие, способствует постоянному улучшению культурной среды работы с данными, оптимизации процессов предоставления услуг и организации операционной деятельности.

Тестирование и непрерывная доставка данных

Надежный конвейер сборки (continuous integration / continuous delivery, CI/CD) со средствами автоматизированного тестирования способствует совершенствованию архитектуры работы с данными, повышает качество обслуживания и создает основу для гибкой разработки и DevOps. По мере роста числа тестовых кейсов увеличивается и сбор тестовых данных. Как и сам код, они должны поддерживаться в новых версиях, а также обеспечивать производительность и проведение регрессионного тестирования.

«Цифровой двойник»

Рис. 4. Каталог сервисов обеспечивает данные и анализ для различных целевых групп с помощью подходящих приложений

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

Путь к монетизации

Разберем пример, иллюстрирующий процедуру развертывания архитектуры для обработки данных.

Глобальная компания-авиаперевозчик расширяется и приобретает новые активы. В результате образуется множество разнородных ИТ-сред, адаптированных к потребностям отдельных направлений или активов. Приложения взаимодействуют друг с другом без единой точки связи. Отсутствует комплексный анализ данных: соответствующие проекты завершились после первых неудачных попыток — затраты на подключение к многочисленным источникам данных были слишком высокими, и не было четкого представления о правильных источниках.

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

В качестве эксперимента ИТ-команда создает куб данных из нескольких источников, чтобы проиллюстрировать, каким образом может быть проведен анализ для предоставления отделу продаж актуальной информации. В итоге отдел продаж решает поддержать дальнейшее развитие архитектуры. За подключением наиболее важных бизнес-приложений к агрегатору данных следует проверка обоснованности концепции (Proof-of-Concept, PoC), которая показывает, как ориентированное на пользователя приложение может помочь пассажирам в аэропорту. Так, благодаря приложению, наземный персонал получает текущую информацию о статусе рейса, который требует внимания, например, при задержках или изменении выхода на посадку. Инструкции поступают от старшего диспетчера в чате и могут быть отправлены другим членам команды обслуживания пассажиров. Слухи о преимуществах нового приложения быстро распространяются — ИТ-отдел получает дополнительные запросы на такие приложения.

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

***

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

Литература

1. Александр Александров. CMDB: досье для управления ИТ // Открытые системы.СУБД. — 2006. — № 10. — С. 29–38. URL: https://www.osp.ru/os/2006/10/3910054 (дата обращения: 21.11.2021).

Стефан Брок, индустриальный партнер, Сергей Карташев (sergey.kartashev@hpe.com) — архитектор решений, Hewlett Packard Enterprise (Москва).