Ключевые процессы MDM и архитектура MDM-решения

 

Управление основными данными ориентировано на сбор и накопление данных из различных информационных систем – источников данных, консолидацию данных и их распределение (доставку) информационным системам – потребителям данных.

Можно выделить следующие ключевые процессы MDM в организации:

● управление моделью данных;

● сбор и накопление данных;

● проверка, стандартизация и обогащение данных;

● разрешение конфликтов данных (разрешение сущностей);

● использование данных[427].

Практика MDM в организации должна быть поддержана специальным ИТ-решением, созданным и внедренным в организацию. Важнейшая составляющая MDM-решения – центральный репозиторий данных (хаб). В него собираются данные, являющиеся кандидатами в основные данные, они надлежащим образом обрабатываются и доставляются потребителям. Определены четыре варианта архитектуры хаба данных[428].

1. Индексная архитектура: на хабе хранятся только соответствующие ссылки (индексы) данных; это актуально для данных, которые нельзя копировать или перемещать.

2. Консолидирующая архитектура: данные регулярно загружаются в хаб, обрабатываются, и при этом обеспечивается доступ потребителей к этим данными.

3. Централизованная архитектура во всем подобна предыдущей, но в этом случае дополнительно хаб выполняет задачу разового ввода данных, и далее все изменения данных делаются непосредственно на хабе (информационные системы попадают в разряд потребителей).

4. Смешанная архитектура реализует сочетание консолидирующей и централизованной архитектур для различных основных данных организации. Если какие-то фрагменты данных организации запрещено перемещать, то для них может использоваться индексная архитектура.

 

Существует большое количество готового программного инструментария по созданию MDM-решений. Прежде всего, это такие продукты как SAP MDG, Informatica MDM, IBM InfoSphere MDM, которые ориентированы на решение стандартных задач MDM. Однако разнообразие практических задач столь велико, что некоторые производители (например, «Юнидата» и пр.) предлагают программные «конструкторы», которые позволяют получить MDM-решения для конкретных потребностей организаций.

 

MDM-проекты

 

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

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

С другой стороны, организации может быть и не нужен MDM-проект. Во-первых, когда речь идет об обработке однородных данных – например, сформированных посредством ввода одним или несколькими операторами. Такие проекты могут потребовать: создания логической модели данных, валидацию и очистку данных, обеспечение доступа к данным в различных режимах и т. д. Но при этом отсутствует главная задача MDM – консолидация данных из разных источников. Если для такой задачи операторный ввод данных заменить автоматизированным поступлением тех же данных из разных источников, то она приобретает MDM-специфику. Во-вторых, «вне юрисдикции» MDM-проектов лежат запросы на реализацию сложного бизнес-функционала. Такой функционал должен быть вынесен из MDM-решения в отдельные информационные системы[429], а MDM-проект заканчивается доставкой основных данных потребителям.

Следует отметить, что MDM-специфика должна быть основной в проекте. Если этой специфики нет или она лишь частично присутствует, но является не главной, то данный ИТ-проект не является MDM-проектом.

 

Состав MDM-решения

 

В результате реализации MDM-проекта у организации-заказчика появляется MDM-решение, которое включает в себя: MDM-систему (программную часть решения); новые регламенты по работе с данными; обученных сотрудников организации, которые умеют использовать MDM-систему в соответствии с новыми регламентами; налаженный и запущенный процесс управления основными данными. Последний пункт важен, поскольку все может иметься в наличии, но деятельность по MDM в организации отсутствует. Например, из-за нерешенных вопросов безопасности или противоречий внутренних регламентов, или в силу большой загруженности сотрудников, которые должны участвовать в MDM. Таким образом, MDM-решение – это осуществляющаяся в организации деятельность, налаженная и обеспеченная всем необходимым.

MDM-система представляет собой развернутое в организации готовое программное обеспечение, которое реализует основные функции MDM – хаб данных, консолидацию и пр. Главная часть этого ПО – базовый MDM-продукт[430], а также дополнительный набор ПО для решения частных вопросов. Наличие многофункционального готового ПО, которое следует лишь настроить и развернуть у организации-заказчика, существенно снижает стоимость и риски MDM-проекта. Однако некоторую часть MDM-системы приходится дорабатывать в рамках проектных мероприятий, чтобы отразить особенности организации, которые не удается покрыть стандартным инструментарием[431].

 

Описание модели

 

После первой оценки потребностей заказчика необходимо провести их детальный анализ в терминах MDM[432]. Для этого предлагается специальная функциональная модель. Она описывает типовое MDM-решение, включая в себя максимальный объем функциональности, с тем чтобы можно было выбрать необходимые компоненты, которые нужно реализовать в данной ситуации[433][434].

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

Например, при реализации одной из главных компонент модели «Консолидация данных» нужно:

● выполнить работы по наладке: наладить ПО, поддерживающее соответствующее рабочее место аналитика, определить правила для разрешения конфликтов и выполнить первый раз консолидацию данных из источников данных организации;

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

Предлагаемая модель ориентируется на внедрение в организации новой ИТ-системы на основе готовых инструментов, которые могут быть настроены и доработаны под особенности задач заказчика. Поэтому каждая компонента модели имеет программную и аналитическую части. Часть функционала компоненты выполняет соответствующее ПО, а часть – человек (аналитик). Работы по наладке компоненты целесообразно разделить на наладку/реализацию некоторого ПО и выполнение аналитических функций. Например, создание логической модели МД – аналитическая функция, а очистка данных – программно-аналитическая. В последнем случае речь идет о создании и программной реализации специальных правил очистки, которые применимы именно для этих данных, именно для этой организации, и применении этих правил, включая анализ результатов, возможно создание новых правил. При этом используется готовое ПО, но отдельные специальные правила, ориентированные на специфику данных организации, могут быть реализованы в виде дополнительного ПО, созданного в рамках MDM-проекта.

 

Основные пакеты модели

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

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

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

 

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

Пакеты и функциональные компоненты модели представлены на рисунке 13.1.

 

* Кузнецов С. В., Кознов Д. В. Управление мастер-данными в рамках итеративного подхода // Онтология проектирования, 2021. Т. 11, 2 (40): 170–184. – DOI: 10.18287/2223–9537–2021–11–2–170–184.

 

Инвентаризация данных

В рамках этого пакета производится идентификация источников данных, а также определяется, какие именно данные из этих источников нужно преобразовывать в основные данные. Необходимо определить точный состав основных данных. Чем больше разнообразие данных, тем сложнее (и, следовательно, дороже) будет MDM-проект. При этом собирают лишь те атрибуты, которые будут востребованы потребителями данных. Важно провести типизацию данных, выяснить реальную заполняемость каждого существенного атрибута и его типовые значения. В этом пакете также определяется уровень доверия к различным источникам данных. Возможна ситуация, что некоторый источник имеет очень низкую степень доверия, в частности, он может хранить данные, которые давно не обновлялись. Обращаться к нему следует лишь в крайнем случае. Эта функциональная часть – преимущественно аналитическая.